Jump to content

Workgroup Signals: Categories


spettitt

Recommended Posts

I have quite a lot of workgroup signal types to define, which are things not covered in the stock definitions rather than 'company' versions of the stock ones. They cover all sorts of disciplines from touring lighting to installed show control, so the list is quite big and hard to navigate.

 

I tried to make categories in the text file by using:

Lighting(tab)=(return)

in the same way as the signals list in the app folder, but this puts all of the new WG signal types in to the last section of the stock signal types, rather than appearing under the Workgroup heading.

 

Should I be able to do this please? If so, what's the trick?

 

Thanks

 

Simon

Link to comment
  • Vectorworks, Inc Employee

Hello @spettitt,

 

Workgroup and user signals usually go in the workgroup and user categories on top of the list, so that they are more accessible to you. There was an update on this in VW 2023 and overwritten app signals remained in their app data categories, but this was reported as a problem and we are planning to restore the previous behavior and keep WG data in WG category and user data in user category in the future service packs.

 

If you prefer to have workgroup and user data in different categories, could you please submit a wishlist item for this so that we can consider it?

 

Best Regards,

Nikolay Zhelyazkov

Link to comment

Thanks Nikolay

20 minutes ago, Nikolay Zhelyazkov said:

There was an update on this in VW 2023 and overwritten app signals remained in their app data categories, but this was reported as a problem and we are planning to restore the previous behavior and keep WG data in WG category and user data in user category in the future service packs.

Oh no, that's a shame, I like what it does at the moment. If we redefine an app signal, we'd have to tell people 'Don't use this XXX in the App folder, use the WG one, but if there is no WG entry, then use the app folder!', which I'm sure will lead to confusion. It would probably work well for those who want to build up an entire set of WG signals and ignore the App ones, but for me, it's cleaner to just tweak the App ones as we need them and add new ones that don't actually exist.

 

That said, it would be great if there could be an optional special character at the start of a line in the WG signal types txt that defines whether it merges in the App list or appears in WG at the top of the list. Mega flexible and everyone happy! Default would be a revert to previous behaviour, but with a special character documented that CAD admins can add in the WG text file to get the 2023 behaviour for whatever lines are required. I'll add this to the wishlist.

 

20 minutes ago, Nikolay Zhelyazkov said:

If you prefer to have workgroup and user data in different categories, could you please submit a wishlist item for this so that we can consider it?

 

I will do; I'll put it in the wishlist forum later today, unless there is another facility for reporting these.

  • Like 1
Link to comment
  • Vectorworks, Inc Employee
1 hour ago, spettitt said:

Oh no, that's a shame, I like what it does at the moment. If we redefine an app signal, we'd have to tell people 'Don't use this XXX in the App folder, use the WG one, but if there is no WG entry, then use the app folder!', which I'm sure will lead to confusion. It would probably work well for those who want to build up an entire set of WG signals and ignore the App ones, but for me, it's cleaner to just tweak the App ones as we need them and add new ones that don't actually exist.

- I think that I might not have explained this well. What we are planning is the following. If you have both App and WG entries with the same name then you will see only the WG entry in the WG category, as we would expect that this is the preferred for usage. Is this correct?

Link to comment
5 hours ago, Nikolay Zhelyazkov said:

- I think that I might not have explained this well. What we are planning is the following. If you have both App and WG entries with the same name then you will see only the WG entry in the WG category, as we would expect that this is the preferred for usage. Is this correct?

Oh I see - so if I redefine LINE in the WG, then the LINE definition would move to only show in the WG section at the top of the list, and be removed from showing in it's original app location? If so, that sounds good.

 

My point about categories still stands though; the WG list at the top should be organised in to categories the same as the app folder, it's confusing to have a mix of categories in the list together. I'll make the post ASAP.

  • Like 1
Link to comment
  • 4 weeks later...

Hi All,

 

I think this has similar reference to my complaint of the new behavior in the below post @Nikolay Zhelyazkov.

 

