Plane Frame Analysis : The Back End

As mentioned in discussing the Front-End, the development of the back-end for frame analysis is of secondary importance, as it has been relatively well catered for by the off-the-shelf structural analysis software. For example software like MicroStran and Multiframe have two options concerning sizing of structural members, and these are:

1. Check
2. Design

The "Check" option carries out an assessment as to whether the currently set structural sections are adequate for the action-effects generated by the applied loads, and otherwise gives some indication of the efficiency of such sections. The designer can then adjust some sections in an attempt to get more efficient sections, and run the analysis again and check adequacy. The designer can repeat this until they are happy with the result.

The "Design" option automatically finds the most efficient section for each member, the designer can then opt to use these sections or not. Typically adopting the results of using the "design" option is highly impractical. Consequently the results of the "design" option are just used as a guideline for manually changing some of the members but not all of them. Therefore some human interaction is required to reach the final design selection.

Additionally little of the available software has integrated options for connection design and footing design, this is typically all done external to the program. Also as previously mentioned the 3D geometric model is not necessarily a valid structural model, and therefore there are other components designed external to the analysis software. Some 3D structural analysis software explicitly optimised for buildings, allows components to be modelled graphically but excludes them from the 3D structural analysis and treats the components separately in the manner most appropriate for such components. Thus allowing everything to be modelled visually but with out creating an invalid structural model.

For manufactured structural products (MSP's) typically expect:

1. Reduced parameter set
2. Reduced set of components

For example cold-formed steel sheds and carports made from c-sections and employing rigid portal frames, typically have such frames at 3m centres. The frame spacing is thus one parameter which is rarely changed and when it is it is usually reduced. This is because the C75 typically used for girts and purlins is barely capable of spanning 3m: however it wastes little floor space compared to larger sections fastened to the face of columns. The roof pitch is also typically locked. These things often need to be varied but are not in the scope of standard calculations typically held by suppliers, hence the desire for software to allow such variation.

With respect to a true MSP, there is no real need for structural analysis software. Often the issue of analysis versus lookup tables arises, with look up tables being considered inefficient. It is incorrect to conclude that look up tables or databases are absolutely inefficient for the task. In fact there is a good chance that structural analysis is the wasteful inefficient option.

If have something like the span tables of the timber framing code (AS1684) or the girt and purlin load capacity tables for c/z-sections: then for certain automating looking up values from such tables is likely to be inefficient if it is based on simply building a database containing the printed tables. Similarly it would be inefficient to place the span tables for steel carports and verandahs into a database. If look at cold-formed steel sheds then the manufacturers typically have an ad hoc random collection of standard calculations with no rationale behind them: the calculations are of little use to anyone other than for annoying the customers with a failure to have anything compatible with their needs.

Rather than a database of values, the real need is for a database of constraints which can be readily attached to the input boxes on data collection forms. The MSP's are meant to be pre-engineered, thus all the engineering is expected to be done already. The engineering can therefore be used to define constraints and associated solutions and the software can therefore run a lot faster. In other words instead of searching through all the available structural sections to find one that works, from the very start already know what the minimum suitable section is. We know the capabilities of the smallest available section, and also know the limitations of the largest available section. So it is not necessary to carry out structural analysis at the PoS to identify that a proposed building is beyond the scope of the typical cold-formed steel structure, and requires significant custom engineering to make it feasible using cold-formed steel. {eg. We recently designed 32m span x 8m high using Fielders largest Dimond sections. The section is not adequate in it's own right and therefore had to be reinforced with steel flat bar and folded channel. Therefore feasible but not something would get the salesperson to do whilst chatting with the customer at PoS. This is not a Fielders shed, it is just using their materials.}

The database doesn't need to be massive. Further if talking about large databases, then the structural drawings and structural model especially if in 3D represent an extremely large database. Whilst the analysis of a 3D structural model is typically very fast, the automatic sizing of the members by the software can be painfully slow. The earlier versions of MultiFrame for example were extremely slow compared to MicroStran when it came to running the "design" option: now they are about the same, with MultiFrame having got faster. This I expect had more to do with MultiFrames complex multi window user interface than with the algorithm operating behind the scenes. So opting for analysis does not reduce the size of the database, nor does opting for look up tables increase the size of the database. The structural product needs to be looked at carefully, and if it hasn't really been designed that's going to be difficult.

For example each available cold-formed c-section has a maximum achievable envelope which it is suitable for when used for a simple gable frame. Once that section has been selected for a proposed building the connection components and footing system are also largely determined. Therefore only really need to know what the defining envelope is for each c-section. A simple data input form can then automatically update based on constraints in response to simple inputs. Depending on the structural product could all be done by an extremely simple and small Excel spreadsheet.

