wd_jumpers and wire numbers: not propagating

[Anonymous]

Windows7, ACE2014.

Problem statement:

I have a PLC card with WD_JUMPERS dictating the terminals that will share a common wire number.

I have a signal arrow on the fist wd_jumpered terminal that is driving the wire number for all those terminals.

When I do a signal arrow refresh across my project, wires that are on wd_jumpered terminals will randomly be assigned a wire number from the current dwg ladder reference.

Overview:close up of the first offending point and point above it:

I do a tracewire on the incoming signal arrow wire that is driving all the wd_jumpered terminals (they are all connected):

If I do a drawing audit it does not call those wires floaters and it also does not highlight them as being connected to the incoming signal arrow wire, even though tracewire shows them connected.

Now I delete wire number (aedeletewireno) and it blanks out my signal arrow and removes all wire copies (if they were there).

If I retag/refresh the signal arrow, it will be fixed. Until I run a signal arrow refresh on the project and then who knows what will happen.

This happens way too often. It is killing my productivity.

I have attached the drawing.

[dougmcalexander]

I downloaded your drawing and added it to a test project I created to analyze your drawing.  Everything seems in order with your PLC symbol.  I checked the WD_JUMPERS attribute assignments and the PLC name and it all looks in order.  

In the video at the link below you will see my test procedure.  I had to add a wire source arrow since you didn't include the drawing with the source wire.  I changed the wire number at the source and after a Signal Reference Update, all wire number copies updated as expected.  The video cut me off at the end as I was explaining how to delete the project scratch database, in case the AEREBUILDDB utility (Full Rebuild Option) doesn't help.  You simply close AutoCAD Electrical and delete the project scratch database from your User folder.  Your User folder should be located at C:\Users\Your User Name\AppData\Roaming\Autodesk\AutoCAD Electrical 2017\R21.0\enu\Support\User.  Look for a file named for the project but ending in .MDB, as in Microsoft Database. 

As you will see in the video, all seemed to work as expected for me, so I suggest a Full Rebuild or deletion of the project scratch database.  The software will create a fresh database from the drawing data and the project definition file data (ProjectName.WDP) when you restart AutoCAD Electrical and activate the project in question, so don't worry.  

I tested with AutoCAD Electrical 2017. Be sure you have all updates installed.

https://www.screencast.com/t/sgN3Z2JX

[Anonymous]

Doug,

I too, can fix it.

the problem is if I run the project wide retag/renumber tool (I have to add drawings and redo the ladders), it starts renumbering wires that already have the wire number driven by something else (a signal arrow, a wd_jumper, or a "jumper" wire).

I already have a tool to delete the scratch databases. I am unclear how it would help in this situation.

I am pretty religious about rebuilding the database before I retag/renumber. So it should be up to date and correct when I begin the retag/renumber.

It's something about how ACE tries to figure out the wire networks, it is having a hard time doing that in these cases.

[dougmcalexander]

Okay, I was able to reproduce the issue with 2017 as well.  I suspect that your workflow isn't something that the developers anticipated.  In fact, I've been designing with this software since 1997 and I've never run into this issue.  Admittedly, I haven't often been faced with the need to renumber my rungs while designing to U.S. standards in ladder format.  I use a simple ladder format where the rung numbers are incremented by 100 with each new drawing and the beginning number is the sheet number.  

I too have custom Flex I/O PLC symbols that make use of the WD_JUMPERS attribute, but I use these symbols for IEC format.  That's not to say that this isn't an issue.  It is indeed an issue.  It's just that the circumstances that lead to this problem are probably not so common that many customers have experienced this and gone so far as to report it.  The circumstances leading to this issue involve a custom made PLC with internal jumpers. They also require that the wires connected to the PLC via source and destination are also connected to wire connections that are internally jumpered, and add to that the fact that the wires connected to these internally jumpered wire connections have a wire number copy inserted onto them.  

