How does D-Tools handle multicores cables

Forum Forums D-Tools General Forum Pre-Sales How does D-Tools handle multicores cables

This topic contains 7 replies, has 3 voices, and was last updated by  David Haddad 6 years ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #6020

    Jeremy Aston
    Participant

    Hi,

    I had an online demo of d-tools yesterday and overall was very impressed. One major problem struck me however – d-tools does not seem to handle cable cores.

    It is very easy to add a cable (wire) to a project and use this to connect devices together, produce labels etc however there are details in the project where the individual cores in a cable requires identification.

    For example – you have a room amp linked to a pair of speakers. If we use a single 4 core cable to run from the amp to the first speaker, break out two cores (red & black) and terminate, then continue on to the second speakers and terminate with the second pair (e.g. green and white) then how can this be shown? It’s one cable with one identifier but will go from two outputs to two different end points.

    Another example – what if I have a multo-core control cable linking sensors to analogue inputs. I have one cable running with, say, 4 pairs. How would this be identified?

    Another example. We often wish to show detailed schematics showing particular cores going to particular terminals on control devices. A classic would be RS232 or RS485 showing specific core colours going to pins. How can this be done?

    I guess what I am saying is that it’s fine to identify a wire going from point A to B but there is no easy way of then providing the engineer with the detailed wiring info required – even something as simple as which +/- terminals are to be wired to which colours on a speaker, RS232 connection or other control connections. As far as I can see there is no way of incorporating cores/sub cables into a cable to make the schedules more accurate and drawing more specific.

    Has anyone found a work around for this?

    At the moment it seems like we would still have lots of work to do to make our drawings and schedules as detailed as the ones we already produce. If the answer is to add that info to what d-tools provides us then where is advantage in using d-tools? There will be a load of info that cannot be put into the database, cannot be synced between drawings and still requires significant manual overhead.

    Any comments would be most appreciated.

    Rgds

    jez

    #7480

    Christian Brøndbo
    Participant

    Handling multiwire is a “known” issue, but mainly on the report side. From obvious reasons it makes little sense to do schematic drawings on pinout levels. For a RS-232 it might not be a big problem, but if you i.e. should have a connector panel at the FOH position in a concert hall with 4 pcs LK 85 (85 pins on each connector), you would rather quickly run out of printers large enough :) Keep in mind that the drawings you create should not only be for installation purposes but should be designed in a way that makes it easy for a service person that doesn’t know the installation to quickly get a overview on the buildup and wiring of the project. On special connectors I usually paste a pinout guide onto the drawing or simply print it on a separate sheet and adds to the install document pile. In SIX, you can easily create a custom report with all commonly used pinouts and add that to a grouped report that you run prior to installation.

    What we have done is creating a pinout guide on the right side of the drawing that covers the most used connectors (XLR, RS-232, Cresnet, balanced and unbalanced audio on phoenix, standard color order for a PFSK wire (up to 18 leaders) and RJ45). In the case of the 4-leader speaker cable it might make sense to pull that from the amp to a a room junction box and 2-leader wires from that to the speakers. That also seems as a better solution from a installation and service standpoint. Otherwise you might end up with a technician having to remove 30′ of outer jacket and then adding some kind of tape jacket to protect the two leaders that runs to the next speaker.

    It is fairly simple to do workarounds on schematic drawings for one wire with more than one leader, such as an audio multiwire cable or the VGA with Audio cable. It will not populate 100% right on the wire termination reports but you will get it to make sense on the drawing itself.

    I know they are looking into different solutions on how to handle multiwire and not at least bundled cable.

    I’ve been using D-tools for 12 years and have from time to another ran full woring trial versions of competing software. I’m still with D-tools and can’t see that change for a very long time. It has become a VERY powerful tool for our trade and it is designed to grow with you.

    Ah, one more thing: If the technician is not able to know what wire that should go where on a speaker terminal, the less expensive solution is to not have that person do the connections :)

    #7481

    Jeremy Aston
    Participant

    Thanks for your response Christian – you make some good points. I can see that it is possible to accommodate pinouts in the way you suggest.

    The biggest concern I have is that it is not possible to get the reporting sorted on termination reports. We have to provide lots of witnessed documentation as part of commercial installations and I can see that we are going to have to kludge a solution together if we are to use d-tools. For a piece of software that has been around for as long as d-tools I would have expected this to have been solved some time ago.

    On the matter of speaker cable, we don’t strip the outer jacket to the second speaker, rather we strip a short length from a loop at the first speaker to break out the first pair of cores. I get your point however. Re the technician – you are right re their capabilities – it was more of a simple example to show where the ability to work with cores or sub-cables in a multi-core is needed. I guess for the time being it would be possible to work with a main/sub cable identifier withing the program.

    Thanks again for your input – the fact that you have been using it for so long is a great testimony.

    #7487

    Christian Brøndbo
    Participant

    If you send me some examples (on PM) of what kind of documentation you need to provide I can send you examples of what reports we run and that is approved as sufficient documentation by consultants and used on tons of projects. We usually operate on two levels of documentation; Install and As Built. Install is the documentation we create prior to the installation (schematics, plan, elevation/rack layouts, wire termination reports, equipment usage list per location and a few other). The As Built documentation is what we provide the customer with at the time of the handover. This is mainly just a revised/updated version of the installation documents but with all changes made during installation. We also have a customized equipment usage report that also displays the serial No’s and if needed or required the firmware version on the unit at the time of installation. Not very much used as it usually becomes outdated on the first service visit :)

    We only work in the commercial market. As a fun fact I can mention that Norways largest oil company demands that all documentation on their AV installs shall be made in D-tools.

    #7482

    David Haddad
    Participant

    pigbite, a couple of comments here.

    1. I think the best way to document things such as pinouts is to provide a page that details an example pinout, as Christian says. I say that both as my opinion and as a matter of engineering practices :-), you really don’t want to be trying to detail things like pinouts on schematics. That’s sort of like having a set of electrical blueprints and trying to document the hot ground and neutral at every connection, it’s totally unnecessary. It’s also going to make drawings unmanageable because it would take up 10x as much drawing space.

    2. But if you insist, there is actually a way to do it, and it would be the same way that people handle bundled cable in D-Tools. Let’s say you have a Cat 5 cable and you wanted to document each pair. You would create a “master cable” with accessories for your individual pairs:

    Master: “Cat 5”.
    Accessory: Orange/Orange White
    Accessory: Blue/Blue White
    Accessory: Brown/Brown White
    Accessory: Green/Green White

    Now you can connect the pairs separately in a schematic because they are represented as individual cables. You can even give them names like “orange/orange white” to make it clear what they are. Using the above example you could even create 8 accessories if you wanted to for every individual strand.

    Where this is a much more practical solution is when you are dealing with bundled cables (2 Cat5, 2 RG6). Again, for your application I really don’t think it’s necessary and if anything will create a bit of a documentation nightmare This can all be easily covered on a single page named “specs” where you show that for instance, all 4-conductor speaker cables should be terminated as “white = L+, green = L-, red = R+, black = R-. And so on.

    Hope this helps!

    #7483

    Jeremy Aston
    Participant

    Thanks for the input David/Christian. I agree that on many schematics you would not want (or need) to show detailed pinouts and the tabular approach is more than adequate – in fact it is something we already do. David, your suggestion on dealing with bundled cables makes sense and I will try in out on a sample project later.

    We too work on design and as built documentation. I think some of my questioning comes from the type of work that we do get involved in – some of which is not A/V at all – and this does bring some additional facets to bear. For example, we get involved in commercial KNX shading and/or DALI lighting projects where we are building enclosures containing DIN rail mount devices. Typically we use DRM terminal connectors to provide the physical interface between the field and enclosure. Each DRM terminal takes a core and it is critical that the cores are correctly identified. The attached example shows the sort of drawing we typically produce. This is given to a panel builder so they can build the panel, then the finished enclosure is given to the site electrical contractors to wire the field connections. In this scenario, both of these other contractors may have no real knowledge of the detail of what they are wiring so need detailed and specific instructions.

    Maybe I am trying to get d-tools to do too much. At the end of the day, it would easily allow the quotation, proposal creation, higher level schematics and topology diagrams along with associated schedules to be built. Perhaps I am being unrealistic in my expectations in thinking that we could go to this level of detail but it would be great to think not!

    Thanks again for your input!
    [attachment=118]example.pdf[/attachment]

    #7494

    Christian Brøndbo
    Participant

    Ah, I’ve made a few of those drawings too. When needed I have added a frame or container around those components in the schematic drawing with a refferal to “see detail drawing xx.xxx.xxx.xx.x.” I’ve used the Line View sheet so I could use real pictures of the components and Visio shapes to create and label DRM’s. If you want to, you could use outline product drawings instead of pictures. Such detailing is mainly used to communicate the interface between our delivery and the electrician.

    #7495

    David Haddad
    Participant
    pigbite wrote:
    Thanks for the input David/Christian. I agree that on many schematics you would not want (or need) to show detailed pinouts and the tabular approach is more than adequate – in fact it is something we already do. David, your suggestion on dealing with bundled cables makes sense and I will try in out on a sample project later.

    We too work on design and as built documentation. I think some of my questioning comes from the type of work that we do get involved in – some of which is not A/V at all – and this does bring some additional facets to bear. For example, we get involved in commercial KNX shading and/or DALI lighting projects where we are building enclosures containing DIN rail mount devices. Typically we use DRM terminal connectors to provide the physical interface between the field and enclosure. Each DRM terminal takes a core and it is critical that the cores are correctly identified. The attached example shows the sort of drawing we typically produce. This is given to a panel builder so they can build the panel, then the finished enclosure is given to the site electrical contractors to wire the field connections. In this scenario, both of these other contractors may have no real knowledge of the detail of what they are wiring so need detailed and specific instructions.

    Maybe I am trying to get d-tools to do too much. At the end of the day, it would easily allow the quotation, proposal creation, higher level schematics and topology diagrams along with associated schedules to be built. Perhaps I am being unrealistic in my expectations in thinking that we could go to this level of detail but it would be great to think not!

    Thanks again for your input!
    [attachment=118]example.pdf[/attachment]

    Nice drawing, that helps me to understand better. FWIW I actually would like to see D-Tools be more powerful in this regard, I don’t know if it’s a D-Tools or Visio limitation. It would be nice to be able to define the number of conductors as a property of the item, and then when needed detail how those connectors get terminated.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.