However all the engineering for the product needs doing first before any such constraints are available and the building industry is not really into being proactive and designing a product to satisfy the needs of a market, it is instead highly reactive only responding when it bumps into and trips over the customers needs. On the other hand if they did decide to be proactive and went to a consulting civil/structural engineer to get a MSP designed they would bump into a series of problems: that's why the manufacturers typically hold a random collection of structural calculations obtained on an as needs basis. An infinite number of points along a line segment of any length, leads to an infinite number of standard designs being required, which is not practical therefore seek software so that parameters can be varied on an as needs basis. Most manufacturers however are too small to pay for development of such software, and also seemingly too small to pay for product development.

My view however is that they could pay for product development if they employed engineering associates on staff and made use of off-the-shelf software. They develop the product in small steps and otherwise provide higher quality service to their customers, by having engineering capability on staff rather than hoping some external consultant is available at the time required.

If focus on product development and having a product available which meets the needs of the customer, then the PoS software can be kept simple and all the design and engineering done in the back-room prior to customer enquiry. The real objective is to predict accurately, what the customer wants, and have it available already, not ask them what they want, and supply at some future date.

Therefore the back-end of frame analysis is of secondary importance as there is now a diverse range of structural analysis software available which can be used for sizing members. Where little effort has been put is auto-generating the structural model: with geometry and loading. This is because the focus for high end software is dealing with geometry which comes from an architect and having to transform this into a structural model.

For MSP's we are only concerned with the structure, therefore more able to generate geometry and loading. The importance of this is that at point of generation we know that a certain structural element is in the roof or the wall and therefore know what loads to apply to it automatically.

For the architecturally defined geometry, do not know that a beam is in the roof, unless it carries additional data which can be interrogated, so that can apply the correct load to it. CAD operators find putting lines on the appropriate layers cumbersome, and commands designed to ensure that entities have the appropriate layer and other attributes even more cumbersome. So the possibility that all elements in a building information model (BIM) are all tagged correctly to allow automation tools to work correctly is relatively low.

For a MSP however everything is supposed to be predefined, and therefore we have far greater potential to auto-generate the structural model. If we can do that then there is plenty of software available for what I have labelled the back-end of frame analysis. Developing a back-end is therfore not something I wish to give priority to, as all this other software provides the needed independent check on the design of the structural product. I have MicroStran and Multiframe licenses explicitly for the purpose of checking one against the other. Most of the time only use one package, but when strange things occur then build models in both packages and check one against the other and hunt down causes of variation if any.

With an auto-generated structural model and a large variety of software available to carry out the frame analysis and size the members, there is reduced potential to question the validity of a manufacturers MSP, as there is potential for a large number of independent checks. The structural model is not hidden in some obscure software owned by a manufacturer. Further the suppliers of the general purpose frame analysis software will be under increasing pressure to further develop the back-end capabilities of their software as their software will be the ultimate bottleneck in the whole process. So why expend effort re-inventing the wheel? These software developers already have 80% or more of what is required for the back-end of frame analysis, let them add the missing features.

The current major bottleneck is building the model for use in the available software when it comes to the common structural forms of the MSP's. However some manufacturers may be better served by a stand alone structural analysis package with integrated back-end highly customised to a specific MSP.

Simple Back-End

Therefore to provide for experimentation with the back-end of frame analysis I have thrown together a simple MS Excel template. The template just has a single button which reads the results file generated by cpframe and writes them into the cells of a single worksheet. Once the results are inside a worksheet, they can be linked to other cells which are used for the sizing of members, the checking of connections and the sizing of footings. To deal with multiple load cases however it would be better to read the results into an array and process all the load cases using vba. It would generally be preferable to avoid performing calculations in a worksheet unless a relatively tidy presentation can be developed: as the number of structural members and load cases increases, such becomes increasingly impractical.

I see both the front-end and back-end being developed entirely in vba or other programming language. Whilst it is possible to do the calculations in the worksheet it just becomes increasingly prone to error and a nightmare to manage. Why repeat a calculation in 10 cells by copying one cell, when can write the formula once and place in a loop and be sure all 10 calculated results are based on the same formula at all times. Copying cells is prone to unexpected changes in cell references. Such changes may be easy to spot after the fact, but not always fresh in the users mind when they are copying the cells.

