Disable Automatic Cable Type Based on Signal

[garrettohler]

After transitioning to VectorWorks 2024, there seems to be a new feature that automatically assigns a cable type based on the signal.  Previously, that was not the case.  It's detrimental to our current workflow that utilizes larger "signal buckets" primarily for the purpose of a cable number prefix.

 

Signals are Audio, Video, Lighting, Network, etc.  "Audio" can have many cable types inside of this category, but once you have assigned a cable type to a signal, any time you move devices the cable type is overwritten based on the signal.

 

Is there a preference that would allow for disabling this function?  If not, could there be?

[garrettohler]

Similarly, the cable type symbols used to be based on a text style, but now they are easily changed with the active text settings in the main toolbar.  This leads to accidentally changing the fonts and the drawings looking sloppy.

[spettitt]

58 minutes ago, garrettohler said:

but once you have assigned a cable type to a signal, any time you move devices the cable type is overwritten based on the signal.

 

There does seem to be some auto-assignment going on yes, but I can't reproduce cable types being overwritten when a device moves. If I change or remove a cable type, it remains if I move the device. It seems like it notices what cable type you use for a given signal type and tries to place future circuits using it.

 

58 minutes ago, garrettohler said:

Similarly, the cable type symbols used to be based on a text style, but now they are easily changed with the active text settings in the main toolbar.  This leads to accidentally changing the fonts and the drawings looking sloppy.

Can you screenshot what you mean by the cable type symbol? 

[Conrad Preen]

@garrettohler Could you send us a Vectorworks document that shows the behavior and the steps we should take to reproduce the problem?

 

Conrad

[garrettohler]

 

@Conrad Preen  I think the video demonstrates the issue clearly.  If you need a file as well let me know, but it happens on all of our files.

 

21 hours ago, spettitt said:

There does seem to be some auto-assignment going on yes, but I can't reproduce cable types being overwritten when a device moves. If I change or remove a cable type, it remains if I move the device. It seems like it notices what cable type you use for a given signal type and tries to place future circuits using it.

 

It seems that I was wrong about cable types changing when a device moves.  However, the second clip shows that the cable type font can change.

[Conrad Preen]

@garrettohler Thanks for reporting this - we'll look into it.

 

Conrad

[Conrad Preen]

@garrettohler I've filed a bug for this and we will get it fixed as soon as possible.

 

Conrad

[garrettohler]

@Conrad Preen  It appears that this was half fixed in the latest patch (or I was talking about two different bugs).

 

VB-203617 - Circuit cable type is changed on reconnect was fixed!

 

However, another fix I'd like to see is the auto-assignment of cable types.  Any time you assign a cable type to a signal (EX: S1 to SPKR), then any newly created cables are automatically assigned the last selected cable type.  Is this a bug or an intended feature?

 

If it is a feature, is it possible that it can be incorporated into a preference? 

[Conrad Preen]

@garrettohler it's a feature! It rests on the idea that the last selected cable type for that signal is likely to be the one you want in the next case. To me that doesn't seem like an unreasonable assumption. But since this is causing you problems let's have the conversation about why, and see if we can find a better workflow.

 

From what I understand, the problem you are facing is that the software is making the wrong guess instead of doing nothing. And it's much harder check each item to make sure it's not the wrong thing than to fill in the blanks. Is that the issue?

 

Here are some ideas of mine to get the ball rolling.

 

Option #1 - leave cable type as a totally manual assignment the way it used to be.

 

Option #2 - improve the prediction of cable type. Find a better basis for guessing what you want. Or at least not guess when it's not a sure thing.

 

Option #last-of-all - Adding a preference. This is something I try very hard to avoid. Software should just work.

 

Other random thoughts:

 

You are using broadly-defined signal types ("buckets") for the purpose of cable number prefixes. Presumably these are your own signal types? so you have control over whether a cable and connector type is assigned to them. If you don't have anything assigned, isn't that Option# in my list? You can also un-assign the default cable types for all the application folder signals that you use.

 

Another thought - you are doing this for cable number prefixes - correct? The prefix is editable for all signal types, application and user. So how about editing the prefixes to your taste and saving all this in a template?

 

Let me know what you think.

 

Conrad

[garrettohler]

@Conrad Preen  Sorry for the very late reply.  

On 6/3/2024 at 4:06 AM, Conrad Preen said:

From what I understand, the problem you are facing is that the software is making the wrong guess instead of doing nothing. And it's much harder check each item to make sure it's not the wrong thing than to fill in the blanks. Is that the issue?

 

Yes!  That is exactly the problem.  Honestly, with a lot of the devices that we use, it's very quick and easy to assign the cable type after by just selecting all of the cables and picking the type.  For example, an audio console I/O box only takes a few clicks.  Most of my cables are type 'ML1' for everything that isn't network.  They all get an 'A####' prefix, as they are all the "Audio" signal type.

 

Where things get tricky, is with our "Network" signal type.  We often cycle between 4 different cable types: N1, N1S, NP, NPS (CAT5e UTP, CAT5e STP, Network Patch, Network Patch STP).  All of these signal types are commonly sharing devices, depending on the implementation for the install.  Using multiple signal types won't work, as they'll constantly need adjusted to get the right signal on each side, though I do know the prefix could be the same for multiple signals on the cable IDs.

 

So, once I assign a cable type, then every network cable that I draw following that takes on the last used cable type.  Personally, having it default to '---' made it much easier.  I could assign the ones that I wanted to and leave some for later.  Some of those I might apply the cable type in bulk.
 

On 6/3/2024 at 4:06 AM, Conrad Preen said:

Option #1 - leave cable type as a totally manual assignment the way it used to be.

 

This would work best for our workflow, but others may be liking this feature.

 

On 6/3/2024 at 4:06 AM, Conrad Preen said:

Option #last-of-all - Adding a preference. This is something I try very hard to avoid. Software should just work.

 

Personally, I think this could be ideal.  There's already a ConnectCAD preferences window that allows you to customize the software to work best for your workflow.

 

On 6/3/2024 at 4:06 AM, Conrad Preen said:

Option #2 - improve the prediction of cable type. Find a better basis for guessing what you want. Or at least not guess when it's not a sure thing.

 

While I don't dislike this idea, I think it would be very hard to implement.  You'd basically need a table that compared signal type and start/end connectors and then you'd have to specify the cable type you want in the table as well.  The last part of your comment is where the key is.  The software isn't really guessing, it's just going with the last cable type you used, which is often not helpful.

 

-----------------------------------------------------------------------------------------------------

 

Finally, here's an example from our drawings that may add some context.  These are all network signal cables.  You'll see the connectors in this example are BW (bare wire) and RJ45.  Some of the cables are patch cables and some are riser cables going to the keystone patch bay.  Some are STP and some are UTP.

 

 

[Conrad Preen]

@garrettohler OK in this case I will go for a preference setting. I've filed a request for this.