spettitt Posted January 9, 2023 Share Posted January 9, 2023 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 Quote Link to comment
Vectorworks, Inc Employee Nikolay Zhelyazkov Posted January 10, 2023 Vectorworks, Inc Employee Share Posted January 10, 2023 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 Quote Link to comment
spettitt Posted January 10, 2023 Author Share Posted January 10, 2023 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. 1 Quote Link to comment
Vectorworks, Inc Employee Nikolay Zhelyazkov Posted January 10, 2023 Vectorworks, Inc Employee Share Posted January 10, 2023 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? Quote Link to comment
Vectorworks, Inc Employee Nikolay Zhelyazkov Posted January 10, 2023 Vectorworks, Inc Employee Share Posted January 10, 2023 1 hour ago, spettitt said: I will do; I'll put it in the wishlist forum later today, unless there is another facility for reporting these. - Yes, the forum is ok, just make sure to put ConnectCAD in the title or share the post here, so that we can easily find it. Quote Link to comment
spettitt Posted January 10, 2023 Author Share Posted January 10, 2023 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. 1 Quote Link to comment
alexmootv Posted February 2, 2023 Share Posted February 2, 2023 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 Quote Link to comment
Vectorworks, Inc Employee Conrad Preen Posted February 3, 2023 Vectorworks, Inc Employee Share Posted February 3, 2023 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 Quote Link to comment
Vectorworks, Inc Employee Conrad Preen Posted February 3, 2023 Vectorworks, Inc Employee Share Posted February 3, 2023 @alexmootv @spettitt If you have some extra categories to suggest this would be a very good time to tell and I can see if they could be added to our taxonomy. Conrad Quote Link to comment
spettitt Posted February 3, 2023 Author Share Posted February 3, 2023 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 Quote Link to comment
Vectorworks, Inc Employee Conrad Preen Posted February 3, 2023 Vectorworks, Inc Employee Share Posted February 3, 2023 @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 Quote Link to comment
alexmootv Posted February 3, 2023 Share Posted February 3, 2023 @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 Quote Link to comment
spettitt Posted February 3, 2023 Author Share Posted February 3, 2023 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... 1 Quote Link to comment
Thomas_ Posted February 26, 2023 Share Posted February 26, 2023 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 Quote Link to comment
Recommended Posts
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.