The key to this is to specify a chamfer value, and at least three points using the PolyBeam class. You must also provide a profile type that Tekla understands – otherwise you’ll get a bunch of straight lines.
Here’s some basic code to get you started:
You should be able to easily import, into Tekla, any curved Beam you want. The principal requirements are: (i) start point, (ii) end point, and (iii) also rotation. Start point and end point and centre point – this will not do: you will also need a third vector if you are going down this route, and I feel that it needlessly complicated. This can be obtained via any any means: CSV files, or directly with Rhino APIs (this might require programming in both Tekla and Rhino).
It is best to control your data source
If you read our past blogs re: CSV files – everything is contingent on how it is obtained. If you have rubbish in, you get rubbish out. We worked extensively with a party on the Westgate Tunnel, who promised .CSV files, but then provided me with corrupt and inaccurate data points, and did not provide the data in the agreed upon format. This makes for headaches and recriminations — and ultimately dissatisfied customers — but what can you do if they provide you with rubbish data that you cannot verify? So if you’re going down the CSV file route — then you need to know how the CSV files are being produced, and that there are not mistakes in them: e.g. missing columns, nonsensical data values, and that they are being produced programmatically etc. or at the very least have excellent lines of communication with your client to resolve these types of issues. Controlling the data source obviates these problems.
Or another problem I faced – you’ve agreed on CSV files, but the format changes each time an update happens. Someone changes the name of a column header – or they give you a file with irrelevant stuff in there. Every time you have to manually edit something, you’re introducing the possibility of errors. All of this can be solved by controlling the data source.
The Devil is in the Details
Again, as with most things, they seem simple at first but the devil is in the details: you gotta tackle the problem of rotation and also profile mapping and weird gotchas in Tekla – that are not documented. Then another important thing to manage:
Revisions and changes
How are you gonna manage this? How are you going to document variation hours? Likely you might have to add IDs to each member. This will have to be incorporated into CSV files from the outset. Or if you have the Rhino model in hand — then you could just see what has been changed programmatically: (i) are they IDs all the same, and (ii) if so, have they been moved. Now this will entail persistence of an old model to be compared with a new model, and a form of documenting these changes. This takes extra time, extra programming, and extra documentation management.
By Ben Koshy
Leave a Reply