I'm having an issue with a Wire Type that is defined to not get Wire Numbers assigned - get a Wire Number assigned when used with Source & Destination Arrows. Then on top of that the number that does get assigned to it is actually used again on a wire that should have a Wire Number. I have five groups like this and it is happening on all five.
We use a dashed Wire Type that is set to not have Wire Numbers assigned on our control schematics to define wiring that needs to be completed by the EC in the field. In this situation I have a field device shown with a field wire to Source Arrow which in turn goes to another sheet in the control schematic with a Destination Arrow on another field wire to a terminal block that is in our panel. So the Source Arrow is on one sheet and then the Destination Arrow is a few sheets AFTER. (See screenshots below)
The problem is with a Wire Number Retag it appears that the first field wire with the Source Arrow is actually assigned the Wire Number of 108 (although not shown or editable) because then on the sheet with the Destination Arrow it labels the second field wire with the Wire Number of 108. However, a few rungs below the SOURCE arrow on Rung 170 - another wire is given the same Wire Number of 108 also. It seems that (1) ACADE is taging the wire that shouldn't be numbered becuse of the Wire Type and (2) not realizing it tagged the wire it shouldn't have and then uses the same number again.
I am not sure if this Wire Number is being assigned because of the Source & Destination Arrows or what but I am not sure how else to show this setup without this happening. I was trying to set a Fixed Wire Number on the wire after the terminal block on the Destination Arrow end but I can't do that either becuse it is tied to the Destination Arrow.
Any ideas on how to get around this? Using ACADE 2011 v2.1.
I just discovered some other issues reguarding more wires of the same Wire Types getting numbered. I did have the "WIRENO" attribute hidden on the Source & Destination Arrows (because it should read ??? with no wire number) and sure enough after unhiding them it appears that every wire utilizing Source & Destination Arrows on a Wire Type that shouldn't be getting wire numbers is getting the same wire number per block. So now I have multiple wires on multiple blocks with the same numbers all over.
The weblinks for the screenshot are not available, i cannot open them, can you double check ?
Strange; this is the third network I have been on today since posting that and the links work on all three of those networks for me. Maybe something blocking the Dropbox domain on your end? Oh well - they are attached below.
I was able to duplicate this issue using page 4 of WDDEMO, as shown in the attached screen captures. I tried it with line-reference-based wire numbers and with sequential wire numbers. The results vary. J-Reese's scenario is worse because he is using sequential wire numbers, which of course should be allowed. With line-reference-based wire numbers (a.k.a. rung numbers) the wire number is not duplicated, but with sequentially-assigned wire numbers it seems that AcadE doesn't realize it has already assigned the same wire number, albeit to a source arrow, by mistake. This is evident in my example where wire number 16 is duplicated at line 430.
Suggestion: As part of an action plan to correct this defect, I would suggest that when a source and destination arrow are inserted on a wire type that is set for no wire number assignment, the WIRENO attribute should be automatically flipped to invisible.
Thanks for the confirmation Doug.
The bigger problem in the picture for us is all of our field wiring gets landed on terminal blocks in one location of our panel to reduce EC's making a mess our entire panel.
Therefore almost all of our Destination Arrows will be attached to a wire going into a terminal block. In your sequential screenshot example the wire number doesn't carrry over to the Destination Arrow because the wire is going to an indicator light and therefore forces a wire number change. In that situation the easy solution is to just hide the "WIRENO" attribute and then it doesn't really matter with ACADE assigning the Wire Number elsewhere. However, in almost all of our scenerios our destinations are going to terminal blocks and it actually does carry over the wire number to the Destination Arrow which in turn assigns it to terminal blocks. And in this case it is actually multiple terminal blocks throughout the schematic since like is shown on my third screenshot - there are acually 4 Source Arrows going to different locations and assigning 108 terminal block numbers.
Hidiing the WIRENO attribure works for some situations where the wire number is being forced to change on the Destination Arrow end by either fuse block, breaker or basicly anything other than a terminal block. To verify this in your sequential demo you could throw a terminal block in between your Destination Arrow and the indicator light and it should carry the wire number to the Destination Arrrow and assign 16 to that terminal block as well as the one on the next rung. That is the big problem for us. Especially since I just noticed this issue and we are ready to go to production.
The only temporary fix I can think of right now is to just use the generic Reference Only Arrows and fill the TO and FROM information in manually but that is taking a lot of smartness away and leaving quit a bit of room for error - plus taking more time than I have right now.
Even with the pilot light the wire number should have carried over from source to destination. Wire numbers should always carry over from source to destination, no matter the component on the destination end. In the case of the pilot light the wire number should not change. It should be different on the other side of the pilot light but not on the destination side. I think that having wire number 16 on the source arrow and ??? on the destination arrow, is a result of the the non-numbered wire scenario. There should be ??? for both source and destination in this case.
I think your situation is partly a workflow issue, though it would be nice if the software could be improved to accommodate this situation. You see, the regular source and destination arrows expect to pass a potential and its associated number from one place to another If the wire has no number there is no potential to pass, thus you normally get ??? as a placeholder and reminder that you haven't yet numbered your wires. Blanking out the WIRENO attribute would be enough for the schematic but the wire list might still look strange. But then again, if you wish to have no wire numbers, you probably will not generate a wire list. I normally do assign wire numbers to field wires, just so I can generate a separate from/to report for the customer to use to pull the wires they are responsible for. If you have no intention of generating a from/to list for these wires, perhaps consider using a plain AutoCAD line with a dashed line type and insert stand-alone cross-references.
I don't think Autodesk anticipated someone might use standard source and destination arrows for a wire that isn't receiving a potential number assignment. The stand-alone cross-references were created so you could direct the technician from one position on a page to another, or even to an entirely different drawing. I attach Stand-alone Cross-references to "non-wire" entitles or to give the appearance that I'm passing a cable from one place to another when using fan-in/fan-out. You see, the _MULTI_WIRE layer doesn't get a potential number either, so a regular source and destination pair will not suffice. But I can position the stand-alone source and destination symbols so they touch the _MULTI_WIRE and it appears that they are cross-referencing the cable from one place to another. You can do the same with non-wire lines.
Perhaps the stand-alone cross-reference approach will work for you. It automatically maintains the cross-reference data but doesn't expect a wire potential number.
Thanks JReese-NC for reporting and Doug for confirmation and explanation.
I have noticed this and reported to my team for investigation.
Well I have to be honest and say that I haven't seen the Stand Alone Cross References before so that was a new find to me.
However, it is still unfortuneate that even Stand Alone Cross References can't be used in my situation in a fully "smart" manner because even those mess up the terminal block numbering on the destination end. Sure there isn't supposed to be a wire number passed through it but I still recieved ??? for all destination terminal block numbers and a wire on the other side of said terminal blocks with which I still couldn't even manually set a fixed wire number because it was still seen as coming from a Source/Destination.
I just finished up doing as you mentioned which was replace any field wire being used with a Source/Destination by a generic line with the same properties and then used the Stand Alone Cross References on those lines. All terminal blocks and wires are now being numbered correctly so thank you for that tip Doug.
I still think that something needs to be reworked in the software with it being able to detect a Source/Destination network that shouldn't carry a wire number. I shouldn't have to use generic lines and start removing the smartness of the software like was done just to get it to work.
I suggest that you not use the terminal block symbol that expects a wire number assignment when you are inserting a terminal onto a non-numbered wire. The software is actually doing its job when it reports ??? because ??? draws attention to an entity that expects a wire number but cannot find one.
Again, if you are not numbering the wire, you are probably not reporting it, so you can solve this issue by using non-wire lines to show the connection.
Access a broad range of knowledge to help get the most out of your products and services.
Start with some of our most frequented solutions to get help installing your software.
The AutoCAD Electrical forum has moved into it's very own category page, and can no longer be found within the Additional Product Forums.