I'm glad that you took the time to report this.  It is difficult for the developers to anticipate each and every workflow that we might use, so bugs are inevitable.  That's why customer feedback during the beta phase is so important.

You are absolutely correct that it appears to be related to the order in which the update/retag utility processes affected wire networks.  I shot a video illustrating the issue and I have sent it to the developers.

[Anonymous]

Excellent Doug!

Did I read this wrong or are we suspecting the ladder number format as a contributing factor in this error?

Just curious.

[PatMurnen_Adsk]

Hi Darrell,

This is a little out of my area of expertise but it almost sounds to me like the Signal Update might be having a problem with the internal jumpers defined on the PLC module. To test this theory, what if you removed those internal jumper assignments and drew wires to actually connect the terminals within the PLC module and put them on the TERM_JUMPER layer (jyour jumper wire layer defined with the word JUMPER in it). I think this would essentially be the same thing. Then see if the Signal Update correctly interprets the jumpering. 

I am just trying to think of an easy to to troubleshoot this since it is somewhat complicated. 

Regards,

Pat Murnen

[Anonymous]

Pat,

Sorry for the long wait on this. Very busy this year, already.

Set wd_jumpers to be blank on both PLC cards.

Connected all COM together with "jumper" wire, connected all "+24v" with "jumper" wire.

Redid ladder.

It put a local ladder wire number on a jumped point.

See image below:

 close up:

Here showing tracewire...

so some aspect of the software knows it's supposed to be connected.

Drawing audit will NOT fix this.

You have to delete that bad wire number, which then sets the signal arrow and all other wire numbers and copies on that network on this page to be blank. One then has to "retag" the signal arrow to get the wire number back. and then put all the copies back that you wanted there.

[PatMurnen_Adsk]

Darrell,

Would it be possible for you to send me the drawing? If you don't want to post it here, send it to my email [email protected]. Also, what version of AutoCAD Electrical are you using? 

Regards,
Pat

[Anonymous]

Pat,

we just migrated to 2016.

wd_jumpered PLC drawings are being tagged by local ladder (randomly) still.

If I use the "jumper" wire to connect the terminals on the PLC it doesn't appear to be renumbering them to the local ladder. So far.

Of course this is messy.

I'll attach the drawing that is jumpered.

You can remove the jumpers and put the wd_jumpers back on for testing. I have put the wd_jumper text on some text objects.

[PatMurnen_Adsk]

Darrell, so far I wasn't able to reproduce any problem with either drawing you have attached to this thread. I ran signal updates and wire numbering and got the wire numbers I expected each time. Although I am not 100% sure I am reproducing it exactly since I don't have the project which would include the drawing with the source arrow that feeds into the destination arrow which feeds all the jumpered wires.

Also, the drawing you uploaded 147158_08_jumpered, if you were doing that with the internal jumpers, how would you jumper across the two pieces of the module since the module is broken? I don't see a way to get the internal jumpers to mimic what you reproduced with actual jumper wires.

So the main problem is that the wire number is not carried to all the wires that are connected by the internal jumpers, right? Is there a way to simplify the example and cut down on the number of variables? Right now we have a number of variables making it more difficult to diagnose. Can you try these cases:

• If it happens with modules that are not broken (like drawing 132999_22) then let's leave that out of the test case.
• Can it be reproduced without source\destination on the first wire, i.e. the first wire number is assigned to that wire coming into the first terminal on the PLC from the ladder. Does the wire carry across to all internally jumpered wires? If the problem can be reproduced without signal arrows then let's make a test without them.

Once you have the simplest possible test case that still reproduces the problem can you detail the exact steps to reproduce it. By exact steps I mean something like "run command AEWIRENO picked from ribbon Schematic tab > Insert Wire\Wire Numbers > Wire Numbers" or "run signal update AEUPDATESIGREF picked from ribbon Schematic tab > Edit Wire\Wire Numbers > expand > Update Signal References". Anyway, maybe not that much detail but enough so the testing group can be sure they are performing the exact same steps.

