Cold-Formed Steel Shed Industry: part:#2

As explained previously an Excel/vba macro is used to generate an AutoCAD script which is written to a default folder, and then AcadLT is launched from vba using command line parameters to run the Acad script automatically as Acad loads. The model space output of the script is shown in Fig 1, and the paper space output shown in Figs 2 to 6.

Fig 1: Model Space output of script.

Fig 2: Paper Space output of script. Footing plan showing stiffened raft (not typically required).

Fig 3: Framing Plan & Member Schedule

Fig 4: Side (Front) and End Elevation (Right)

Fig 5: Side (back) and End Elevation (Left)

Fig 6: Detail Section of Portal Frame

At present the script doesn't modify the paper space layouts to match the paper size. This is largely because in the first instance it requires using "print" and adjusting the layout parameters and then cancelling the print command. It can crash if invalid paper size names and printer names are provided, so it was left out. Text is all placed in paper space, with exception of the grid labels which are written in model space. The input parameters allow varying the paper size, the scale, and forcing either one view per sheet or everything to a single sheet. The scale can also be selected to be calculated. Either way the vba macro will determine one of a few different preferred layouts, and attempt to use as few sheets as possible. All the parameters to define the structural frame can be varied. Spacing of frames, girts and purlins are assumed to be constant. Except for the simplest of buildings, usually after the script has run a great deal of manual editing is required to produce finished drawings for development approval.

Fig 7: Screen Capture of Time Script Takes.

As can be seen from the screen capture, Fig 7, the script takes less than 9 seconds to run, this is significant decrease on the 5 to 20 hours that may be required for drawing such stick diagrams from scratch. Another 5 to 40 hours may be required for drawing connection details and other relevant detail sections. Given that the shed industry typically does not produce formal drawings, only a freehand sketch on square ruled paper order form, taking some 10 to 60 minutes whilst salesperson talks to customer: collapsing the drafting time is important. Whilst the freehand sketch is suitable for a small garden shed, its not suitable for a 4000 sq.m industrial warehouse with office space. But people go to the shed suppliers on the assumption that they have solved all the problems before and have standard designs which can be modified. Whilst the industry advertises custom manufacture it cannot provide custom design. The industry relies heavily on the local council, requesting further information, before they go and get architectural and engineering input. This results in delays for the customer as issues of  non-compliance with building codes are resolved.

Whilst high end building information modelling (BIM) software may be useful for the task, it is too complex for sales people to be using at the point-of-sale, and with costs from $5000 to $25,000 (AUD) per license it is also far too expensive. {Though any shed supplier setting up own engineering staff and making  use of such software, has the potential to make it financially viable, taking advantage of the software to improve their product and increase sales.}

Whilst the suppliers run around from one consultant to another, requesting standard designs for one shed or a range of sheds, there is a need to develop low cost, highly product specific software which produces drawings, and structural calculation reports, along with material take-off's,  cost estimates, and work shop details, along with any CNC machine instructions if appropriate, to resolve the problems of not using standard designs correctly.

There is already precedent for such software with the nail plated timber roof truss manufacturers, however their software started in the wrong direction: it failed to provide adequate evidence-of-suitability and was proprietary. This made it difficult for council to check the adequacy of the proposed trusses, and there is still need for improvement, but there is now a guide line for such software, put out by Planning SA.

Minister’s Specification: SA A2.2 : Structural engineering software

The problem with such software is that it tends to only produce specifications, and it can do so in a short period of time, a few minutes. Compare this to a few hours to check all the different roof trusses in a typical house, using either manual methods or standard frame analysis software. It seems no consultants providing technical certification services has automated their standard frame analysis software for checking timber roof trusses. Similarly they also haven't produced automation for sheds, carports and verandahs. So the industry can do fast, but the checkers and certifiers are slow. The big question though is the industry fast because its not doing engineering checks, or because it has fast design tools, and have those design tools been checked and are they being used correctly. Hence developing and releasing the software not just a matter of writing source code. Hence these things tend to get part developed as useful in-house productivity tools rather than commercial products. But not everyone has the time to develop such tools in-house, and that causes hindrance, and delays, when at the certifier level. So tools need to be readily available to all, not just limited to manufacturers, possibly under a GPL, so that source code viewable by all.

