Because drawing Advanced Steel Beams is very cumbersome. If you have a CSV file you can draw AutoCAD lines and conver them with a fairly simple macro. Everything is open sourced, so you can fork or submit a PR if you require.
Here is a video demonstrating this:
If you want to download it, please see check out this link.
I had written a more advanced user interface for AutoCAD. Perhaps I will incorpoate that into Advance Steel when I get the time. Porting it is a little tricky/complicated it.
You want to programmatically create reports. Here’s how
Reports can be generated fairly easily, manually. But how do you do it programmatically using the Tekla Open API?
Please see below for a code sample:
Programmatically Extracting Report Values
Now, if you want to generate the values programmatically, in memory, and then process them somehow into an excel output, consider the following code sample here.
If you want to programmatically select model objects, refer to the code pasted above.
The question: how to generate generate excel files given a particular hash table – this is not an issue pertaining to the Tekla Open API specifically though. I would use a library like CSV Helper to create a series of rows from the hash table.
There is a large number free way gantries across melbourne. Tek1 has detailed a good number of them very efficiently.
Here is an example of one such Gantry we have detailed for our Melbourne client in the SouthEast.
There are couple of types of gantries, very similar. The large span gantries have to be fabricated with a camber which is challange for the detailer and fabricator.
Managing weld distortion, transport etc are the challenges the fabricator will have solve.
Most of such jobs come with a very short delivery time between order and install, and generally high pressure jobs. Getting first time right is super important.
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.
Here is a preview on what is cooking in our kitchen. This is one of the feature which have built into the system to save a huge amount of time trying to avoid duplicate file downloads. The principle is simple and the execution beautiful. Saves us a huge amount of time. The entire RFI system is free our our clients to use for the projects they allocate to us.
As of now there is no public domain taken for this app. It still in the kitchen. But nearly ready for the shelves.
Here is a tutorial which covers Numbering in advance steel. It however does not cover what how to manage once drawings are issued. May be there is another video for that
Here is a video on how to export Anchor bolt positions to Total station. This option is available in Tekla as well. But it is surprising that no one has yet asked us for this export.
We have so far only provided CAD layout of anchor bolt position. May be we must provide the point export from advance steel as well as Tekla
Here is the video of how to export from Advance steel