Worksheet calculations are useful for checking the operation of vba code and otherwise testing and breaking vba functions by attempting to supply invalid data. For example testing a function for the case of division by zero, has it been covered? What other inputs can break the function? All easier to test grabbing input parameters from the worksheet. Whether actually does work when called from vba is another matter, as the features available to handle errors in a worksheet cell are not valid when executing solely with in vba.

Anycase the back-end template is:

backEndPFrame.xls

DISCLAIMER :
Users of the software must accept this disclaimer of warranty :
The software is supplied as is. The author disclaims all warranties, expressed or implied, including without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of the software.

---

Revisions:
[04/02/2014] Original

[23/04/2016] Changed download links to MiScion Pty Ltd Web Store

Plane Frame Analysis: The Front End

The Plane Frame analysis command line application previously released, is typically expected to be used for developing and testing a larger application which would comprise of the following:

1. Front-End which auto-generates the structural model (the data file for cpframe).
2. cpframe
3. Back-End which obtains the results from cpframe and then uses to size members, check connections and size footings

My primary focus is on the front-end as there is plenty of structural analysis software out there which already integrates the structural analysis function of cpframe with the back-end functions of member sizing, though little software available for checking connections and sizing footings with in the structural analysis software. The available structural analysis software also typically has facility for auto-generation of the dimension and geometry for common structural forms. Very little of the software however will auto-generate the model with loads applied: and that which is available doesn't cover Australian standards.