Any case primary task at moment is to reduce the drafting effort, since calculation effort has largely been reduced already for the typical gable frame shed.

---

Related Posts:

Cold-Formed Steel Shed Industry: part:#1

Cold-Formed Steel Shed Industry: part:#2

Cold-Formed Steel Shed Industry: part:#3

PEB, PEMB, PMBS Cold-Formed Steel Sheds and Canopies #pt2

Height Versus Span Design charts for Steel Sheds

The Section Weights ...

Weight of Steel does Matter?

Kleinlogel Rigid Frame Formulas

Manufactured Structural Products And Simplified Wind Classification

Other Blogs:

Shed Design: pt#1 (Basic Procedure

AutoCAD Speed Test

As a simple test of the comparison between speed of manual CAD drafting and scripting (*.scr), a simple test can be carried out. This test comprises of drawing a rectangle and then diagonal lines and bisectors of the sides. All entities should be ordinary lines, no polylines or rectangles, and no drawing as such and exploding to ordinary lines. Running osnaps can be switched on to save time. I typically have osnaps switched off, it interferes with running scripts, and otherwise tends to waste time in manual drafting selecting the wrong points, so I typically select snaps manually, the right one at the right time. Anycase for the test I used running osnaps, because it is a situation where it clearly provides benefit rather than an hindrance. The dimensions of the rectangle are @10000,5000.

It should be noted that the larger the screen the longer the distance to travel from one corner to the other and therefore the longer the drawing time. So larger screens not altogether a benefit. Faster times can be achieved by reducing the size of the AutoCAD window, or by zooming to a fraction of the screen (eg. zoom 0.5x).

Fig 1: Screen image of finished drawing test.

{NB: click image to enlarge and scroll all images.}

Fig 2: Screen capture of time taken for manual drafting

The time taken with manual drafting is approx 26 seconds. With practice it may be possible to get the time down further. Starting out today it took 55 seconds, but for some reason I was typing the command "Line" rather than using the alias "L", also wasn't using running osnaps. But since I knew last time I did the test I did it in 26 seconds, I kept trying until could capture such time from screen. Faster  computers and faster operators may be able to get lower times, but unlikely to achieve the less than 1 second that the script takes to run.

Fig 3: Screen capture time taken by script, drag and drop onto CAD drawing.

Fig 4: Screen capture time taken when macro added to a toolbar button.

Not sure why but the script runs slower when called from a toolbar button than when script file is "drag and dropped" onto the drawing. However the button saves operator  time finding the script.

The script:

;---------------------------------

TIME RESET

LINE 0,0
0,5000
10000,5000
10000,0
C
LINE 0,0 10000,5000

LINE 0,5000 10000,0

LINE 5000,0 5000,5000

LINE 0,2500 10000,2500

ZOOM E
ZOOM s 0.5x
TIME

;---------------------------------

The button macro:

'_script speedTest1.scr 


Faster computers and larger monitors save time, but only when there is a great deal of interaction between the operator and the machine. To really save time and increase productivity need to get the computer to do the work, and a slow computer may be adequate for such purpose. If it takes a person 2 minutes to enter data, and the computer 1 second to respond, it does not make any perceptible difference if get a computer twice as fast to complete its task in 0.5 seconds. Its the 2 minutes of human interaction with the machine that needs to be reduced: and that is likely to become a political issue. There has to be some acceptable need to reduce the production time before effort gets applied to do so. After all what are you going to do with the free time if just reduce production time just because you can.

Related Posts:

