Scott C. Parker

Take a look at the cable configuration of the unstyled cable before making the changes, and then look at the cable config after the changes. The first likely has cable parts, and the second, likely not. I have to dive deeper.

Yes, the cable tool looks at the connector of the light to decide what cable is needed. Or, to offer the adapters when needed. Yes, and no. Yes, you need to edit the XML if you want to use a custom name. Yes, the light has to use the same connector name. No? Wait Scott... Why no? Well, we read the UniversalName, but show the LocalizedName. In other words, if the xml file has this line: UniversalName="NAC3FX-W and NAC3MX-W" LocalizedName="PowerCON TRUE1" The Light Info Record attached to the light has to have "NAC3FX-W and NAC3MX-W" in the record's connector field, but the OIP will show the LocalizedName of "PowerCON TRUE1". Or, in other words, "NEMA 5-15" shows as "Edison." That's best. I make them and save them in my favorites folder. I also save a copy in a shared workgroup folder when working with a team. I have a file for 4wall, Christie, PRG, etc. This is especially helpful for cables. In fact, if I switch cable sets from 4wall to Christie, all my cables get updated/rebuilt with Christie's 4', 8', and so on, lengths for me.

Please post a sample file so that the collective can take a look. Please add info about what you're trying to report upon in the drawing. 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

Yes, I think it has something to do with your custom-edited cable. It could be that the name does not match what is in your xml file. 2026-02-06_15-12-12.mp4

Oh, yes, we can. Been here, done this. We are working on things to make power and data easier overall. You'd still need to manually add "PowerCon" and/or "True1." We don't expect that to change in the near future. You can. Simply choose the cable you want and then click on the button to not add the adapter when done. As for the connector on the light, since many rental houses offer a light with different connectors as their standard, we let the user make whatever changes they need. At some point, it'll likely be guided by the GDTF profile, and users won't need to change the record. I don't know when. When I was working in production, I had a version of a symbol for certain rental houses when their idiosyncratic methods countered the norm. It was easy enough to swap the fixture, and most items were updated.

I'm seeing the same issue and will file a bug. I'll let you know what I hear back.

The short answer is that were not supporting data cabling yet. Data cabling and support are in active development. The longer answer is that there are workarounds. In order to use the name Powercon true one, you would need to edit your CableConnectors.XML file and add the definition manually. We are no longer allowed to add it as part of the delivered content due to licensing issues. The fact that you can see it tells me your XML file has either already been edited or is out of date. When you edit your XML file, you'll need to save it in your user or workgroup folders as the XML file we deliver gets overwritten every time you update the software. When inserting cables, the cable tool is expecting you to click on a distributor rather than a light. The reason why it's temporarily working for you is that the link through the output connector thinks it's part of a distributor, but it's not. We need to let it suffer from this identity crisis in order to allow the link through functionality and were working on making it less confusing. The cable errors make sense because the lighting unit symbols in your document likely are specified to use a Nema 5-15 (Edison) connector. You'll edit this using the attached record choice when you right-click on the symbol in the resource manager and edit the connector code. This brings us to what an NAC3FX-W is. That's likely a leftover model number four Powercon connector. When viewing the XML file, you'll see that there is a universal name and a localized name. For Edison connectors, the universal name is NEMA 5-15, and the localized name is Edison. When you add your Powercon connector to the file, you'll likely enter: <Entry SocketPatchCount="3" UniversalName="NAC3FX-W and NAC3MX-W" LocalizedName="PowerCON TRUE1"> <Socket UniversalName="L1" LocalizedName="L1" /> <Socket UniversalName="N" LocalizedName="N" /> <Socket UniversalName="PE" LocalizedName="PE" /> </Entry> There is a step-by-step guide on how to edit the cable connectors xml which goes through the process of creating new connectors and how to error check the edited xml afterwords. https://university.vectorworks.net/mod/overview/view.php?id=3065 Other forum posts relating to this: https://forum.vectorworks.net/index.php?/topic/121796-changing-electrical-connectors-on-fixtures-and-accessories/#comment-527823 https://forum.vectorworks.net/index.php?/topic/118982-custom-cable-connectors/#comment-563914 https://forum.vectorworks.net/index.php?/topic/129629-cable-tools-power-and-data/#comment-563698

The inventory list is used to list all the pieces of truss, rather than listing hanging positions. You have 57 sticks of truss in the drawing, and 57 are listed in the inventory window. It seems like you're looking to have a list of each hanging position and how many truss are in each. This would be a worksheet report instead of using the general inventory counting method.

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.

A few thoughts to play with. If you make the terminator into a distributor, you can place it with the distro insertion tool, and it'll show up in reports; without connections, but it'll be there. You could make it into a lighting device and then use a cable to make the connection. It would then be in the cable reports. Making it into a cable could connect to the last unit and would show in the cable reports. If you want to get counts via the inventory system, add a virtual part of Terminator to your lighting devices with a default of zero and then select just the last lights of each DMX run and change the virtual part zero to a 1. This will show in inventory counts.

Received your file and I'm seeing the same issue. I'll file a bug.

As we work on adding data to the cable tools, we'll figure out a way to show terminators. Terminators are already available in the ConnectCad tool set for schematics and will work on a Spotlight power schematic, if one has access to CC. What this doesn't do yet is add a physical object to the last light in the DMX chain. I'm wondering if building a terminator as a device and then connecting it to the last light would work, as a workaround. I've not played yet, but the device might need to be a distributor object, a consumer object, or a cable object. Or, a combination. Once Data is officially supported, we can figure out a straightforward approach vs. a workaround.

The cable in the drawing does not have adapters assigned, so the tags are not reporting any data. If you select the cable and manually add adaptors via the OIP, you'll see the data populate.

Toto, sorry, as a new forum user, uploads are restricted. If you want to DM me your file, I can post it for us to take a look.

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

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.