With respect to manufactured structural products (MSP's) there are at least 3 issues for structural design software, and these are:

1. Rapidly analyse and specify structural requirements and generate cost for at the point-of-sale (PoS) and to be used by sales people and customer.
2. Provide adequate documentation for seeking development approval (building permits)
3. Aid independent checking and/or testing

The latter issue is important because without adequate consideration it becomes necessary to generate an unnecessary amount of documentation for seeking development approval for each and every project. MSP's are made in large numbers, if the structure was adequate last week, and barring any major changes in codes of practice, then it will be adequate this week and next week. To churn out documentation in the form of a thick report for each and every project becomes silly. The report needs to be kept, as far as possible, to a single page certificate: but we need independent means of checking the validity of such certificate.

Since most software for rapid design of MSP's is restricted to use by the manufacturers and their sales agents, no consulting engineer charged by local councils to do an independent check can rapidly generate a design model for use in general purpose structural software. Checks would involve the following:

1. Relevance of the software or structural model to the proposed building structure
2. Validity of the input parameters to the model
3. Validity of the calculated results

Similar checks are also required  by consulting engineers employed to check and certify the software. However whilst such software may require to be certified, such certification doesn't mean the software is relevant to the projects it actually gets used for in its day to day usage. The authors of such software also need to be conducting such checks and tests.

To my mind it has never been a simple matter to just dive straight in and start writing software for a manufacturer. The first stage should be developing tools which assist with the independent testing through the use of general purpose structural analysis software. To start with the engineers typically asked to provide such software usually start out by providing the engineering, so they need tools to provide rapid feedback to their clients. {NB: This not the case of designing a building for an architect and come back in a week, the feedback needs to be in around 30 minutes. In 24 hours the customer could have gone else where got a price for a building and placed an order.}

Unfortunately the manufacturers typically want to start putting software to use immediately, and once they do they will start hitting into projects which are beyond the scope of the software. The engineer will then have to deal with these variations in rapid time frames. So this situation reinforces the need to have an interface to general purpose structural analysis tools, so that the custom variations to the MSP can be easily handled externally to the manufacturers software.

Now given that MicroStran is popular general purpose structural analysis software, and its text based '.arc' files are a common import option with other software, then auto-generation of MicroStran '.arc' would the more productive option to adopt for the design office.

However developing a front-end to auto-generate structural models for MicroStran is not useful with respect to developing the software required by the manufacturer of MSP's, as MicroStran is not available as an analysis engine for integration into other software.

Therefore need to pursue parallel paths:

1. Auto-generating models for a structures engine
2. Auto-generate a model compatible with general purpose structures software.

Since we have MicroStran and MultiFrame licenses I will be developing auto-generation of models for these two packages along with models for our structures engine (cpframe). In the first instance I will focus on models for use with cpframe, as engineering graduates have the greatest potential for writing model generators and they don't necessarily have access to the commercial software packages.

It is also to be noted that most consulting engineers have little interest in auto-generation of structural models, as they mostly work with architects and have to fit a structure to a building, where as with MSP's the building is fitted to the structure. So most consulting engineers will be increasingly moving towards use of building information models (BIM) as such becomes more affordable and practical. However BIM forces the use of 3D models, and 3D structural models introduce a multitude of problems with respect to realistic modelling of the real structure. There are components in building structures which cannot be modelled correctly in general purpose 3D structural analysis software. If these components are left out, say girts and purlins for example, then no longer have a single 3D structure but a series of isolated plane frames. These 2D plane frames are largely the same, therefore wouldn't waste time modelling all of them, just the most heavily loaded frame and make them all the same. This is important for PoS software, as the computer has to wade through all available components and find the ones which work: where as an experienced designer would start off with a reasonably good guess and would only need a few iterations to find the best solution from the available components. In short at present BIM is too expensive, and the 3D graphical model has little relationship to engineering models across all disciplines, and a lot of extra work is imposed for no benefit. Any case for these engineers auto-generation of the structural model is of little value, as the primary requirement would be to auto-generate design actions applied to the dimensional and geometric model created by the architect. For such situation, idealistically want the structural model, the design actions applied, as the architect designs the building. For example the architect inserts a floor, defines its purpose and the floor structure is automatically generated. The structural engineers task being to tweak the model and advise the architect of changes to make. Ultimately the architect should be able to remove a column and the beam supported would turn red identifying as no longer suitable and in need of re-sizing. That is 80% of the expert advise the architect needs would come from the software the remaining 20% from specialist consultants. It is to be noted that often architects have difficulty finding engineers who are capable of realising the proposed the building, and so the buildings get reduced to the pinned and braced boxes which are in the capabilities of the available engineers. {NB: Whilst an engineer may have studied some theory or be able to pick up and read literature on new theory or rarely used theory, it doesn't mean they are confident or willing to apply such theory in the real world. So in the first instance computer software allows those who can to enable those of lack the confidence to go it alone. Such software however provides a foundation for enabling and empowering everyone, instead of building physical prototypes and testing, they use the software as the test bed.}

So with MSP's we are dealing with standardised structures and the proposed building has to fit the available MSP. The structure therefore takes precedence over the building design, the designer has to fit their building into the envelope provided by the MSP. The designer is typically the owner who has decided that an MSP is suitable for their purposes, and who otherwise wants to avoid the delays caused by architects and engineers. Unfortunately they typically miss the delays which will be caused by expecting a sales person to provide design for the custom features the buyer desires. An engineer being called in at the last minute when everything has been rejected by the local city council. Since the engineer can be any available engineer, such engineer first has to get up to speed with the manufacturers product. Which will turn into a hassle as the manufacturers don't really have product specifications, or spew forth a lot of nonsense about intellectual property (IP). If they had any real IP then they would have patents, and if they have patents, its public knowledge. In the main they have no real product, no product manager, and no product development manager, and an over willingness to sell what ever the customer asks for. Hence their desire for software to do the design to the customers requirements at point of sale: but do the design and engineering for what? That is something they have no idea about, except the unrealistic expectation: anything the customer asks for.

Clearly developing an auto-generator with the flexibility to generate a structural model for anything under the sun is a major undertaking if not impossible. To achieve that would require some form of scripting or modelling language to define a new structural form without going back to source code programming. There would still need to be development of a new interface for the user to incorporate the new MSP, it wouldn't be something done at PoS whilst talking to customer. {NB: MicroStran as a macro language for auto-generation of complex geometry: as I remember spirals and such. I never really used it, its limited, and its a variation of the .arc file, it just removes the need to define all the nodes and connectivity of such.}

So whilst there may be flexibility in the background behind the scenes, in the foreground there is necessary restraint on what the salesperson and customer can do. Otherwise could simply use BIM type software at PoS and feed into the back office for engineering at some other time after PoS. The whole point of MSP's is that such structures are as close as possible to being off-the-shelf buildings with a fixed price and comparable from one supplier to another. Too much variation and its no longer an MSP. A car is pre-engineered, you cannot go into the showroom and ask for it to be supplied with 3 wheels instead of the standard 4: such variation imposes a need for extensive engineering which includes building of prototypes and physically testing that mathematical models are valid and not overly unrealistic. Choosing whether to have a radio in a car or not doesn't typically impose a need for additional engineering. Putting a window in a shed doesn't impose a need for engineering, placing a door in a shed which is wider than the spacing of the frames imposes a need for engineering. Placing a building in a wind loading environment it wasn't originally designed for imposes a need for additional engineering. Most of this structural engineering is little more than calculations to codes of practice. Not all of the engineering however is within the scope of calculation and some physical testing is often required. Hence the importance of defining the product before writing the software. 

Software is also a product and it should also be designed before being written. However it is recognised that the manufacturers just want to get on with manufacturing. You don't get the full technical drawings and specifications for a car, but then again the customer is not permitted to make changes to the car which would require such information. The building industry does permit making changes which requires the additional information, and therefore they need to make it available: which is extremely difficult if they haven't produced it.

There is a lot of up front work to do before software the likes of MicroStran or Multiframe can be put to use. Most MSP's are well within the capabilities of Australia's 2 year qualified Engineering Associates to design and assess, and such persons are likely more compatible with the needs of the majority of the manufacturers than professional engineers. So if the structural models for the MSP's can be auto-generated and be compatible with commercial structural analysis software, then the engineering associates can handle custom variations in house, a lot more rapidly than queuing up for assistance from a consulting engineer. If such personnel can be employed along with appropriate software then the need for PoS software would be slightly reduced, because going to the manufacturer would still be faster than going to an architect and then going out to tender.

So would say we are looking at:

1. PoS design solutions in no more than 5 minutes during at most a 30 minute interview.
2. Behind the scenes solutions in less than 24 hours: same day response.

The latter can be achieved by semi-automating the readily available general purpose structural analysis software. The former requires full automation at PoS, and requires highly specialised custom software.

In the first instance therefore I would recommend semi-automating the readily available software and employing the right people on staff. Such tools would enable all consultants and increase the number available who can deal with custom variations to MSP's, including future extensions, and who can test and certify the more specialised software, and otherwise independently check and certify individual building projects. Diving straight into the specialised software owned by the manufacturer and only available to their sales distributors just creates a lot of hassle for everyone else involved

Internally to an application which auto-generates a structural model it doesn't really matter what structural analysis software is used. That is the difference between generating a model for cpframe or MicroStran is simply a matter of file format: the data required for the files is the same. Therefore a model generator written for cpframe if written appropriately can be easily adapted to a multitude of general purpose frame analysis software by writing an appropriate file export procedure. The principal task of generating a model already completed in the main body of the application.

An MS Excel Template for cpframe.

The simplest, though not very practical, means of generating a model for cpframe is to use MS Excel and perform all the calculations in the worksheet and connect these to a summary sheet which as the appropriate format for writing to a cpframe data file. To such end I have thrown together a template for such purpose called frontEndPFrame01.xls.

frontEndPFrame01.xls

As its a template file it doesn't actually do anything. The template merely provides a worksheet which can be adapted to suit various structures by adding extra data rows as required. Buttons are provided to write the contents of the worksheet to a data file compatible with cpframe, and then run a shell to execute cpframe to generate the results file. As the application is procedural, can be reasonably certain that the data file will exist before the next command is executed, therefore these tow buttons can be combined into a single command button: with the data file being automatically generated and passed straight to cpframe. On the other hand cannot be certain the results file is available, before the next command executes, as cpframe may still be in process. Therefore have to have a separate manually executed task for viewing the results. This command merely opens the results file using Windows notepad.

As a test my gable frame spreadsheet can be meshed into the template. This spreadsheet calculates the wind loads on a simple gable frame, the same structural form as set up in the front end template. So just need to link the appropriate cells, such as the wind loads on the frame, into the the template data sheet. Since the spreadsheet already contains Kleinlogel formula for the frame, the results of running cpframe can be checked. Since cpframe can only handle a single load case at a time, conditional formula would be required to switch the load case the file is being generated for. This approach I took in 1996 using Quattro Pro (QPro and the original version of pframe. {Actually back then the program was called either f_wrk.exe or frame.exe, pframe was the name of my QPro workbook which drove the program}.

QPro pframe.wb1

As can be seen from the screen capture of the QPro workbook, it contained buttons for collecting data defining the structure, writing the data file for the plane frame analysis program,  running the plane frame analysis program, and then printing out the multitude of worksheets used to design all the various components of the whole building extending beyond the primary frame. To the right of the worksheet is a small table showing the load cases for the old permissible stress design, with a marker showing the current load case for which the plane frame data file is to be created.

Plane Frame Analysis Launched in front of QPro Workbook

With the original version of the plane frame application, I had to manually open each data file and run the analysis inside the plane frame application. With cpframe those steps are removed. Still with the original application that is how I manually incremented the heights of the structures until I broke the section desired to be used and then produced standard calculations for maximum height structure possible. {Stepping back of course to what did work. I also happened to know which load case was most likely to be the critical load case therefore I only need to increment height for one load case, and check other load cases when it appeared the maximum height had been reached.}

The QPro application never got fully converted to MS Excel for a variety of reasons: basically all the building blocks are there, just not connected up. Any case using the worksheet to do the calculations is not the most efficient way to do things. Its intuitive and fast initially, but cumbersome at later date when need to add additional members and load cases. It is better to use the wind load functions in schTechLIB directly in vba code using arrays, rather than reference the functions to carry out calculations in worksheet cells. Calculations in the worksheet cells are fine for presenting the calculations but a hindrance to more complex tasks.

Download frontEndPFrame01.xls

For a more flexible approach I will release an alternative template, with the data spread across multiple worksheets, making it easier to shrink and expand the structural models, and provide easily reading existing data files into the Excel workbook. Generating multiple models in the one workbook is not compatible with worksheet calculations. Multiple models is a definite move towards using vba or other programming language.

---

DISCLAIMER :
Users of the software must accept this disclaimer of warranty :
The software is supplied as is. The author disclaims all warranties, expressed or implied, including without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of the software.

---

Revisions:
[03/02/2014] Original

[23/04/2016] Changed download links to MiScion Pty Ltd Web Store

Testing Slide Show

Plane Frame Analysis with Graphics

I've now got the screen graphics back into plane frame application, which had been taken out to provide a command line application (cpframe) which can be run from with in other applications. This version I have named gpframe, for graphics plane frame its is still a DOS based application. When converted to run in Windows I will name it wpframe.

It can be called by typing the following in a command prompt:

gpframe

It will then bring up a menu system which will allow selecting a file. (The file name needs to conform with 8.3 conventions, as does the folder structure where the file is located. Which messes up using it under "Documents and Settings\user name\My Documents". The files also need to be in the same folder as the application as it doesn't support moving around folders: the current working directory. The things we now take for granted, though never really a problem in DOS as always worked in the folder where the files were, and called the applications via batch files.)

Opening Screen

Main Menu

Plot Menu

Geometry

Loads

Moment Diagram

Shear Force

Axial Force

Deflection

On first look I did think the deflections were incorrect, with an expectation that the whole frame would sway to the right, but a check with Multiframe indicates similar deflection at the nodes, with an inward pull towards the centre of the frame from both sides. Which is where the Kleinlogel formula and associated diagrams are a useful reference for checking influence of individual loads. The formula typically give a single direction of loading (vertical, horizontal or normal) on a single element of a frame. Unfortunately I don't have the book with me. So I'm guessing (well slightly better than a guess) the vertical component of the wind load on the central gable frame has the net effect of pulling the frame inwards and exceeds the sway that would be produced by the horizontal components of load on the whole frame. If the central span was smaller then the behaviour would be different. It is something which can be assessed by creating additional models of the structure and looking at the influence of individual loads.

It can be downloaded here.

DISCLAIMER :
Users of the software must accept this disclaimer of warranty :
The software is supplied as is. The author disclaims all warranties, expressed or implied, including without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of the software.

---

Related Posts:

---

Revisions:
[27/01/2014] Original

[23/04/2016] Changed download links to MiScion Pty Ltd Web Store

Plane Frame Analysis

Sample03

I have taken the plane plane frame analysis application I previously blogged about here, and ripped out all the DOS based full screen graphics and reduced it to a command line application, and made available for download. To me this is not diminished capability but an enhancement. I never used the user interface as I auto-generated the data files using Borland Quattro Pro (QPro) spreadsheet. However whilst I could launch pframe from within QPro I had to open the data file, run the analysis and then save the results: three steps where one would have done. Now with a command line parameter, the data file can be created and then cpframe can be called from an MS Excel routine to run the analysis on the data file and produce the results file. Though it can be simply used at the command prompt. If type name in without a file name then it will show a brief message on how to use.

cpframe usage

run cpframe

Other wise it is simply called with a data file containing the definition of the structural model, a single load case per file, for example:
               cpframe refF_wrk.dat

screen dump as program runs

Which will then display its progress and generate a results file with the file extension .rpt for report. The report can be read with a simple text editor like notepad, and similarly data files can be created with notepad. Though the primary intent is that data files will be auto-generated by some other application.

Sample01

There are no graphics with this version. Since the graphics in the original version have full control of the graphics screen, its not fully compatible with use in Windows. It works in the Windows XP command prompt but does not seem to work in Windows 7. However can always load FreeDOS onto a bootable flashdrive and run from there.

Noting the benefit of being able to see the geometry and the direction of loading to check the validity of the model, in the near future I will release a version with the menus and graphics put back. However I will be removing the menus for data file creation, as objective is that data files will be created by an external application and I don't wish to expend time fixing such menus up. The source code has already been transferred to Delphi and a windows version part written. We also have a version in Excel/vba (.xla) which is providing the structures engine for cold-formed steel carport and veranda software. {Sorry! Cannot release the original version as the report file it produces implies we did the design of the structure being analysed. Plus it was compiled back in 1996 using Turbo Pascal, and finding the complete source code to compile something similar got complicated.}

Any case the idea isn't to write a stand alone frame analysis application but provide a library, or COM automation server or .net component which can be referenced in other applications, which need structural analysis as a component of a much larger system. A command line application provides a stepping stone towards such objective, it allows use in other applications, but in a more limited way than is possible if can send data direct into the analysis.

In future posts I will provide more sample data files, and an MS Excel workbook with vba code to write such data files. Resources for calculating wind loads and checking capacity of members can be found over on my ExelCalcs profile. Of course meshing it all together to fully automate simple buildings at the point of sale is a fairly massive exercise.

For small manufacturers approaching small engineering consultancies the one thing the consulting engineers have missing from their tool box is frame analysis. The consultants typically use MicroStran, Spacegass or Multiframe to conduct analysis, and therefore the engineers do not have their own tools to integrate into the software they are asked to develop. The simple solution to this is to use Kleinlogel formula, however new publications with such formula are now rare, and the older publications difficult to get hold of. Further there is the problem of finding the appropriate formula for the structure being considered. Sure they could attempt to derive the appropriate formula but that is more time and effort, and as the manufacturer introduces more variety into the structures more formulae are required. Where as  matrix structural analysis is more general purpose, once again there is still the problem of writing the source code and testing it. Also transforming theory into source code not so easy, and books with sample source not so readily available. Though a search of the web indicates recent engineering students/graduates may have experimented with matrix structural analysis using either MatLAB or SciLAB.

My previous contribution to easing this shortfall of analysis tools has been:

1. Release height/span charts showing the limitations of c-sections for the typical gable frame shed so that can limit the number of standard designs produce detailed calculations for.
2. Release MS Excel workbooks with Kleinlogel calculations in the worksheet.
3. Release MS Excel workbook with Kleinlogel formula as vba code for gable frame.
4. Release table of Contents of Kleinlogel formula book
5. Release a simple program for checking gable frame size based on Kleinlogel formula.

All of these tools we use in-house for quick decision making, though admittedly my gable frame spreadsheet contains the full design for cold-formed steel: still I believe I've provided all the resources for interested parties to build something similar better adapted to their needs. All the previous releases however have been focused on the gable frame (sample01) where as design of the so called American barn style structure (sample03) is often wanted by manufacturers.  Using plane frame application this is now more practical to accomplish than setting up worksheet calculations in Excel.

The program can be downloaded here. 

DISCLAIMER :
Users of the software must accept this disclaimer of warranty :
The software is supplied as is. The author disclaims all warranties, expressed or implied, including without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of the software.

---

Related Posts:

Plane Frame Analysis History our Development

Plane Frame Analysis with Graphics
Plane Frame Analysis Front-End
Plane Frame Analysis Alternative Front-End
Plane Frame Analysis Back-End

Plane Frame Analysis Future Developments

---

Revisions:
[25/01/2014] Original

[23/04/2016] Changed download links to MiScion Pty Ltd Web Store

I Believe there is a Need to Define the Concept of Software Upgrade

An issue I have with software companies is that what they call upgrades are light years from being upgrades. There should be some peoples law which defines an upgrade. Changing any of the following breaches the concept of upgrade:

1. File format
2. User Interface
3. Reports generated

If I cannot generate the same reports with the software, then it is clearly a different product: the output expected from the product is no longer there and therefore it is clearly different. So if have engineering, accounting software or similar and the developers change the reports, then they have changed the product. If they retain the original reports and add more reports then can consider it to be an upgrade.

If the old program cannot read the file of the new program then its not an upgrade its a change of product. The file format should therefore be designed so that additional data can be added in future. Whilst the file parser/reader should be designed so that it can read what it needs and ignore the rest. Similarly the file writer should be designed so that it can update the data it uses, but otherwise doesn't touch and retains the data it doesn't use. Most old software isn't written such way, and therefore changing the file format would result in a change of product not an upgrade.

Changing the user interface is clearly a change of product. Replacing the popup menus with a ribbon bar, is not an upgrade. Changing the locations of commands in a menu is not an upgrade its a change of the product. Increasing necessity of a mouse and removal of keyboard commands is not an upgrade. Removing commands, renaming commands, none of this represents an upgrade.

Any change which results in a learning curve to get back up to speed with using the software is a change of product not an upgrade. The learning curve should only be for new features, and if don't need them don't need to upgrade, and don't need to learn how to use them.

FreeDOS and USB Flashdrive on Asus EEE PC Netbook

On attempting to get the USB flashdrive to work on my netbook, I read several websites about various drivers the most useful articles being:

1. DOS USB Drivers (At BootDisk: a useful site for information about booting DOS and/or windows from CD's,to fix problems)
2. Yes, there are USB drivers for DOS... (From FreeDOS site itself)
3. Run USB devices under DOS! (TechSpot Forum: From memory where I actually got the drivers from, most other sites had dud links.)
4. Bret Johnson (A collection of programs for working with USB's at DOS, and extensive documentation of USB technology. Though no quick guide, or example Autoexec.bat and config.sys files.)
5. USB Made Simple (For those interested in the electronics)

I started out with what appeared to be the simplest and most common appoach of using the seemingly universal Panasonic drivers. It didn't seem to work, but then too many other variables to get a clear check on things. So I decided to take the plunge and start reading Bret Johnson's 186 page document, plus randomly typing commands into DOS with the help switch option, or simply running and waiting for the complaint, then go read the instructions. Actually no real instructions. I opted for putting the following at the end of my autoexec.bat file:

USBUHCI
USBDRIVE

I'm not sure if USBUHCI should be in config.sys. It seemed to work but not consistently. First boot and my drive was E: and a second boot and drive was F:, boot again and back to E: and so forth. However messing with USBHOSTS and DRIVES, I decided I was probably wasting my time.

Wasting my time, because I was starting to get the impression that none of the drivers were actually doing anything. One of the problems is that when the netbook boots most of the information it displays flies off the screen fairly quickly. However, just before disappears off the screen do get to see that it finds either the USB flashdrive or the extrenal USB CD ROM drive if plugged in. I can boot the computer from either.

Actually that was a problem. A while back I downloaded FreeDOS and burnt the ISO file to CD. This time round I downloaded the FreeDOS ISO file and used Rufus to create a bootable USB flashdrive. Problem was that even though can boot from the flashdrive, the installation expects a A: floppy disk drive: so doesn't install. The result I installed the older version of FreeDOS from the CD. Didn't have that problem with Ubuntu, I installed from the flashdrive.

Any case I can boot the flashdrive and work from it. So using my MS Windows XP machine I created a new bootable FreeDOS stick using Rufus, with minimum requirements. That booted and provided access to the two DOS partitions on my harddrive: further more it didn't complain about the partition, as I described in earlier post. This I guess is because the memory stick, was now the C: and the partitions were D: and E:. So it appears it could be a boot sector problem.

Booting from the flashdrive (I prefer memory stick, mainly because I thought flashdrive was one specific brand), I got a nice clean display of all the drives recognised when FreeDOS booted: not cluttered by error messages.

So my next exercise was to disable the autoexcec.bat and config.sys files on my harddrive and boot from the harddisk. Didn't seem much of a problem, as I don't know what most of the rubbish in these files is for anyhow: I'm guessing mostly only of use by those who want to play old DOS games. So all up not having my display cluttered with error messages about stuff I don't have nor need was a good thing. The system thus booted ok, with just the message about the bad partition.

Next thing was to plug in a non-bootable memory stick, and reboot from the harddisk. As expected the computer found the memory stick. Since my harddisk is partitioned I was expecting the harddisk to be C: and D: drives. However the memory stick became the D: drive and the second harddisk partition the E: drive.

Still its something I can work with. As to why it was not apparent in the first place, I guess that is because the memory stick I was using, was set up to be bootable, therefore I removed it from the drive when booting from the harddisk. The flashdrive /memory stick needs to be plugged in at boot time for the computer to find it.

Having to plug the memory stick in, at bootup is not a problem for me: I only have simple uses for a fast operating system. For some people it may be a problem, and the computers ability to find the flashdrives may be a problem if using drivers, Bret Johnson's document provides some trouble shooting guidelines if have such problem. Its how I decided that may be I didn't need any drivers and I was potentially wasting my time trying to get such to work. {With approach adopted I don't need any third party drivers, and therefore no licensing issues.}

I started out using an old 128Mbyte flashdrive, then I setup a 2Gbyte flashdrive to boot to FreeDOS. Given my intended use of FreeDOS either of these flashdrives is plenty big enough to work from without need to setup the computer harddisk.