Programming/Automating #Autocad LT
Automated Drawing List Update Acad LT (revised)

Cold-Formed Steel Shed Industry: part:#1 (Shed Framing Drawings)
Cold-Formed Steel Shed Industry: part:#2 (Shed Framing Drawings)

Programming/Automating #Autocad LT

As far as I am aware the main reasons for opting for the full version of Acad are:

1) AutoLISP
2) COM automation
3) Database connectivity and SQL
4) Extended data
5) Complex entities/objects, 3D and otherwise

The seemingly most dominant reason that full Acad is chosen is because it is programmable through AutoLISP. The common myth is that AutoLISP is required to program AutoCAD. Since AcadLT does not have AutoLISP it is not programmable or customisable. Wrong!

AcadLT can be customised and its is programmable without any tricks or add-in LISP engines. Forget about the pretty toolbars, AutoCAD has a command langauge, and supports script files for those commands. The command language and script support is not as powerful as that in say the old DBase II/III, but it is none the less available.

The common criticism aimed at scripting is that it cannot do anything. For example to draw a line, the script would be:

Line 0,0 1000,1000

where as in AutoLISP it would be:

(command "line" pt1 pt2 "")

Where pt1 and pt2 can have any coordinates desired, thus the AutoLISP script can draw different lines, whilst the command script can only draw one line. However, the AutoLISP script is part of a much larger program which determines the values of pt1 and pt2, and instead of sending instructions to the Acad command line, it could equally well write the instructions to a file as follows:

(write-line (strcat "LINE " (ptstr pt1) " " (ptStr pt2) " ") fp)

Where (ptstr) is a user written function to convert the point coordinate lists to text strings, which can be written to a file (fp). The resultant plain text file can then be excuted from within Acad or Acad LT via the run script command. For simplified usage the script can always be written to the same location and file, such as default.scr, and this script can be executed from either a menu macro or toolbar button: once again in either Acad or Acad LT.

'_script default.scr 

Now such plain text files containing Acad command line instructions can be generated by any available programming language. On old MS DOS machines the most readily available programming language was GWBASIC, but other high level programming languages like Turbo Pascal and Turbo C may have been available. In the world of Windows XP and higher, every machine has available windows scripting host and can run VBscript or JScript.

For example in VBscript, can replace the AutoLISP instruction with:

fp.WriteLine("LINE " & ptStr(x1,y1) & " " & ptStr(x2,y2) & " ")

However most offices have MS Excel installed on most machines, and a few may have access to MS Access, in which case vba can be used to generate scripts. Script instructions can be generated in an Excel worksheet then copy/pasted into a text file, and run by the script command, alternatively the instructions can be pasted directly to the Acad LT command line. Similarly queries in MS Access can be used to generate a sequence of script commands either pasted to a file or direct to the Acad Lt command line. This approach is useful when converting simple data into graphics.

Example of Coldformed steel section generated from script pasted to Acad command line, from Excel worksheet. Worksheet can be found here.

For more advanced automation Excel/vba combination provides the means of collecting input in the worksheet and then writing a script file based on this worksheet data. In vba the typical script would be something like:


Print #fp, "LINE " & ptStr(pt1) & " " & ptStr(pt2) & " "

Where pt1 and pt2 are coordinates stored in a data structure as follows:

Public Type TCoord
  x As Double
  y As Double
  z As Double
End Type

To avoid keep writing the instructions for a line the following subroutine can be defined and used.

Public Sub write_line(fp As Integer, pt1 As TCoord, pt2 As TCoord)
  Print #fp, "LINE " & ptStr(pt1) & " " & ptStr(pt2) & " "
End Sub

call write_line(fp, pt1,pt2)

Similar subroutines can be written for other commonly used Acad LT commands. By building a library of such commands, it is possible to simply convert the program from one CAD package to another simply by rewriting the library to suit the CAD package. That is the main program written uses the users own subroutines and data structures, and should never need rewriting, but the library can be converted to use the data structures, objects and methods of a chosen CAD package. For example write libraries for scripts, DXF, Acad COM automation, TurboCAD, DesignCAD, MultiFrame, even the Excel shapes layer.

Now the problem with the script is it cannot select Acad entities, nor points. Many AutoLISP routines simply pick a single point on the screen then generate a parametric detail about this point. Most of the time (0,0,0) is a good enough start point and a new file is the place to start drawing, therefore no point needs to be selected. By generating a new file, and using xref to reference this file into the primary drawing, interaction with the Acad drawing editor can be minimised. Unless using handles and links to an external data base it is seldom necessary to modify entities. The primary objective is to automate drawing production, not interact with the drawing editor. If a full set of drawings for some parametric object can be generated in a few seconds there is no need to revise or modify the previous: simply regenerate using the modified parameters. Further more if critical parameters start out in Excel and are used to generate a drawing, then there is no need to extract such information from the Acad drawing database.

Interaction with the drawing editor is not highly productive, nor are dialogue boxes. A common flaw with AutoLISP routines is that they have dialogue boxes collecting mutiple parameters. The number of parameters collected by these dialogue boxes exceeds the number of parameters used by engineering. The problem is that engineering calculates the other parameters, used to specify a part. Due to the division of labour between drafter and engineer: the drafter draws and the engineer crunches numbers, there is consequently a lack of integration in the design activity.

It is more productive to write the AutoLISP routines without dialogue input boxes, rather write as subroutines requiring passing of parameters. Then write additional subroutines using dialogue boxes to collect the parameters and call the routine which does the actual drawing. The reason for this is so that the drawing routine can be used in much larger drawing application. Just as machines and buildings are made from component parts, also is a drawing using blocks and xrefs, and similarly a computer program using functions and subroutines. Just as blocks simplify building large drawings, so to do subroutines simplify writing large programs.

The first use of a drawing subroutine, may be to call it from a routine using dialogue boxes to collect all the drawing parameters. A future use may collect far fewer drawing parameters and calculate the rest. But of far greater value is the potential to string multiple subroutines together in sequence to draw something much larger and more complex from a few simple parameters.
Similarly, if this can be done using AutoLISP it can equally well be done using Excel/vba and the generation of scripts. What is more without the use of Acad or Acad LT, an engineer or other designer can generate a series of scripts in a common location, these scripts are then executed by the drafter using either Acad or Acad LT.

Excel/vba can also be used to grab a list of files, either drawings (dwg), DXF and then execute a set of script commands on each of the drawings. Similarly vba can get a list of scripts, and combine them into a single script to be launched in Acad LT. An alternative approach is to execute each script one at a time by calling Acad LT with command line switches, unfortunately with Windows multitasking causes a a timing problem. It is however the approach that was taken with Acad when using MS DOS. It was the failure of my Turbo C multiScripting program in Windows using Acad LT which led me to experimenting with generating scripts using QuattroPro spreadsheet with which I could easily grab a list of file names.

To launch Acad automatically from an application and run the script call Acad using command line switches, for example.

"C:\Program Files\AutoDesk\AutoCAD LT 2000\aclt.exe" /b default.scr

This can be configured in an Excel worksheet, so that can vary CAD applications used and the script names used. More samples can be found here.

Here is some sample output generated by scripts (*.scr).

From a few parameters steel framing plans, elevations and section for simple building generated in model space and paper space, all text with exception of grids placed in paper space. The above view shows the model space 2D stick diagrams, and the lower view a close up of the framing plan.

The following was originally written using DesignCAD, generating a 3D stick diagram of a shed, but then translated to use Acad scripts and draw more detailed elevation.

Simple stick diagram above. Below, model with detailed elevation, and permitting any number of spans.

The following is a close up of the knee connection.

A limitation of Acad Lt is not being able to generate 3D elements. I have used Lights for analysing tension membranes, and whilst it generated an Acad Script file, I was unable to run the file in Acad Lt since it could not create the 3D face elements, whilst intelliCAD 2000 used a different set of parameters to draw 3D faces so the script was incompatible. I therefore modified my Acad script library to use the intelliCAD COM objects. To produce the following, which is viewed in Acad LT.

I could have written the program using scripts in intelliCAD, but I used the opportunity to try out COM automation. The program reads the results from Lights, and then shades membranes elements in tension green, and elements in compression red. It is all on layers, so the membrane can be switched off, and the tension and compression elements of the supporting cables can also be viewed.

Another use of scripting is a simplified geographical information system (GIS). The following made use of MS Access, which was used to count the number of projects in a given area: mainly a UBD map. This data was then transfered to Excel, where a vba macro further sorted the data and generated a script which inserted a block on the appropriate layer. Red blocks represent areas with most projects, and paler blue blocks represent areas with least projects.

Each square represents one map from the UBD Adelaide street directory. The vba routines translate UBD map grid references into Australian Map Grid (AMG) coordinates so that can be located in Acad by (x,y) coordinates. In addition to the coloured blocks. circles were drawn at more localised positions, with the size of circle reflecting the number of projects in the area. The reference grid on each UBD map is about 250m x 250m, so objects typically located at the centre of these grids. For many things don't require the use of a fully blown GIS, since only concerned with relative distances between locations. For example nearest neighbours and hinterlands, or catchments of common facilities like shopping centres, hospitals, business competitors. The map shows that a lot of our work is dependent on the North East Road. It doesn't show projects outside the metropolitan area spread around the state and the country, and the occasional few outside the country. For an alternative GIS can take a look at MapMaker gratis this I have experimented with to generate contours whilst in the trial period with the professional version. The contours being for soil heave, caused by reactive clay soils. We have collected lots of bore logs over 16 years, and therefore, it should be possible to produce a contour map. At the moment I don't have subroutines to generate contours, but have found routines for generating Delaunay triangles, though generating Voronoi polygons would be even better for assessment of catchment areas. This far have written Acad scripts to do the triangulation, the rest is for a future date.

Any case if automation is the primary objective, and doesn't involve creation of 3D entities, then Acad LT can be used to automate a considerable amount of 2D work, or if stick diagrams are all that is required then it can also automate 3D models.

Recommended Reading
1 Microsoft Press (1997),"Micosoft Office 97 Visual Basic Programmers Guide", Microsoft Press
2 Jim Boyce, et al (1997), "Using Microsoft Office 97 Professional: Special Edition", Que
3 George Omura (1989),"AutoCAD instant Reference", Sybex
4 C W Sharp and W W Hamm (1989),"AutoCAD Advanced Techniques",Que
5 D Raker and H Rice (1990), "Inside AutoCAD: 5th Edition (metric)",New Riders Publishing
6 J Smith and R Gesner (1989),"Customising AutoCAD: 2nd Edition",New Riders Publishing
7 J Smith and R Gesner (1989),"Inside AutoLISP",New Riders Publishing
8 George Omura (1990),"The ABC's of AutoLISP", Sybex
9 Dennis N Jump (1989), "AutoCAD Programming", TAB Professional and Reference Books
10 AutoDesk(1995),"Users Guide: AutoCAD LT Release 2 for Windows",AutoDesk
11 Acad LT on line help system.
12 Burchard, Pitzer, Soen, et al (1997), "Inside AutoCAD 14", New Riders Publishing
13 AutoDesk(1999),"Getting Started: AutoCAD LT 2000",AutoDesk

Related Posts:

AutoCAD Speed Test
Automated Drawing List Update Acad LT (revised)

Cold-Formed Steel Shed Industry: part:#1 (Shed Framing Drawings)
Cold-Formed Steel Shed Industry: part:#2 (Shed Framing Drawings)