Since I can't reproduce it, this will really help. I am going to be out of the office next week but will check in on this thread and forward anything you post to the testing group.

Regards,

Pat

[Anonymous]

Pat,

I am so huge busy right now that I can't possibly get to all this testing and do my job.

So what I think might help is for me to put the project here.

It is currently exhibiting the problem. See dwg 147158_17 (others as well).

All the drawings were fine (I fixed them all several times which is one of the reasons I just don't have any extra time to do this testing... I have to keep redoing stuff on my projects that are killing my productivity).

All I did was add some drawings in front of the I/O drawings (added some estop drawings).

I then used the project-wide update or retag from the ribbon with these options selected:Drawings selected were by section/sub-section: "schematics" "24VDC", starting number was 22BD001.

I hope this is agreeable, otherwise it might be some time before I can do the testing asked.

[PatMurnen_Adsk]

Darrell. I understand. Thanks for uploading the project. I will let you know when I hear something. 

Regards,

Pat

[PatMurnen_Adsk]

Darrell, in looking at drawing 147158_17.dwg, I notice that some of the address terminals have wire connection points on both sides as if you would connect a component from the left and\or right, i.e. X4TERM04 and X1TERM04. I think the jumper ends up jumpering to one of these but then the wire from the component is connected to the other. Seems like it might "break" the wire this way. Is there some reason there are wire connection attributes on both sides?  

Can you zip up and send your PLC database and all the HP symbols in your library folder and post? Or I can set up a Box folder for you to upload them to.

Regards,

Pat

[Anonymous]

Pat,

>< Is there some reason there are wire connection attributes on both sides?><

Yes, many reasons....

1. Since ACADE is supposed to treat all terminals with the same "TERM##" as essentially wd_jumpered we took advantage of this to allow the card to work like it does in real life, you hook power up to the +24V terminal and the COM terminal and the rest of the terminals are internally jumpered.
2. It also allows us to more easily connect the two halves of the broken module without double landing on the same terminal side and creating an angled wire for those few connections that get made later. We normally draw the PLC module and connect the broken halves before we land the devices on it, so when the new wire is put on the ones with a land on already it tries to angle that wire and we don't want that.
3. We were having issues with folks "fixing" wire numbers on broken cards, when they changed the upstream wire number, they would forget to change all the fixed wire numbers downstream on PLC cards, so we just made it easy to NOT fail that way. This also increases productivity as one doesn't have to remember all those fixed wires... just change the one that is driving them all.

Anywho... attached should be the files you requested (I think I got them all...).

[PatMurnen_Adsk]

Thanks for uploading the files. I will make sure it is logged and I will need to pass this along to someone who can trace the code to track down the real culprit. So far I haven't been able to reproduce it with a simple drawing\project.

Sorry for the inconvenience and thanks for your patience.

Regards,

Pat

[Anonymous]

Pat,

Ok, very troubled to hear you cannot duplicate the error. I can easily duplicate by just running a project wide retag of the ladders (that causes the ladders to all change, so change starting ladder from 22BD001 to 22BD100 and then run it).

[PatMurnen_Adsk]

Darrell, sorry, I should have been more clear - I can duplicate it with your project and drawing set. I can't duplicate it with a simple project\drawing set which is what I would need to do since I can't trace the code to see why it happens this way on your drawing set. There are a number of variables and maybe not so common cases happening, i.e. the internal jumpers, the wire connection attributes on both sides, the wire driving the number has a destination arrow, etc. So I need to pass it to someone who can trace the code using your project set.

Sorry for any confusion.

Pat

[Anonymous]

oh, then that's awesome!

I thought it was "just us"...

If I only had a small project...

[Anonymous]

I have similar problem with WD_JUMPERS in AcadE 2016.

[rhesusminus]

Sooo.. Create a new thread with your similar (but not identical) issue, and we'll try to help you?