Author: admin

  • Speed up the Shop Drawing Process – Order Dimensioning Tool (Bubble Deck)

    Dimensions are critical
    A nice photo of a scale.

    I’ve made a tool which allows you to order dimensions faster.

     

    Here it is below:

    Order Dimension Command from Tek1 on Vimeo.

     

    For those who want to read my philosophy of the benefits of improving productivity and how I approach detailing – see below. If that bores you, then you may safely skip it with no loss.

    An Approach to Detailing: Make things Easier and make them faster

    Productivity is what makes the world go round faster. It’s why you can fly from Melbourne to London in less than 24 hours. 500 years ago it might take you a few months – and that too at a break neck speed. Today, anything over 2 days is a painful delay.

    Improving Shop Drawing Productivity

    It’s the same with shop drawings. We found that our detailers were spending too much time ordering dimensions. That’s something that can be sped up. We want to smash something which had taken over an hour down to 5-10 minutes. And if possible, we want to reduce that time to zero. This allows our detailers to turn around shop drawings quickly to their Precaster – which will in turn massively improve the Precasters turn around time, and working capital situation, and will allow a continual throughput of panels being cast on the factory floor. In other words you will never have a situation where you have 30 guys on the shop floor twiddling their thumbs because their drawings weren’t brought to them quick enough. And if you can get out of a project earlier, that means you can get paid earlier. That in term will allow developers to quickly build and get out of a project ASAP, which would have monumental impacts to their working capital positions and overall profitability. In short, doing things quickly and accurately is worth a lot………………..Time is money.

    Small improvements have big impacts.

    That’s how I approach detailing.

     

  • 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: