Steel Detailing | Precast Detailing | Estimation

Author: admin

  • Thoughts About the AutoCAD API (AutoCAD .net API)

     

    Get your API working hard for you. Like worker bees.
    Get your API working hard for you. Like worker bees.

    I got thinking about the AutoCAD APIs (ObjectARX/.NET) – they’re virtually the same – the .NET API is basically a wrapper to the ObjectARX API (with some differences). If you want the full power of low level calls then you gotta go with ObjectARX. But then using .NET comes with a very powerful benefit – a host of libraries and code readily available to utilize. If you’re talking UI then WPF is waiting for you if you go down the .NET path, but not so with ObjectARX.

    Anyways, when you think about the API  there are a few issues that you gotta manage:

    1. The opening and closing and disposing of Objects.

    And the main operations that come to mind are the following:

    1. Adding Items to the database.
    2. Removing Items from the database.
    3. Editing existing items from the database.
    4. Getting Items from the database.
    5. If this happens do that (Events) which ties into all of the above.

    Is it just me or does smack of a RESTful API? Well not quite, because we can store state in variables, both within the drawing, and in variables within our classes (temporary).

    These are the steps:

    1. Identify a resource.
    2. Operate on that resource.

    We can go about this in a few ways:

    1. Using extension methods. This means that we have already identified the relevant resource and we act on it.
    2. Static Methods where then operate on those resource. (I use resource in the sense that Fielding uses it).
    • GetResource( parameters)
    • Action(parameters)

    We shouldn’t have to worry about all the lower level stuff.

    Perhaps a better wrapping API can be written incorporating this. I know Mr Wolfgang Tertinek has wrote about it extensively in his blog. It’s a good approach, but perhaps common tasks e.g. changing a layer of an object can be incorporated in this model. Ideally this should be written simply with core level logic without direct use of a particular dll.

    • .e.g something like this: SelectionFilter.Create(layer: “test”, types: [BlockReference, Mtext]) – without going into the specifics of setting type filters etc. A DSL much like Active Record for handling these types of queries.

  • WPF User Interface for Precast Panel Comparison

    This utilises WPF to compare panels, isolate changes and make better decisions.

     

    See below for a demonstration:

    WPF – Eliminating Errors using Cross Checking from Tek1 on Vimeo.

     

     

     

  • 3d Steel Estimation

    Estimate accurately 3d Model

    Click to Download Sample take-off

    Accurate estimation from people with takeoff experience, highly skilled in the use of Autocad, Tekla, and Excel. You save your estimators time. We provide you low-cost accurate takeoffs.

    How do we do it?

    We prepare a cad file in Autocad cad suitable for conversion to Tekla.

    Then with a single button Click, We convert All the members to Tekla native members which is Col, Beams, Bracings. Base Plates.

    Deliverables

    1. Tekla Stick Model
    2. Linear Footage of Balustrades and handrails
    3. KISS file from Tekla model (If done in Tekla)
    4. Excel Sheet summary of the take-off of items that are not stick modelled.
    5. Grating Summary
    6. Tread Summary

    Benefits

    • Fast turn around – We have the tools, the skills and the man power.
    • Low Cost
    • 3d Model
    • Better Information to GC Contractor via 3d Model

    Our Office Locations

    Head Office in Melbourne, Australia. Back office, Chennai, India

    Our Contact Details

    email: koshy@tek1.com.au

    Phone +61 3 9560 6397

    web: www.tek1.com.au

  • The Connect Handrail Command – Demo (BubbleDeck)

    A lovely picture of handrails.
    A lovely picture of handrails.

    This is a little utility which connect handrails. It does so if:

    1. The handrail block references are parallel to the panel edges, and
    2. If they are a minimum 560 mm away from the edges and
    3. If they are colinear with each other.

    Here is a demo:

    Demo – Connect Handrails Command in AutoCAD` from Tek1 on Vimeo.

  • On Line Equality (AutoCAD .net API)

    Some lines may be more equal than other lines? The AutoCAD .net API's EqualTo method may disagree with your interpreation of equality. Here are the results;
    Some lines may be more equal than other lines? The AutoCAD .net API’s EqualTo method may disagree with your interpretation of equality. Here are the results;

  • Refactoring the Code – Printing Selected Beams to Excel – Part 3 – (Tekla Open API)

    An apposite photo for refactoring, yet it is also oxymoronic.
    Refactoring is when you change, but don’t change.

     

    Let us now continue to refactor according to good design principles.

     

  • Refactoring the Code – Printing Selected Beams to Excel – Part 2 – (Tekla Open API)

    Ok, so we’ve done some significant refactoring.

    We’ve considered a lot of things. Some things still to be improved:

    • Naming,
    • Better utilization of the ClosedXML library – because our techniques are quite primitive right now.
    • Testing (this really should be done first, but no matter).
    • Further refining the code according to SOLID design principles.

    Here is the code thus far:

     

     

    Ok, that’s certainly a bit better. Still the namining of the classes is quite poor; and we have the dependency inversion issues that we need to fix. Also is there any need to pass in the beams object direction when at the end of the day, we are converting it to a data structure which the printer can understand? Perhaps we should just pass in the printed data structure? We will address these concerns in Part 3 of our refactoring.

  • Refactoring the Code – Printing Selected Beams to Excel – Part 1 – (Tekla Open API)

    Improve by refactoring.
    Strive to improve the code. Just like this guy is trying to improve his swing. Looks like a fine golfer by the way. probably low single figure handicap, if not scratch.

    We will attempt to do something which is seldom done or discussed in Tekla code samples: and that is the very important issue of refactoring code.

     

    1. Start with Tests.

     

    The first thing you need is a good suite of tests. That way you will know whether something has gone wrong or not. It might be tricky doing this since we are developing within the Tekla environment, but I do suppose it’s possible.

     

    2. General Themes:

     

    • Change names to more appropriate titles.
    • Restructure the code to make it understandable.
    • Correct any obvious defects:

     

     

  • Write Selected Beam Members to an Excel File (Tekla Open API – Tutorial)

    Members. Looks good.
    Some nice looking steel. The picture has nothing to do with the Tekla API but it’s cool nonetheless.

    What is the task at hand? 

    1. The user selects some beams.
    2. We then want to collate the following information into various Excel spreadsheets:
      1. Name
      2. Profile
      3. Length and finally Weight
    3. We want two views: the first aggregates the beams by their name and finish, and the second merely lists all the beams selected with the information listed above (length/weight etc).

     

    WARNING: The code is very dirty. There’s a lot of repetition here. And I’ve gone up some cul de sacs incorrectly. But that’s ok. It’s code which works. We can worry about refactoring for another day – in fact, that will make for a very good exercise. Here is a link to where I document the refactoring process.

     

    I’ll walk you through the code:

    Here is the full code unencumbered by commentary: