Jump to content

Conrad Preen

Vectorworks, Inc Employee
  • Posts

  • Joined

  • Last visited

Posts posted by Conrad Preen

  1. Hi @joster


    You can use the 3D Rack object to visualize the layout of your console bays to a higher degree of accuracy. The way to go is to drag your equipment into standard 2D rack objects without worrying too much about what they look like. Then elsewhere place a 3D Rack object for each of the 2D Racks and assign each 3D Rack to it's corresponding 2D Rack using  the popup in the Object Info Palette ( easier to do than to describe !!! ).

    Now again in the OIP set the rack style to Console, set the slope of the bay, set the width of the side panels and you get a barebones rack-mounting space that displays your equipment. Insert that into the models created by your console builder and you're done.





  2. @Dendecko It does work, I just tried it now. You'll just need to include the Socket.tag parameter in your report and you'll have to change both the Name and Tag.


    The reason Devices and Sockets have separate name and display tag parameters is because on drawings you need to save space while in reports and lists you need longer more descriptive naming because you don't have the visual context.



  3. @SAmmerman It's always the same at this time of year. The questions we get are 90% stuff that is about to change for the better 🙂.


    I understand your frustration. However in the last 20 years no-one else has raised this issue. The way DA's are drawn is pretty standard, and it's useful to be able to quickly set the number of outputs. That doesn't mean that I don't want to accommodate your wishes, but I also have to consider all the other users too and prioritize the use of limited resources.


    I've noted these points as matters to be improved.



    • Like 1
  4. @btgroves Just want to point out that there are better ways now to add extra info to ConnectCAD objects. You can automatically attach your own records and display their values. But you probably know that. We will continue to support the old way but I want to encourage everyone to go towards attached records.

    Regarding your question, do you want to PM your CustomParams.txt file and the exact steps you took and I'll look into it?



  5. @wscooper I agree that we don't have a specific model for multicore cables and right now we leave this up to the user. In the interests of simplicity we have sort of merged the physical cable with the the signal connection. I am very conscious of how intimidating ConnectCAD can already be for the new user so I want to be very careful about adding yet more complexity. I hear you but I'm searching for a solution that will keep simple things simple.



  6. @SAmmerman Interesting food for thought. Just to give you perspective, we have to tread a fine line between having a feature-rich product and one that is simple enough for a new user to get useful work done in less than a week. The learning curve is massively important.


    So now some answers:


    1) you do not have to use our DA tool. You can create your own devices with the sockets laid out the way you want them. Nothing constrains you to rectangular boxes either. You can use any graphics you like inside a ConnectCAD device. You only have to create the device your way once - just click the Save as Symbol button to keep it and share it to other documents using the Resource Manager.


    2) Well that's an idea. But maybe even better just allow the Prefix to have a numeric suffix that determines the starting socket number. Say the Prefix entry is PORT05 then the series created would be PORT05, PORT06, PORT07... formatting and start number in one go without any extra UI.





    • Like 3
  7. @spettitt thank you very much for the feedback. These are all basically content wish-items. The extent to which they can be addressed depends on available resources. I will log them but at the moment I can't make any promises.

    Of course you can develop this for your own use including adding extra classes. If you create a well-structured library I could certainly propose the idea of Vectorworks buying in this kind of content from power users.







  8. @wscooper I think we need to moderate our expectations. Cable cross-section is calculated as a rough guide to help estimate the requirements for cable containment (trays, ducts etc.). The cross-section is calculated as diameter x diameter - nothing too clever. And that needs to be de-rated to take account of cables passing over each other as they turn corners.


    The realities of installation can make a huge difference to how much space is taken up. Same is true of cable lengths. An installer whose brain isn't functioning can destroy any estimates simply by dressing the cables in a weird way. Then add to that the fact that cables come on spools of a give length so again your installers can easily cost you several extra spools. And it might not even be their fault - it could just be logistics.


    Of course if there are ways to improve this in a manner that is practically useful I'm all for it. But let's not chase the dream of a perfect computer model only to have it trashed by the realities of life on site.



  9. There are two cases really:

    1. when you don't know the equipment to be placed but you have to design the cable paths
    2. when you already know the equipment.

    I think for the latter case it would be quite nice for an equipment item to be able to function as a drop point so as to save having to place both. But we (ConnectCAD team) need to talk this one thru to make sure there aren't any rock in the road.



  10. Hi @wscooper this is a way for you to indicate that a socket is the termination or source for multiple circuits. It isn't anything particularly clever. When you set # Circuits to a value > 1 that number will be displayed next to the socket. And it will appear in Circuit reports. ConnectCAD doesn't do any checking to see if the values make sense - that's is left to you the designer. Essentially it's just a visual aid.



    • Like 2
  11. 2 hours ago, wscooper said:

    The only down side is it's a two-step process as every drop point now would then need to have a device connected down the line at exactly the same point, for example a ceiling speaker, or to explicitly define a cable along the cable path.


    I fully agree! Interesting suggestions too. There maybe a way forward like that but I will need to work through all the cases. I'll be back!



  12. @wscooper Hi Will,


    This particular thing goes both ways. The line between equipment and drop points is blurred. There are times when you'd like to take a cable path to a piece of equipment and there are times as you say when the drop point is in effect the end point of the cable. These things keep me awake at night!


    The reason why we have drop points at all is workflow. Quite often you have to make decisions about the physical routing of cables long before you have any idea of what will be connected to them. Say you are called in as an AV consultant on a new building. You'll receive a bunch of architectural plans and the first thing you'll have to do is mark where cabling will go to - i.e. drop points. You will have to show what cabling (at least a guess) goes between them because some routes will become inaccessible during the building process. You can't specify equipment in detail before building works are complete because it will all be out of date by the time you install it.


    But there are other situations I agree.


    The way we do it now - attaching equipment  to drop points doesn't imply an extra length. The equipment simply uses the drop to access the path network. You could style a drop point to look like a patch panel, but then it wouldn't be in your equipment report. But you could customise the criteria of the report to include drop points. So maybe that's a way forward?


    I like that fact that you've raised this point. Let's keep the discussion going and who knows maybe an even better solution will emerge?



  13. @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?



  • Create New...