https://forum.vectorworks.net/index.php?/topic/101459-v2023-workgroup-signals-and-connectors-not-taking-priority/

 

As @spettitt mentioned, we also as a company define our own signals, that in some case share the same name as the default ones. What we currently do as a workaround since Vectorworks will not display the workgroup version if it has the same name as one in the app folder is to delete those files and mark some as read only. Below is the procedure to only show what is defined in the workgroup and not the default app group versions. We do this every time we do a new install.

 

 

DELETE

C:\Program Files\Vectorworks 2023\Libraries\Defaults\ConnectCAD\ConnectCAD_Database

  • SignalTypes.txt
  • ConnectorTypes.txt

 

Create Empty file and Mark as Read Only

In some cases, we have found another area that causes a problem, but isn't consistent. We now do this out of precaution as well. Sometimes this file already exists. Delete it first and make an empty one that is read only.


C:\Users\Admin\AppData\Roaming\Nemetschek\Vectorworks\2023\Libraries\Defaults\ConnectCAD\ConnectCAD_Database

  • SignalTypes.txt

 

 

None of this helps with the grouping, which I would also like to make work. What it does do is ensure that what you define in your workgroup folders are actually displayed.

 

Hope this helps,

Alex

Link to comment
  • Vectorworks, Inc Employee

Well this is one those places where there are two kinds of people in the world. Those who want thousands of ready-made devices, and those who want to do their own thing.

 

Personally, I'm with you guys. I wouldn't trust a library device because I know what can go wrong. But we are in the minority which means that as far as libraries are concerned ConnectCAD has to "tick the box". Another issue to think about is collaboration. Increasingly we are seeing projects being handled by design teams drawn together from different countries and companies. If they aren't all singing from the same song-sheet things can quickly get into a real mess.

 

All this is driving us in the direction of keeping categories and types under Vectorworks control rather than users inventing their own. Regardless of my own opinion as a designer, I am definitely in favor of commercial success otherwise there won't be a ConnectCAD. I also have to bear in mind that the people who are happy with the status quo hardly ever post on the forum to tell us how happy they are. This is an unfortunate fact of human nature.

 

I'm not promising anything but we do try to please all the people all of the time! We will bear you comments in mind moving forward.

 

Conrad

Link to comment
40 minutes ago, Conrad Preen said:

All this is driving us in the direction of keeping categories and types under Vectorworks control rather than users inventing their own. Regardless of my own opinion as a designer, I am definitely in favor of commercial success otherwise there won't be a ConnectCAD. I also have to bear in mind that the people who are happy with the status quo hardly ever post on the forum to tell us how happy they are.

So far this thread has only been about custom categories rather than custom signal types...category organisation is a cherry-on-top really, and I'm all in favour of standardisation.

 

But when you say driving in the direction of keeping types under VWX control...just checking that the ability to actually add a workgroup signal type won't go away? There will always be endless protocols and applications not covered by the stock definitions, not because the stock definitions aren't up to the job, but our industry is just too vast and fast moving.

 

Re. more categories: although I will circulate the question here, I'm not sure there is really a need to add any more. My initial impression is that they are fine.

 

All this thread was about was achieving the following:

  • Workgroup
    • Lighting
      • sACN
      • ART-NET
      • MA-Net3
      • MA-Net2
      • etc
    • Audio
      • AVB Primary
      • AVB Secondary
      • etc
  • Stock
    • Lighting
      • Stock Type A
      • Stock Type B
    • Audio
      • Stock Type A
      • Stock Type B

As opposed to:

  • Workgroup
    • sACN
    • ART-NET
    • AVB Primary
    • AVB Secondary
    • MA-Net3
    • MA-Net2
    • etc
  • Stock
    • Lighting
      • Stock Type A
      • Stock Type B
    • Audio
      • Stock Type A
      • Stock Type B

 

Link to comment
  • Vectorworks, Inc Employee

