I thought I had shut down all input from social networks associated with these groups, so that I wouldn't be distracted by their nonsense, but seems I was wrong: some leaked through.
It seems APESMA, the association of professional engineers scientists and managers Australia has created new internal groupings or something, and so Professional Engineers Australia has emerged.
I guess they didn't like resurrecting the original name which was something like: APES. A name which some probably think is an apt description of engineers. It certainly reflects my understanding of the letter 'P' in CP.Eng. Nearly 5 years they took to dream this post nominal detritus up to improve status: not sure how capitalist profiteer, or cretinous primate, improves status. See once something is released to the market it takes on a whole new live of its own: and since engineers are seen as ignorant of the environment and the consequences of the technologies they release, it is clear that any post nominal dreamed up needs to be such that it does not provide an easy hook into reinforcing the communities negative views. It should be noted I only listed the relatively polite possibilities for CP, I'm sure people can find more interesting expletives to use.
However, back to the issue, I do not see any value in creating these separatist elitist clique's.
Further the issue of importance is that Engineers Australia sought to redesign the industrial environment, and poorly executed its implementation. It introduced the concept of engineering technologists, without creating an industrial award for such. It ignored the technical officers awards and renamed engineering associates to engineering officers. It further ignored the technical officers awards which placed engineering technicians subordinate to engineering associates and equated engineering associates to WFEO engineering technicians. With the federal system, most of the state awards have been scrapped, and currently there appears to be only one federal award and that is for technical professionals: which doesn't cover the full technical team.
Further in the design of this new industrial environment, it is inappropriate to hold the new members of the engineering team as responsible for creating their own little groups and promoting their occupation. It is meant to be an engineering team, and each member of the team has an identifiable skill set not held by other members. Engineering Associates form the solid foundation on which the pinnacle stands firm, they are essential. The professional engineers and engineering technologists are not essential.
The engineering associates deal with the firmly established technologies, for which the technical science is well established and the risk and uncertainty is extremely low: and they are supposed to be educated in specific areas of practice not broad engineering disciplines. Engineering associates are responsible for the technologies we have and are dependent upon, their body of knowledge defines the frontier of science and technology. Just because a technology was originally designed by an engineer, does not mean that an engineer is needed to redesign apply and adapt that technology.
By promoting occupational cliques and professional elitism, we are eroding the foundation. Further more the resulting professionals are something far less than the learned elite they contend to be.
It also causes industrial relations problems. If work is well within the capabilities of an engineering associate but an engineer typically does the work, then to pass the work over to the engineering associate raises the contention that the engineering associate is doing the work of an engineer and therefore should be paid as such.
On the other hand if the work is with in the capabilities of an engineering associate then the engineer doing the work should be paid as an engineering associate not an engineer, ignoring the potential the B.Eng provides and pay according to their actual contribution not according to their education. This industrial relations system also hampers developing new technologies and then handing over to engineering associates once the technology has been established.
Once a technology is released to the market it will be put to uses far beyond the intents of the designers, and likely have impacts beyond their imaginations. Engineers Australia has basically demonstrated poor planning, design and management skills with respect to the industrial products it is trying market. These human cogs it has defined don't really fit anywhere. Industry is basically being forced to buy what is being supplied rather than what it really needs. But then again it could design and make what it needs: or is there something preventing them from doing so? I'd contend the professions are an obstructive obstacle.
I contend that Engineers Australia is attempting to float a pinnacle in fresh air, rather than stand it on a firm foundation. The contention has been held that some of the big mining and infrastructure projects have failed to launch due to a shortage of engineers.
My contention is they failed to launch due to having eroded the foundation of the engineering team: namely the trades people, the drafters and the engineering associates. These people form the army which makes things happen, engineers have the vision to give them direction and put them to work.
I contend we are creating a society which is top heavy. We should stop promoting professional engineer to school leavers, and instead promote engineering, and get them in at the ground floor. With plenty of opportunity for the best to step up the ranks towards professional engineer.
At present the professional engineers, the CP.Eng's are less than the learned people they contend to be.
That has a two fold effect. One is that industry has no faith in CP.Eng as a reliable indicator of technical competence, and therefore will not select employees on the basis of such accreditation over and above any other qualifications. Secondly persons not having CP.Eng credentials, don't see those with CP.Eng as being competent, and therefore see no reason to join such class of individuals.
In fact it can work the other way round. Clients themselves having got some rubbish from a CP.Eng go looking for a real engineer: that usually means older engineers and/or engineers with overseas qualifications. People who actually gained experience working on serious projects, under the supervision of a properly qualified individual, and who then went through some relevant qualification process for their discipline. The CP.Eng credential is based on some generic rubbish, and is an unreliable test of technical competence: it is based on far too great an assumption that the competence comes from the B.Eng: the required technical competence never has come from such degree. Some CP.Eng's are competent, the issue is that its an unreliable indicator: as we do not know what they are competent in, nor what they are deficient in.
For example a lot of the civil/structural engineers operating in the area of manufactured structural products are a public menace. Besides lacking adequate knowledge of structures, they also lack knowledge of industrial product design. The result is poor service to the manufacturer/suppliers of the structural products and poor service to the greater community. Those carrying out certification work for the regulating authorities are no better.
A lot of the work which passes through the office is well within the capabilities of engineering associates, it is dull for engineering technologists, the work is flowing in because people think they need an engineer. This work should be flowing to engineering associates in the first place.
The regulators should stop refer to the need for engineering and the need for engineers reports. The requirements of the system are adequate evidence-of-suitability, and often the engineers are not capable of supplying adequate evidence: as they lack adequate knowledge of the technology they are supposed to be assessing and otherwise fail to properly research such established technology, or otherwise don't have the time.
Established technology is the realm of engineering associates, or as I prefer Associate Technologists. Forget about recent years in which engineers have been relegated to being the tools of regulators. The proper role of an engineer is pushing forward the frontiers of science and technology. Their education is for such purpose and they lack adequate knowledge of the established technologies, and industry is unreliable as a trainer.
The Associate Technologist is meant to be educated in the specific area of practice not a broad engineering discipline. Their task is to maintain the technological base of our industrial society. Buildings shouldn't fall down, bridges shouldn't collapse, machines shouldn't blow up. All of this is established technology.
After an engineer as originated something, the ingenious leap of logic is no longer necessary. A new generation of technologists and Associate Technologists can be trained to apply and implement such new technology.
We are pushing the elitism of the professional engineer and failing to train the people we really need. Lets make sure we build and sustain an army of competent Associate Technologists before we push the elitism of professional engineer.
A journal on everything technological and everything to do with structure: from building structures, to organisation structures, politics, education, and business. If it has structure I will essay it, if it ought to have structure I will essay it. If it don't have structure and it is chaos, I essay that too!
Sunday, October 27, 2013
Wednesday, October 16, 2013
Data file formats for interchanging and sharing data from user applications
When I wrote my soil heave program I based its data file format on what I had otherwise learnt about DXF files. I did this to keep the reading of the data simple, as I hadn't otherwise written any code to process a comma delimited file (.cdf), and I had both numbers and text and all kinds of problems were encountered if text and numbers are on the same line and use the standard input/output routines with languages like Pascal and C.
The format of the data file adopted therefore comprises of a line with the tag name followed by another line with the tag value. However I didn't include all the complicated nesting and sections typically found in a DXF file. However the soil heave program is based on multiple soil cores being split into multiple strata, and this introduced some inconsistency into reading and writing the data format. Whilst the Core tag is followed by a count of the reference number of the core, the end core tag has no tag value following it. Similarly the end of file tag (EOF) also has no tag value following it. But for simple data sets, this poses no real problem for reading and writing the file. For more complex data sets however, a more consistent data format is required, with a simple parser which can be called repetitively.
When I recently came to revisit the data file format for exporting data from my spreadsheets, I discovered XML files.
No need to re-invent the wheel, nor particularly any need to write a file parser as such, such file readers are built into various programming environments. The only task is having got the data, to sort it and assign to appropriate variables inside the user application: well programming wise. The bigger task is to decide on the format of the data.
I realise that MS Excel exports data to an XML file, newer may even use such as the default format, however that contains more information than I am interested in, and is about data defining a spreadsheet, not the structure of the data stored in the spreadsheet.
So at present I have wrapped the whole data set in the tag, namely its my data, formatted my way. Then I have divided the data into parameters and variables. Parameters are named ranges in an Excel spreadsheet which contain a simple value and have no formula. Variables are named ranges which contain formula. So parameters are wrapped in tags, and variables are wrapped in tags. Nested inside these tags, are tags for the name of the range, and tags for the stored value.
Whilst writing this code in MS Excel/vba I also had problems dealing with Unicode characters, as Excel cells contained values which disappeared when written to a text file using the ordinary print functions. Having got the data into a text file also had problems reading them back in. But resolved the problems using the VBScript file system objects for reading and writing files.
The other problem encountered in the export of data to an XML file was that not all the named ranges were simple scalar values, some were lists and tables. So also added additional tags, if a range only lay on a single row or column, then the range classified as a list and tagged
An alternative format, or schema, I considered was to consider using the MS Excel range name as the XML tag, and then wrapping the value in these tags. The problem I had with that approach is that it is less generic. Whilst it may be the more valid way of defining the fields for a database in XML, it doesn't match what I already have in MS Excel and MS Access. In Excel all my variables are typically defined on one worksheet which is compatible with import into an MS Access table. In this way I can add new variables as I wish if I don't have need for a variable or more to the point if a program doesn't know what to do with the variable it can be ignored.
Whilst XML provides flexibility, and can easily write a new variable as a new XML tag, the problem is reading the XML file and then knowing what to do next with the data which comes after the tag. In effect an XML data file has to be parsed twice when using XML objects. The first level of parsing is to grab all the XML tags, any contained attributes, and then the data contained between the tags. The second level of parsing is determining what to do with the tags and data with respect to some specific application.
A book database with a fixed data structure is relatively simple: just read the XML file, and then permit searching and listing information about the list of books contained in the database. Throw variable data structures into the database, then need different processors for each data set found. For example with respect to CAD data, may have a circle and a line. A data structure for a circle contains say the diameter of the circle and may be its insertion point. The data structure for a line contains say the coordinates of the two ends of the line. Displaying a line on the screen is different than displaying a circle. So as the program works its way through all the data, it calls different commands to execute based on the data encountered at any given point in reading the data.
At the time of this experimenting, it seemed to me that if the variable name was used as a tag, then when read a variable unknown to the program, it would loose synchronisation with reading the rest of the file. {This may have had more to do with my writing a parser from scratch rather than using XML reader objects. Which is also why I didn't use parameter and variable as tag attributes. Something like isparameter=1}
If can read all the data into a XML tree object, then if traverse the tree and find a tag do not know, then can ignore the entire branch starting from that node. But if cannot read the entire data into an XML tree object, then seems to me, need to decide what to do as progress through the data: since cannot ignore an entire branch until identified the branch: found the end tag.
I don't know really, probably need to experiment with both approaches. Another approach adopted by some software is to use the tag attributes to contain data. This approach I don't like as it confuses things. Data is supposed to be between the tags, and the tags can contain attributes descriptive of the data. However storing data in the attributes can make the data file more compact and easier to read. For example, the definition of a node could be as follows:
Parameters are input variables and can be changed, whilst those items I have named variables are dependent variables their value is dependent on the value of input parameters, and the process which relates the input to output. Change the process which relates the parameter to variable and change the output of the program. For example height and span could relate to a gable roof building or a skillion roof building or for that matter a balustrade. Thus two basic parameters can get transformed into a variety of structural forms. Further I can define a building as a series of bents. Each bent comprises one column and one rafter. To define a monoslope roof from bents, then the rafter would be split at mid point or any other convenient location along the rafter. Alternatively permit the bent to only comprise of a column. Any case the parameters height and span could occur multiple times and their meaning would vary depending on the object in which they are contained.
Say I throw another parameter in such as eavesHeight, then could have either of the following:
Method 1:
I guess from my viewpoint, when I set up my spreadsheets I didn't know what the input parameters were. I simply worked through the calculations and unprotected certain values as parameters. I then shifted the input of these values to a worksheet used for input values. In Quatro Pro it was necessary to have all the input values to a dialogue box in a continuous block, and since I also wanted the data to be compatible with Paradox it also fell into place as one or more tables. Without the dialogue boxes it also seemed appropriate to collect similar data in sets, with one worksheet per set of data. So ended up with multiple tabbed sheets each of which was compatible with export to a database. When moved over to MS Excel and MS Access, the concept was maintained, even though can feed data from any where into a dialogue box.
So the tables or worksheets are not just a convenient place for named cells/ranges, its not just a simple matter of getting a value for a variable. The tables are defining the parameters which define the object which the spreadsheet is used to design.
So that the list of parameters and their names are just as important as the values of the parameters. Still doesn't give me a reason for putting the names between the XML tags rather than making them the XML tags. {I guess my reasoning is the parameters are data describing an object, change the object the parameters change. Therefore I have added another level of abstraction for the data, which may not be necessary.}
Any case that's the idea at present, if there is a named range in MS Excel then its value is exported to an XML file. If the data in an XML file is a parameter then it can be imported into an MS Excel worksheet. This way large spreadsheets do not have to be stored for individual projects, the MS Excel workbook just gets used as an application, and the required data is stored in simple XML files. This data can also be shared across different Excel workbooks which fulfil different functions. So all the data for a project can be stored in a central XML file, and used by a variety of applications. Each application just reads and writes the data it needs without messing up the data file for other applications.
Of course I could just use a simple Excel spreadsheet to get data to and from complex Excel workbooks, but that supposes Excel is available. Further not every suitable application will be built using Excel, plus XML is also useful for web based data storage. Which means faster development of a web based application at future date.
Looks like I need to figure out how to display the XML brackets. < and > is not working, and neither does using the actual characters. Take that back, it doesn't display correctly in compose. Now for the other problem: none of the sites I found providing a solution, actually explain properly what is required because the codes they recommend are translated and therefore see the results not the recommended codes. The results and codes are:
< is displayed by <
> is displayed by >
The format of the data file adopted therefore comprises of a line with the tag name followed by another line with the tag value. However I didn't include all the complicated nesting and sections typically found in a DXF file. However the soil heave program is based on multiple soil cores being split into multiple strata, and this introduced some inconsistency into reading and writing the data format. Whilst the Core tag is followed by a count of the reference number of the core, the end core tag has no tag value following it. Similarly the end of file tag (EOF) also has no tag value following it. But for simple data sets, this poses no real problem for reading and writing the file. For more complex data sets however, a more consistent data format is required, with a simple parser which can be called repetitively.
When I recently came to revisit the data file format for exporting data from my spreadsheets, I discovered XML files.
No need to re-invent the wheel, nor particularly any need to write a file parser as such, such file readers are built into various programming environments. The only task is having got the data, to sort it and assign to appropriate variables inside the user application: well programming wise. The bigger task is to decide on the format of the data.
I realise that MS Excel exports data to an XML file, newer may even use such as the default format, however that contains more information than I am interested in, and is about data defining a spreadsheet, not the structure of the data stored in the spreadsheet.
So at present I have wrapped the whole data set in the tag
Whilst writing this code in MS Excel/vba I also had problems dealing with Unicode characters, as Excel cells contained values which disappeared when written to a text file using the ordinary print functions. Having got the data into a text file also had problems reading them back in. But resolved the problems using the VBScript file system objects for reading and writing files.
The other problem encountered in the export of data to an XML file was that not all the named ranges were simple scalar values, some were lists and tables. So also added additional tags, if a range only lay on a single row or column, then the range classified as a list and tagged
- , if comprised of rows and columns then classified as a table and tagged . A list contains elements
An alternative format, or schema, I considered was to consider using the MS Excel range name as the XML tag, and then wrapping the value in these tags. The problem I had with that approach is that it is less generic. Whilst it may be the more valid way of defining the fields for a database in XML, it doesn't match what I already have in MS Excel and MS Access. In Excel all my variables are typically defined on one worksheet which is compatible with import into an MS Access table. In this way I can add new variables as I wish if I don't have need for a variable or more to the point if a program doesn't know what to do with the variable it can be ignored.
Whilst XML provides flexibility, and can easily write a new variable as a new XML tag, the problem is reading the XML file and then knowing what to do next with the data which comes after the tag. In effect an XML data file has to be parsed twice when using XML objects. The first level of parsing is to grab all the XML tags, any contained attributes, and then the data contained between the tags. The second level of parsing is determining what to do with the tags and data with respect to some specific application.
A book database with a fixed data structure is relatively simple: just read the XML file, and then permit searching and listing information about the list of books contained in the database. Throw variable data structures into the database, then need different processors for each data set found. For example with respect to CAD data, may have a circle and a line. A data structure for a circle contains say the diameter of the circle and may be its insertion point. The data structure for a line contains say the coordinates of the two ends of the line. Displaying a line on the screen is different than displaying a circle. So as the program works its way through all the data, it calls different commands to execute based on the data encountered at any given point in reading the data.
At the time of this experimenting, it seemed to me that if the variable name was used as a tag, then when read a variable unknown to the program, it would loose synchronisation with reading the rest of the file. {This may have had more to do with my writing a parser from scratch rather than using XML reader objects. Which is also why I didn't use parameter and variable as tag attributes. Something like isparameter=1}
If can read all the data into a XML tree object, then if traverse the tree and find a tag do not know, then can ignore the entire branch starting from that node. But if cannot read the entire data into an XML tree object, then seems to me, need to decide what to do as progress through the data: since cannot ignore an entire branch until identified the branch: found the end tag.
I don't know really, probably need to experiment with both approaches. Another approach adopted by some software is to use the tag attributes to contain data. This approach I don't like as it confuses things. Data is supposed to be between the tags, and the tags can contain attributes descriptive of the data. However storing data in the attributes can make the data file more compact and easier to read. For example, the definition of a node could be as follows:
<node id="1" x="2" y="5" z="0" />OR
<node>
<id>1</id>
<x>2</x>
<y>5</y>
<z>0</z>
</node>
And similarly I could have for simple variables or parameters.
<Height isparameter="1">5</Height >Compared to approach proposed above and otherwise experimented with:
<parameter>
<name>Height</name>
<value>5</value>
</parameter>
Parameters are input variables and can be changed, whilst those items I have named variables are dependent variables their value is dependent on the value of input parameters, and the process which relates the input to output. Change the process which relates the parameter to variable and change the output of the program. For example height and span could relate to a gable roof building or a skillion roof building or for that matter a balustrade. Thus two basic parameters can get transformed into a variety of structural forms. Further I can define a building as a series of bents. Each bent comprises one column and one rafter. To define a monoslope roof from bents, then the rafter would be split at mid point or any other convenient location along the rafter. Alternatively permit the bent to only comprise of a column. Any case the parameters height and span could occur multiple times and their meaning would vary depending on the object in which they are contained.
Say I throw another parameter in such as eavesHeight, then could have either of the following:
Method 1:
<eavesHeight isparameter="1">5</eavesHeight>Method 2 (preferred):
<parameter>
<name>eavesHeight</name>
<value>5</value>
</parameter>
Now why I prefer method 2, I'm not entirely sure. Method 2, is less compact and more cumbersome for a person to read than method 1. But ?I guess from my viewpoint, when I set up my spreadsheets I didn't know what the input parameters were. I simply worked through the calculations and unprotected certain values as parameters. I then shifted the input of these values to a worksheet used for input values. In Quatro Pro it was necessary to have all the input values to a dialogue box in a continuous block, and since I also wanted the data to be compatible with Paradox it also fell into place as one or more tables. Without the dialogue boxes it also seemed appropriate to collect similar data in sets, with one worksheet per set of data. So ended up with multiple tabbed sheets each of which was compatible with export to a database. When moved over to MS Excel and MS Access, the concept was maintained, even though can feed data from any where into a dialogue box.
So the tables or worksheets are not just a convenient place for named cells/ranges, its not just a simple matter of getting a value for a variable. The tables are defining the parameters which define the object which the spreadsheet is used to design.
So that the list of parameters and their names are just as important as the values of the parameters. Still doesn't give me a reason for putting the names between the XML tags rather than making them the XML tags. {I guess my reasoning is the parameters are data describing an object, change the object the parameters change. Therefore I have added another level of abstraction for the data, which may not be necessary.}
Any case that's the idea at present, if there is a named range in MS Excel then its value is exported to an XML file. If the data in an XML file is a parameter then it can be imported into an MS Excel worksheet. This way large spreadsheets do not have to be stored for individual projects, the MS Excel workbook just gets used as an application, and the required data is stored in simple XML files. This data can also be shared across different Excel workbooks which fulfil different functions. So all the data for a project can be stored in a central XML file, and used by a variety of applications. Each application just reads and writes the data it needs without messing up the data file for other applications.
Of course I could just use a simple Excel spreadsheet to get data to and from complex Excel workbooks, but that supposes Excel is available. Further not every suitable application will be built using Excel, plus XML is also useful for web based data storage. Which means faster development of a web based application at future date.
Looks like I need to figure out how to display the XML brackets. < and > is not working, and neither does using the actual characters. Take that back, it doesn't display correctly in compose. Now for the other problem: none of the sites I found providing a solution, actually explain properly what is required because the codes they recommend are translated and therefore see the results not the recommended codes. The results and codes are:
< is displayed by <
> is displayed by >
Tuesday, October 15, 2013
Feasibility of Cold-formed Steel Shed (Simple Structural Software Application)
The simplest program I have written to check the frames size of a cold-formed steel shed is EngineLT.exe. It is a cut down version of a larger program I wrote in Delphi 3, the problem with the larger program is I never really got round to working out how to get the Borland Database Engine (BDE) onto another machine, and I had more important things to do. So I ripped the database out, and simplified the interface. To give the following:
It is based on AS1170.2:1989, so its results are potentially no longer valid. But it provides a quick check on whether a given size of c-section is suitable for a given gable frame shed. A gable frame comprising of two rafters and two columns. The moments in the frame are calculated using Kleinlogel formula for a fixed base rigid moment frame.
The minimum sectional moment capacities of the available c-sections here in Australia are hard coded into the program. The minimum yield strength of the steel is 450MPa. Low internal pressure coefficients are adopted to reflect the status of the industry with respect to the standard calculations held by most suppliers. Remove one or both columns and get a different rigid frames, which are not within the scope of the program. Simply providing carry beams is not acceptable.
Roughly removing one column makes the roof a propped cantilever and the moment at the remaining knee is approximately 1.5 times the maximum knee moment in the full frame. Remove both columns and the maximum moment moves to the ridge and is approximately 3 times greater than it was in the full frame. Typically the maximum moment in the full frame is at the knee, but not always. Any case the program doesn't provide the details, nor can it handle these variations. The point is, the structural form is a specific rigid frame, any variation which changes this structural form requires a different mathematical model to check stresses in the frame.
It is common practice in the cold-formed shed industry to standardise frames at 3m centres and rip columns out for larger doors in the side: this changes the structural form and is beyond the scope of the standard calculations held by most shed suppliers. Merely providing carry beams is not adequate, in fact if remove too many columns, and want really large openings, an entirely different structural form may be required for the entire building: such as large parallel chord trusses span the entire length of the building, with two columns.
So before messing around with carry beams, the first check should be with changing the frame spacing. If want 5m wide doors then see what frame size is required for frames at 6m centres. Sure adopting 6m centres or larger means the C7510 girts/purlins typically used will no longer be valid. By adopting larger spaces, potentially reduce the amount of fabrication and onsite labour: though may increase the need for cranes.
Any case those are other design issues. When I wrote the program, my interest was providing a tool which would allow experimentation with something other than the standard 3m spacing. The application has no data files, and doesn't produce any result files or print any reports. It simply allows playing around with the basic input parameters, and seeing how they affect frame size. The frame size may not be possible when detail design is carried out due to lack of lateral torsional restraint to the frames: provided by combination of girts/purlins and flybracing. However if the program indicates a frame is not possible its highly unlikely that detailed design can make it possible.
EngineLt can be downloaded here as a zip file.
The frame size determined by the programme should be comparable to the frame size selected from the height/span design charts I have produced. The prime difference between the two is that the charts are to wind loading from AS1170.2:2002, whilst this program is to AS1170.2:1989.
Design Chart for C-Section Frames AS1170.2 Terrain Category 3 (TC3)
Design Chart for C-Section Frames AS1170.2 Terrain Category 2 (TC2)
DISCLAIMER :
Users of EngineLT must accept this disclaimer of warranty :
EngineLT 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 EngineLT .
It is based on AS1170.2:1989, so its results are potentially no longer valid. But it provides a quick check on whether a given size of c-section is suitable for a given gable frame shed. A gable frame comprising of two rafters and two columns. The moments in the frame are calculated using Kleinlogel formula for a fixed base rigid moment frame.
The minimum sectional moment capacities of the available c-sections here in Australia are hard coded into the program. The minimum yield strength of the steel is 450MPa. Low internal pressure coefficients are adopted to reflect the status of the industry with respect to the standard calculations held by most suppliers. Remove one or both columns and get a different rigid frames, which are not within the scope of the program. Simply providing carry beams is not acceptable.
Roughly removing one column makes the roof a propped cantilever and the moment at the remaining knee is approximately 1.5 times the maximum knee moment in the full frame. Remove both columns and the maximum moment moves to the ridge and is approximately 3 times greater than it was in the full frame. Typically the maximum moment in the full frame is at the knee, but not always. Any case the program doesn't provide the details, nor can it handle these variations. The point is, the structural form is a specific rigid frame, any variation which changes this structural form requires a different mathematical model to check stresses in the frame.
It is common practice in the cold-formed shed industry to standardise frames at 3m centres and rip columns out for larger doors in the side: this changes the structural form and is beyond the scope of the standard calculations held by most shed suppliers. Merely providing carry beams is not adequate, in fact if remove too many columns, and want really large openings, an entirely different structural form may be required for the entire building: such as large parallel chord trusses span the entire length of the building, with two columns.
So before messing around with carry beams, the first check should be with changing the frame spacing. If want 5m wide doors then see what frame size is required for frames at 6m centres. Sure adopting 6m centres or larger means the C7510 girts/purlins typically used will no longer be valid. By adopting larger spaces, potentially reduce the amount of fabrication and onsite labour: though may increase the need for cranes.
Any case those are other design issues. When I wrote the program, my interest was providing a tool which would allow experimentation with something other than the standard 3m spacing. The application has no data files, and doesn't produce any result files or print any reports. It simply allows playing around with the basic input parameters, and seeing how they affect frame size. The frame size may not be possible when detail design is carried out due to lack of lateral torsional restraint to the frames: provided by combination of girts/purlins and flybracing. However if the program indicates a frame is not possible its highly unlikely that detailed design can make it possible.
EngineLt can be downloaded here as a zip file.
The frame size determined by the programme should be comparable to the frame size selected from the height/span design charts I have produced. The prime difference between the two is that the charts are to wind loading from AS1170.2:2002, whilst this program is to AS1170.2:1989.
Design Chart for C-Section Frames AS1170.2 Terrain Category 3 (TC3)
Design Chart for C-Section Frames AS1170.2 Terrain Category 2 (TC2)
DISCLAIMER :
Users of EngineLT must accept this disclaimer of warranty :
EngineLT 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 EngineLT .
Saturday, September 28, 2013
State of Play 2013/wk39
Now have various blogs and web sites to look after. There is MiScion Pty Ltd, this is where I work drawing, designing structures, and programming computers with my father. This is basically the first web site the business has ever had, and I'm not sure at the moment what to place on it: so blog format works for now.
I have also created some additional blogs all of which can be accessed from the tabs above.
Not so sure this is a good breakdown, too much overlap between, resulting in uncertainty as to where anything should be placed. However right here on this blog is where to deal with the chaos, so stuff likely to start here and then get subdivided refined and then rewritten else where, though remaining here as a reference as to where it came from.
I have also created some additional blogs all of which can be accessed from the tabs above.
Not so sure this is a good breakdown, too much overlap between, resulting in uncertainty as to where anything should be placed. However right here on this blog is where to deal with the chaos, so stuff likely to start here and then get subdivided refined and then rewritten else where, though remaining here as a reference as to where it came from.
Tuesday, September 10, 2013
State of Play 2013/wk37
Been working setting up wordpress for business website. Having closed down the office and retracted the business back home, now need to make better use of the Internet. Most especially with the intended future move over to Maitland on the York Peninsula. The business exists mainly because we are local. That is people attempt DIY building development applications, council advises they need structural engineering. They ask what is that and they are given a list of consultants who submit work for the area. Only one of the consultants is actually in the area, and as both individuals and small builders, have no desire to go into the city or the other side of the city, they come to us. Moving over to Maitland therefore is potentially a major stumbling block.
On the other hand there has been a down turn in work, our regular clients have experienced a reduction in work and that has flowed onto us. As for private individuals, and small builders with one-off projects, whilst they represent some 80% of projects, they represent very little in terms of income, like around 20%, yet they consume a disproportionate amount of time. Their emergencies and urgencies tend to result in them applying pressure to jump to the front of the queue, and otherwise cause delays for our regular clients. Their projects also interfere with our capacity to pursue larger projects. They contribute to keeping our earnings low and barely scraping in incomes equal to the Federal minimum wage. That I don't so much mind, but I object to the hassle and the pressure.
I mean, there are people in the world who don't have housing and our time is wasted by people who don't follow the rules get into a mess and expect we dig them out off a hole for a low fee. Meanwhile people who try to do the right thing, have to have extreme patience, as they keep getting pushed further and further along the queue.
To me it seems there is a need for some means of providing engineering services like legal aid. Though I did take a look at legal aid services, they seem to have highly restrictive requirements as to who can get such aid.
The alternative is to design a service which properly informs people, so that they don't build stuff without approval, and so that they don't produce DIY applications. More prescriptive building solutions are required along with the necessary evidence-of-suitability.
The problem however are people who do not care, think they know what is required, and do not do any research. Such people are always going to be around, the main people to serve are those who go looking for information but cannot find anything suitable. Those who don't do the research, and think they can do what ever they want on their property no matter what hazards it poses to the rest of the community, will hit a bigger problem. That problem, will be no one to get them out off a mess. Since they don't see any reason to get building approval in the first place, they also don't see any reason to pay for the design and engineering services required to get approval. So this bunch are not really worth while clients. Can generally tell who they are from the start by their attitude, the difficulty is telling them to take a hike at the first meeting, and that not interested in their project. I believe it is preferable to refuse service to these people, Assisting them just encourages them to continue disregarding the rest of the community. Members of the Engineering team have sworn to a code of ethics, which typically places the community first, above the client and above the employer.
Sure much of the time, the city councils are just being picky, and its all a matter of just getting paper work in place. The city council doesn't really want to enforce a demolition order: it makes them look mean. But there are some members of the community who need to learn that their property is part of the greater environment and just about everything they do to their property has an impact on their neighbours.
Any case there has been a down turn in work load, and locality is not really a major issue any more. As most work has always flowed in from regular clients either by the telephone, fax, post, or email. In terms of post that is often in the way of clients dropping documents off in our post box after hours. We have lost our land line telephone number, but most clients already have either our email address or mobile phone number: and for a while now most work has flowed in via email. With only occasionally seeing people in person. Not getting out off the office can be some what depressing.
Still it would appear that an Internet based information resource, both with information provided gratis and other information provided for an up front fee, would resolve many issues. Admittedly there are plenty of sites already, but few providing the engineering information, and further more it is clear that people are not finding the information that is available.
Informing people has always been a problem for small business and organisations. Mail leaflet drops can be expensive, and reach few people, with the leaflets typically going straight in the bin. Yellow pages advertisements don't really attract much attention, may be good for some services but not much use for engineering: its too specialised. People may look in yellow pages when told they need an engineer, but they don't look otherwise, they don't know what they are or that they need such services. Engineers services are thus not altogether in the appropriate place in the phone directory. Being elitist not necessarily a good thing: engineers really need to be along side the drafters, fabricators and the builders.
Door knocking just presents the individual as a nuisance, as does phone calls. Advertisements in local paper can be useful, but delivery of this paper is poor, with it just being thrown into gardens, the plastic wrap is not much protection. So during winter the paper gets soaked with rain, during summer it can soaked by sprinklers watering the gardens. The result the paper often just gets picked up and thrown straight in the bin. Advertisements in other papers more useful, but can otherwise be expensive.
The fundamental problem is that engineering is relatively abstract and esoteric, and consequently of little interest and value to the community. Engineering services need to be made more accessible, more tangible and more value to the community which they serve.
Not sure how I can do that, but if do not seek, will not find.
Earlier in the year I created some additional blogs. I have now modified this blog, removing some of the pages and changing their menu tab to link to these other blogs. I have also added some extra tabs to link to other sites where I have uploaded stuff.
On the other hand there has been a down turn in work, our regular clients have experienced a reduction in work and that has flowed onto us. As for private individuals, and small builders with one-off projects, whilst they represent some 80% of projects, they represent very little in terms of income, like around 20%, yet they consume a disproportionate amount of time. Their emergencies and urgencies tend to result in them applying pressure to jump to the front of the queue, and otherwise cause delays for our regular clients. Their projects also interfere with our capacity to pursue larger projects. They contribute to keeping our earnings low and barely scraping in incomes equal to the Federal minimum wage. That I don't so much mind, but I object to the hassle and the pressure.
I mean, there are people in the world who don't have housing and our time is wasted by people who don't follow the rules get into a mess and expect we dig them out off a hole for a low fee. Meanwhile people who try to do the right thing, have to have extreme patience, as they keep getting pushed further and further along the queue.
To me it seems there is a need for some means of providing engineering services like legal aid. Though I did take a look at legal aid services, they seem to have highly restrictive requirements as to who can get such aid.
The alternative is to design a service which properly informs people, so that they don't build stuff without approval, and so that they don't produce DIY applications. More prescriptive building solutions are required along with the necessary evidence-of-suitability.
The problem however are people who do not care, think they know what is required, and do not do any research. Such people are always going to be around, the main people to serve are those who go looking for information but cannot find anything suitable. Those who don't do the research, and think they can do what ever they want on their property no matter what hazards it poses to the rest of the community, will hit a bigger problem. That problem, will be no one to get them out off a mess. Since they don't see any reason to get building approval in the first place, they also don't see any reason to pay for the design and engineering services required to get approval. So this bunch are not really worth while clients. Can generally tell who they are from the start by their attitude, the difficulty is telling them to take a hike at the first meeting, and that not interested in their project. I believe it is preferable to refuse service to these people, Assisting them just encourages them to continue disregarding the rest of the community. Members of the Engineering team have sworn to a code of ethics, which typically places the community first, above the client and above the employer.
Sure much of the time, the city councils are just being picky, and its all a matter of just getting paper work in place. The city council doesn't really want to enforce a demolition order: it makes them look mean. But there are some members of the community who need to learn that their property is part of the greater environment and just about everything they do to their property has an impact on their neighbours.
Any case there has been a down turn in work load, and locality is not really a major issue any more. As most work has always flowed in from regular clients either by the telephone, fax, post, or email. In terms of post that is often in the way of clients dropping documents off in our post box after hours. We have lost our land line telephone number, but most clients already have either our email address or mobile phone number: and for a while now most work has flowed in via email. With only occasionally seeing people in person. Not getting out off the office can be some what depressing.
Still it would appear that an Internet based information resource, both with information provided gratis and other information provided for an up front fee, would resolve many issues. Admittedly there are plenty of sites already, but few providing the engineering information, and further more it is clear that people are not finding the information that is available.
Informing people has always been a problem for small business and organisations. Mail leaflet drops can be expensive, and reach few people, with the leaflets typically going straight in the bin. Yellow pages advertisements don't really attract much attention, may be good for some services but not much use for engineering: its too specialised. People may look in yellow pages when told they need an engineer, but they don't look otherwise, they don't know what they are or that they need such services. Engineers services are thus not altogether in the appropriate place in the phone directory. Being elitist not necessarily a good thing: engineers really need to be along side the drafters, fabricators and the builders.
Door knocking just presents the individual as a nuisance, as does phone calls. Advertisements in local paper can be useful, but delivery of this paper is poor, with it just being thrown into gardens, the plastic wrap is not much protection. So during winter the paper gets soaked with rain, during summer it can soaked by sprinklers watering the gardens. The result the paper often just gets picked up and thrown straight in the bin. Advertisements in other papers more useful, but can otherwise be expensive.
The fundamental problem is that engineering is relatively abstract and esoteric, and consequently of little interest and value to the community. Engineering services need to be made more accessible, more tangible and more value to the community which they serve.
Not sure how I can do that, but if do not seek, will not find.
Earlier in the year I created some additional blogs. I have now modified this blog, removing some of the pages and changing their menu tab to link to these other blogs. I have also added some extra tabs to link to other sites where I have uploaded stuff.
Tuesday, August 13, 2013
Cold-Formed Steel Shed Industry: part:#3
The previous two blogs:
Cold-Formed Steel Shed Industry: part:#1
Cold-Formed Steel Shed Industry: part:#2
largely considered scripting in Acad LT to autogenerate the framing plans. Whilst the posts appear to be popular I hazard a guess people may not be finding what they went looking for, so I thought I would create a brief summary of the more useful posts here and elsewhere more directly related to design of sheds.
For discussion about cold-formed steel sheds, pre-engineered buildings (PEB), pre-engineered metal building systems PMBS. There are various groups on LinkedIN, the one I have created is:
Pre-Engineered Manufactured Building Systems
Rather than being limited to buildings it's more broadly covers building systems: sheds, carports, verandahs, scaffolding, timber framing to AS1684. Basically anything which can be configured to suit a particular purpose without going back to first principles for engineering analysis.
Also have the group:
Pre-Engineered Manufactured Structural Products
This group set up primarily to cover structural products, or independent components of structural building systems. For example bolts, balustrades, base plates, bracing. One again if pre-engineered then products should be capable of being selected with out reverting to first principles for engineering analysis.
SHEDS
The following design tools/aids are available for cold-formed steel shed design.
For typical 3m frame spacing:
Design Chart for C-Section Frames AS1170.2 Terrain Category 3 (TC3)
Design Chart for C-Section Frames AS1170.2 Terrain Category 2 (TC2)
These charts were manually drawn in AutoCAD from the charts in:
For C-Section frames at various frame spacings.
Cold-Formed Steel Shed Industry: part:#1
Cold-Formed Steel Shed Industry: part:#2
largely considered scripting in Acad LT to autogenerate the framing plans. Whilst the posts appear to be popular I hazard a guess people may not be finding what they went looking for, so I thought I would create a brief summary of the more useful posts here and elsewhere more directly related to design of sheds.
For discussion about cold-formed steel sheds, pre-engineered buildings (PEB), pre-engineered metal building systems PMBS. There are various groups on LinkedIN, the one I have created is:
Pre-Engineered Manufactured Building Systems
Rather than being limited to buildings it's more broadly covers building systems: sheds, carports, verandahs, scaffolding, timber framing to AS1684. Basically anything which can be configured to suit a particular purpose without going back to first principles for engineering analysis.
Also have the group:
Pre-Engineered Manufactured Structural Products
This group set up primarily to cover structural products, or independent components of structural building systems. For example bolts, balustrades, base plates, bracing. One again if pre-engineered then products should be capable of being selected with out reverting to first principles for engineering analysis.
SHEDS
The following design tools/aids are available for cold-formed steel shed design.
For typical 3m frame spacing:
Design Chart for C-Section Frames AS1170.2 Terrain Category 3 (TC3)
Design Chart for C-Section Frames AS1170.2 Terrain Category 2 (TC2)
For C-Section frames at various frame spacings.
These charts can be generated for any structural section using the design engine found at ExcelCalcs. It isn't a user friendly application and requires programming knowledge to modify data and run.
For determining the design actions to AS1170 and the design-action effects on a simple portal frame (Gable Frame: doubly pitched roof), with fixed/rigid bases, using Kleinlogel formula a workbook is available here.
For additional Kleinlogel formula extracts of the table of contents of Kleinlogel rigid frame formula is available here. Information from Kleinlogel Beam formula's which may be relevant to the use of the rigid frame formula can be found here.
Related Posts:
Other Blogs:
Thursday, July 04, 2013
Some Interesting Articles
Some interesting articles I will comment further on when I get time:
1) Confessions of a Young Professional, Engineers Australia Volume 85 No. 4, April 2013
2) The 30 year Failure Cycle, The Structural Engineer, Volume 91, Issue 5, May 2013 (IStructE)
3) How can Structural Engineers Contribute towards disaster mitigation, The Structural Engineer, Volume 91, Issue 6, June 2013 (IStructE)
1) Confessions of a Young Professional, Engineers Australia Volume 85 No. 4, April 2013
2) The 30 year Failure Cycle, The Structural Engineer, Volume 91, Issue 5, May 2013 (IStructE)
3) How can Structural Engineers Contribute towards disaster mitigation, The Structural Engineer, Volume 91, Issue 6, June 2013 (IStructE)
Subscribe to:
Posts (Atom)