Jump to content


  • Posts

  • Joined

  • Last visited


56 Excellent

Personal Information

  • Location
    Victoria BC Canada

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah, It only amounts to about 110 grams now for a 6M length of average sized W200. Not enough to worry about anymore. There is more error in the steel mill manufacturing process than that.
  2. Yes, I absolutely have made an error. I was using radius as Diameter. 20.02x20.02=400.8 10.01x10.01xπ=314.787 Δ 86.01 2914.82+2914.82+1655.25+86.01= 7570.90 against 7573.19 mm2 Δ 1.1 2.29 (I really need to use a calculator more often) Not as bad as I had figured.
  3. I think this has been around for some time but I never needed accurate area calculations before so I didn't take notice. The calculation of polyline areas presented in the OIP is outside of standard acceptable tolerances. I only used the WideFlange because I was attempting to calculate weight when I noticed the error and that it was significant enough to alter the weight of a beam from which cost estimates are derived here in Canada. Have I missed something???
  4. Thanks @ Kazemester, Hmmm, I took a look at the implementation this morning for a mechanical fastener. It would seem that this Ifc data is still very much a manual process prone to user error. As an example I created a 3d bolt using VW's Fastener tool. Then it was necessary to use "IFC..." tool on the instance but VWs is not yet filling in applicable fields with relevant data for the application's built-in objects. Minor description or object type differences or dimensional accuracy when keying in nominal length and diameter would cause the appearance of different products which are actually the same. Even the need for the document drafter to run the "IFC..." tool on each instance of a plug-in object and not have a global setting doing this for the for the built-in objects will result in errors for quantities. It would appear that utilizing Ifc categories for data storage to prepare material lists is premature, especially for small manufacturers such as ourselves.
  5. Has VW presented, provided or adopted a framework for identifying materials and items? Is there a list of fields that are be filled in when creating objects to be used in construction documentation? I'm asking in the context of generating materials lists from objects found in the drawings. Programs which are specific to the steel construction industry have these materials lists on every page that are loaded with items present on that page. They present quantities, sizes, name, standards and materials references, item source page and item destination assembly pages among other remarks. So I was requested to see if I could build one of these materials lists that was not reliant upon manually typing up a list for each page. (Trimble does something along these lines with their Tekla product) I believe this would require that the items in the VW document have an attached data record presenting consistent range of fields containing the enhanced details. Not wanting to reinvent the wheel I thought I would ask first before evaluating if this could be cost effective to attempt/implement my own take on the concept. Thanks.
  6. Yes you definitely have a few conceptual challenges. You can create a Tool plugin that could capture the user's selection and create an object plugin. But passing a handle into a record's field attached to the plugin would not work for a permeant instance of a plugin because handles are temporary in nature. Object plugins being creation scripts would need to know how to recreate the user's selection or where to find a premade definition in order to display it. Objects the user creates are simply stored sequentially as a series of hidden commands written in a layer's definition. You would need to name an object with a unique name to reliably find it again and there is no guarantee it was not deleted or manipulated in some way. Capturing the user selected object and stashing it or copying it into a symbol definition created by a Tool plugin would be probably the easiest start. A symbol's name can be stored in a field of an Object's attached record for retrieval by the script of the object plugin. You can think of a Layers, symbols and groups as containers, each with their own strengths and weaknesses, all three are parents to basic object creation commands.
  7. Well that is puzzling. I guess I'll have to put in down to VW's export script function adding in extra code. I drew the 3DPoly in a virgin blank file to see what the difference would be between a line drawn and a 3dPoly being drawn with a start point being 0,0,0 and end point being 0,0,1000. Thanks.
  8. Whether this helps or not. One of my plugins for drawing pickets in a fence could not create itself by collecting three points interactively from the user. It will edit itself if any existing defining points are moved. This is done through reassignment of the values stored in the instance's record. But because the object didn't yet exist during creation until after the object script completed the record I was attempting to place values into didn't yet exist. This was solved by creating a tool to place the first instance. The tool collects the three initial defining points from the user, executes the plugin and then replaces the values in the instance's record. By using a tool the plugin object created is free to run by its own script and not contained as an object within the creation script.
  9. The script output from VW for a 3DPoly is encapsulated by BeginGroup; and EndGroup; But the object created is not contained a parent group. 3DPolys cannot be Ungrouped per say and they cannot be entered for editing a sub part like the holes in a polygon or a helix. Is there an undocumented use occurring here? {Object Creation Code} NameClass('None'); BeginGroup; ClosePoly; PenSize(2); PenPatN(2); FillPat(1); FillFore(0,0,0); FillBack(65535,65535,65535); PenFore(0,0,0); PenBack(65535,65535,65535); Poly3D( 0,0,0, 0,1000,0 ); EndGroup; OpacityN(100,100); {End of Creation Code}
  10. I was reminded that a sweep does almost the same task as using a helix path for an extrude as long as one doesn't need to taper it down to a different radius. Tools that I have not used in a while. The sweep seems to have shaved off a few more KB.
  11. Thanks Pat, the change in focus really helps. I stripped down the Simpson like product which reduced the file to 20% of the previous version and then noticed that the model now more closely resembled Hilti's concrete screw anchor. So I copied and made the minor thread and text adjustments. Definitely using symbols for repeated instances will be required if I cannot pull them off as plugin items. <edit: also I'll be lucky if I am still doing this in 5 years let alone 50, so I will not be waiting around for technology improvements and operating system optimizations 🙃> #4x0.375 concrete anchor Sim to Hilti & Simpson.vwx
  12. LarryO


    Move the mouse near a viewport in question, then right click for the contextual menu. Near the bottom of the list it will show "edit crop" (in your language of course). That would only be a single click to access a viewport's crop. No script required.
  13. I have done some fasteners that I thought would be of some use in my work, but I modeled then and have found that the LOD (level of detail) required for differentiation from that of bolts and screws that are already in the library of tools has significantly increased memory usage and computational needs. Significant to the level that I don't think their use is feasible for anything more than a couple of instances in any one design layer or file. Attached is a screw in concrete anchor of which there are more sizes that I should typically use for detailing installations of steel assemblies. Any suggestions of changes that could make these workable? To make these as plugins I think I would have to figure out a more reliable way of illustrating the threads. My efforts of extruding along a helical path have been hit and miss as to whether the result can be processed by solid addition to the shaft. And that was doing it without scripting. I say scripting because I believe that direction would be far more successful at controlling memory use and the clutter of unused profiles in a file's symbol folder. I suppose I could create a library file that the plugin could retrieve each symbol from when called upon for use, but that wouldn't solve excessive file size increases with each instance of various fasteners. #4x0.375 concrete anchor Sim toTiten™.vwx
  14. Rather than this being a setting attached to the viewing environment it could be better implemented via dimensioning tool enhancement. There are a relatively small amount of tools in the drafting set that communicate measures so it would be easier to program an enhanced and flexible dimensioning system rather than altering viewport functionality. Improvements to viewport functionality are partially limited by its need to be translated to dwg format.
  15. Sorry I don't know how to reduce VW2022 file size. Included are the lengths available in Canada for 6mm, 7mm, 8mm [Sold as 1/4", 5/16", 3/8" nominally] While there are 5mm[#10] in three lengths here I didn't model them. Our engineer's don't fasten structural steel to wood with anything that small. In the GRK product the tread dies back into the shaft at the top end, the crown of the head is less prominent in GRK than similar Torx headed fasteners. The Torx star is only an approximation as are the locking teeth on the underside of the screw's head. RSS screws sim to GRK v2019.vwx RSS screws sim to GRK v2022.vwx
  • Create New...