@spettitt  I certainly don't want to take away the ability to add extra signal, connector and cable types. We could never keep up anyway. No worries.

 

Regarding the taxonomy of device definitions: we have the top-level categories based on the primary signal (video, audio, control etc.) and the functional type of the device (mixer, projector, camera, speaker etc.). I think it is rare that we'll need extra top level categories, but for sure the functional types have no covered every case by far (and some could be consolidated). The aim is to make it a bit easier to locate what you are looking for in the database. It will never be perfect.

 

As you say the industry is vast and fast-moving.

 

An interesting thing to consider would be to separate signal type and protocol. These days a huge number of devices communicate over Ethernet but use different protocols. Maybe its time to add Protocol as a separate socket property? What do you think?

 

Conrad

Link to comment

@spettitt I wasn't meaning to take over your post with the above issue. However, I think you will find with the current state of things sometimes Vectorworks overrides what you put in the workgroup files making the grouping not always work until this is fixed.

 

I personally liked @spettitt idea of being able to add these categories in the workgroup with a special syntax. I believe he mentioned "Lighting(tab)=(return)". This way as we add new signals to our workgroup, we can just create those headings in the file. I would love to have the ability to do what @spettitt is suggesting above, but I wouldn't want it defined by Vectorworks. This would emply Vectorworks is able to think of every edge case which is impossible. I would want to create the hierarchy in our workgroup files.

 

I also think the protocol vs. signal type is interesting as I face this often. However, I end up just making a new signal type for anything, even if it is ethernet. I think this could open up a can of worms however going to granular. If you did choose to start diving more granular however, the 7 Layer OSI Model, might offer some guidance as to how to structure things.

 

https://en.wikipedia.org/wiki/OSI_model

 

Thanks,

Alex

Link to comment

Getting in to more levels of heirarchy (above the current Signal > Connector/Cable Type) could just be too much I reckon. I will ask around here, but the lines blur quickly, for multiple protocols within a physical cable, things that are both logically a signal type and a protocol (Martin P3? I'm sure there are others), as examples. Then, do you colour by signal or protocol? Either way you'd run in to problems I think.

 

I've always viewed ConnectCAD as layer 1 - a line onscreen represents something physical (even if it's a pair of cores within a multicore or whatever). I feel this functionality might be better as a separate environment, a layer 2/3 environment that allows you to indicate logical protocol connections, especially where there are multiple logical connections within an ethernet data stream.

 

What I do feel like raising is functionality for main and backup/primary and secondary, however you want to call it. Indicating this is necessary on drawings, especially for digital audio networking. We've started to use two signal types with the attributes of the secondary being a dashed line of the same colour as the primary, but this means if we have 25-odd discernibly-different colours x 2 line types (continuous and ISO 03 dashed), we run out of colours quickly. We will likely double up colours for things that will never be on a sheet together, but it might be a long-term idea to have a separate way of tagging a circuit as redundant/backup/secondary, so that we are free to do whatever with attributes. Not sure what this would look like on the page, some kind of symbol or something, I don't know. Just an idea, but it saves us doubling lots of signal types. It would have to be a field that you could report by in worksheets as well though.

 

Also, related to that - it would be great to get dual-colour lines, so dashed orange/blue rather than just orange/space. For a company like us that deals in all of the different disciplines - it would make attributes for signal types so much easier. I'm sure it's limited by the Vectorworks attributes engine, but who knows...

  • Like 1
Link to comment
  • 4 weeks later...
On 2/3/2023 at 5:42 AM, Conrad Preen said:

 

An interesting thing to consider would be to separate signal type and protocol. These days a huge number of devices communicate over Ethernet but use different protocols. Maybe its time to add Protocol as a separate socket property? What do you think?

I will say there is possibility to this due to ethernet especially.  If you start documenting Network switches, and show protocols being transferred over (As well as VLANs etc.), I could see this being useful, but not quite as simple as one might like.  Would take a bit of work to get correct.

 

      Thomas

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...