Scott C. Parker

Yes, it's a bug in update 3. It's been fixed in the forthcoming update 4. It'll be another month or two till it's released. You may need to update the cable style once update 4 arrives.

There'a recent bug about the middle tag landing at the end if the cable parts have lengths beyond the drawn length of the line. It's being worked on. Not sure if this is the issue for you though... Please post a sample file so that the collective can take a look. It’s best to copy the problem items into a new file to keep the file small and avoid any NDA issues at hand. Please use a definable file name. We get so many named “sample.” 🙂 Thanks, Scott

Please post a sample file so that the collective can take a look. It’s best to copy the problem items into a new file to keep the file small and avoid any NDA issues at hand. Please use a definable file name. We get so many named “sample.” 🙂 Thanks, Scott

Try these... LMK how it goes. If these workflows don't work, please post a sample file so that the collective can take a look. It’s best to copy the problem items into a new file to keep the file small and avoid any NDA issues at hand. Please use a definable file name. We get so many named “sample.” 🙂 Thanks, Scott BridlesToHoists.mp4

This is something were working on for future updated schematic views. Until then, there is a workaround that allows you to use a single label legend but have multiple versions of the channel or other fields. Basic workflow: open the label legend directly from the resource manager. Duplicate the channel field and change its class to something like channel-2. You can then move this one around so that it works in the schematic view like you would like it to. Now, to deal with visabilities. If you place the schematic view into either a design layer report or interview port on a sheet layer and then adjust the visibility of the classes, you'll end up hiding the wonky label legends and use just the ones you want. If you have trouble, post a sample of your file. Here's mine. SV LL Workaround.vwx

Basically, yes, via the bridle tool. In the Bridle Preferences dialog, if you set the desired hoist, the bridle automatically adds it as bridles are placed. The above replaces the down leg with the hoist.

Please post a sample file so that the collective can take a look. It’s best to copy the problem items into a new file to keep the file small and avoid any NDA issues at hand. Please use a definable file name. We get so many named “sample.” 🙂 Thanks, Scott

Sorry, not yet. Still on the list for future improvements.

Perhaps I misunderstood your query. When I delete the two "blank..." templates I referred to, and then create a new file in VW, the hex information is fresh as a daisy. While this is true, the conflicting thought here is that since the "fresh file" is still based on a forward translated version of the existing blank template file, it's not the template. It's often the gunk picked up through the years in the user's dusty files used repeatedly. This is why things are often fixed when we ask users to copy/import items from an old file to a new "blank document." Often resulting in a solved issue. When I was working in production, I would rebuild my in-house templates every year. But, they all would still have the HEX start date of VW24. I didn't bother deleting my Blank templates.

I can't say this will be a priority for the content team to make full new templates for each year's version of VW. What I can offer towards making a fresh blank template is this. Delete the blank.sta file from your defaults/templates folder and then open a new blank document. The resulting file will be a fresh empty file in which you can build clean templates with the current version as the originating version.

I've filed a bug report as I'm seeing the same issue.

This is a double post.

There are several ways to place a light in a drawing. One of the most reliable methods for setting the direction in both 2D and 3D is to place lights in Top/Plan view. There are three sections in the object info palette of a lighting device that set different rotation values. For your particular situation, you want to use option #2: 1. Sets the rotation of the symbol itself, which you will see in a 3D view. 2. Custom plan rotation checkbox that opens a plan rotation field. Here, you can change the rotation of the 2D symbol as seen in top/plan view. 3. Pan and tilt settings, which rotate the light itself as if you were focusing it. The C-clamp stays static on the pipe while just the body pans and tilts.

What tools are you trying to use when this happens? Some tools use the keys for specific functions when the tool is active.

Please post a sample file so that the collective can take a look. It’s best to copy the problem items into a new file to keep the file small and avoid any NDA issues at hand. Please use a definable file name. We get so many named “sample.” 🙂 Thanks, Scott

Here's a different approach, still a bit of a hack, but you can save the results for future use of the distro symbols. Here's a file to play with. Distro Data Viz Color Change MS.vwx

Workarounds are great in exploring possible workflows, and this is a great start. More work needs to be done to explore how these workarounds work with Braceworks. Though the system moves as one, BW is not seeing the items properly. Hence, not reading the sub part weights, as you mention. At the end of the day, the Side Arm tool wasn't designed to be a linear connect-pipes-together tool. What we're missing is the concept of pipe sleeves used as linear pipe clamps. We'll keep this in mind for the next iteration of the tool.

Whenever I make a custom item like this, I always look at how a VW version is built. When comparing your symbol to an existing Top Hat, we see the 3D needs to be set to Body instead of Lens. The 2D needs the parts record set to Lens. Give these a try and let us know how it goes.

My contact in our content dept is out today. I've forwarded your post and we'll get back to you asap.

Please post a sample file so that the collective can take a look. It’s best to copy the problem items into a new file to keep the file small and avoid any NDA issues at hand. Please use a definable file name. We get so many named “sample.” 🙂 Thanks, Scott

Great question. I've not tried it. Let us know how it goes.

In example, I've used the concept from the stirrup hanger and built a drop T using the ASD truss pipe parts. Putting the truss symbols inside the sidearm object uses the desired parts, but requires building an actual sidearm-compatible pipe with the pipe record attached. I've also been playing with adding the Pipe Record to truss objects, but I'm not ready to offer an actual workflow. I think one of the issues with your approach is that the truss items you're using lack the pipe record needed by the sidearm tool. Issue number two, and more importantly for this, side arms attach to other pipes at angles by default. The angle is set by the chosen clamp. The tool does not allow pipe end-to-end connections. Though I've thought about building some sort of custom pipe-sleeve type object that could trick the tool. No luck so far. Here's my file to play with. truss connection SCP.vwx Since the tool is new, we're eager for feedback about the workflow. Be as detailed as possible in how new functionality and workflows would work.

While I agree, there was a technical reason behind the missing None button. The sidearm always needs a clamp with a 3D Loci to have it connect to another pipe/truss. Without it, the end of the pipe wouldn't know where to connect and how to rotate. The No Clamp symbol has the needed 3D loci to take care of this need while removing the visible clamp geometry. Hence, if we had the None button, we wouldn't have the 3D loci.

Hmm. Sorry, it's not happening for me in your file. I don't know what to advise.

What are your snap settings set to? Depending on your settings, the shift key might be locking into an angle you didn't realize would be in effect.