Jump to content

David Poiron

Member
  • Posts

    127
  • Joined

  • Last visited

Reputation

52 Excellent

Personal Information

  • Occupation
    Architect
  • Homepage
    www.cparch.ca
  • Location
    Canada

Recent Profile Visitors

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

  1. At present we use Filemaker to create all the records and organize them by section number for a particular project and then export that to 24"x36" PDF, which we then reference in Vectorworks. Vectorworks worksheets are not nearly as adaptable graphically as tables are in Filemaker. We do think there is benefit to link the two but there are a number of missing workflows in Vectorworks it seems to make this work for our needs.
  2. We've been using FileMaker Pro to create an in-house database of products but linking it directly to anything in VW is proving to be a challenge. Each of our products has a serial number that we would like to link to objects in VW but we are at a loss of how to do so reliably - we've tried ODBC before but as one VW staffer mentioned to us recently that can be a brittle connection. In addition to the serial number our system has a three letter code for each section of the North American MasterFormat System (as that is easier to read than a bunch of section numbers), followed by a number for the object in that section for that project: say DHW-01 for a door handle for a particular project. The number changes depending on the project but the serial number (a 6 digit number) does not. It would be great to use data tags to extract the information from an object but it is difficult to make links to the extent we would like; even for symbols there does not appear to be a way to assign a serial number to the symbol that is persistent across all instances of the symbol, which is needed to make a link to an outside database. I am curious about the use of VWs Database Manager for this. I would like more information on @shorter s exporting and importing routines if he is willing to share.
  3. I ask for a "survey points file" in CSV format, which is a commas separate value file of all the survey point in a text file. Then it is rather easy to use the "Import Survey File" command to import the points into VW, creating stake objects that can then be made into a site model using the "Site Model From Source Data.." command. You need to specify the type and order of the information for each point: I use ID, Northing, Easting, Elevation, Description/Note. Tell the surveyor what order you want the information. Be careful of survey points that are not at grade. They can be stripped out of the CSV file prior to import or removed after importing.
  4. @bcd Thanks for the suggestion, but unfortunately I think this is even less automatic than our current workaround, which is to put the layer level as a negative amount in the definition for the data tag for each building floor level.
  5. We ended up creating a tag for each level and minusing the layer level from each definition in the data tag for levels 2 +. It worked, but there should be a definition for the height of the grid tool relative to the layer as opposed to the origin, so that one tag is sufficient.
  6. Does anyone know why data visualization would work in plan and in 3D but not in section? I am using it to add colour to space objects based on their names.
  7. We are using the ceiling grid tool and are trying to tag the height of the ceiling grid. We are using the #IPZ# definition to get the height, which works well when the layer elevation (Z value) is zero. When the layer elevation (Z value) is say 10' (as it might be on the second level of the building), it adds 10' to the ceiling height value for the tag. Therefore, a ceiling grid object set to 8' on level 2 shows a tag value of 18' instead of the desired 8'. Is there any way to set up the tag with a different definition, or perhaps subtract the layer elevation to get the desired ceiling height value for each level of the building?
  8. Is there a way to attach a record format to a wall to other styled object so that the record format field entry is persistent (same) for all instances of the styled object?
  9. Strangely enough we have been using a data tag for space objects for reflected ceiling plans, as we need the space label location to change for these drawings. I had a thought that if I had multiline text, my room number which is above the text would need to move upwards automatically. I thought to use a coincident constraint between the two text objects, but this tool does not seem to work on the side, top or bottom centres of text objects, or the centre of the text objects. Do you have any suggestions on how to address this apparent shortcoming?
  10. It would be nice to have multiline text in space objects so longer names do not bleed off the edges of the object.
  11. Here his a quick test file with walls, a roof and floor cut and pasted into a blank file. I have indicated 4 separate tags. Unfortunately in section, VW is not recognizing the roof and walls with the tags. This is a common occurrence which we struggle with daily. Sometimes they work, sometime not. tag test.vwx
  12. I think you are saying that there would still more than one data tag but a script would figure out which one is required and place it accordingly? I would not know how to script that but it sounds interesting. We actually have three tags currently 1. one for "vertical" walls in plan and section 2. one for "horizontal" walls in plan 3. one for roofs and slabs in section.
  13. From a workflow point of view, we are trying to get the same information (reference/mark) from each object (roof face, slab or wall) - we are tagging building assemblies. At this point we need at least two data tags to access what we see as the same type of information from different object types. If the "Current Tag Field Definition" field allowed for some calculations/logic, then we could perhaps add multiple criteria in an if or case statement. Or perhaps a pset can be established that can take the same field across multiple object types - not sure how that works internally. Fire ratings, sound ratings and the like are all fields that we see should be accessible across roof faces, slabs or walls. Of course I would like to see things happen automatically, but would be curious as to how this could be scripted as a workaround.
  14. For some reason the roof face and slab objects use the slab pset and so I can use one data tag for both those object types. Walls have to be a separate data tag. On another note, I have a difficult time tagging assemblies in section - even when the viewport is set to not show objects beyond, it seems to want to find objects beyond the cut plane instead of objects at the cut plane for some assemblies. Anyone else have this problem? VW 2021 SP2.
  15. Is there a way to set up a single data tag to extract the Mark for walls, roofs and slabs, but not other objects? I though OSTYLE would work but it grabs pretty much everything.
×
×
  • Create New...