Duplicate destructive bit reference detected

I've spent three days trying to figure out why my assembly cell is blowing past a step in the logic.


While adding blocking bits I noticed the subject message.


Yes, a OTE from the existing code is defined in two routines.


It seems that sometimes it is on at times even though it shouldn't evaluate to true. When my engineer gets back from lunch we will fix it.


What I'd like to know is how a bit defined in two places and shouldn't come on blinked on and off while I watched.

Thanks

wes.s said:

What I'd like to know is how a bit defined in two places and shouldn't come on blinked on and off while I watched.

Click to expand...

Could be on/off (true false) for one scan, depending on your PLC this could be much faster than your PLC can communicate to the PC and if your comms are slow then your software is not updating as fast as the bit is changing state

I have seen this with the micrologix 1400 processors. It's a known issue. Had to get rid of the duplicate bits.

So it's defined in both places and it shouldn't evaluate as true in either case?

I suspect it is actually evaluating true on one OTE and not on the other, or it is being set high by something else. Either way, it's bad practice to have that arrangement.

If the OTE is in a subroutine and that subroutine is being called conditionally then the OTE is staying on because the routine is not being called when the logic for the OTE goes false.

You cannot rely on the response time of the PC to judge an outputs state, it is not near fast enough.

Example...

Execute JSR - Logic writes the OTE on.
Not Execute JSR - OTE remains on
not execute JSR - logic should write OTE off but does not because the JSR is not called
Execute JSR - logic writes the OTE off

you can see in that example how it could be a perpetual loop of the OTE pulsing on/off.

and as Rupej said, if the OTE exists on two separate rungs and they conflict you will get erratic pulsing of the output.

DarrylR said:

I have seen this with the micrologix 1400 processors. It's a known issue. Had to get rid of the duplicate bits.

Click to expand...

Side note, this will occur on every processor. Its bad practice to have destructive bits unless you have robust routine interlocking.

Usually the complier will flag it as a warning but not an error. So the PLC brains will let you hang yourself with multiple destructive outputs. Usually if you cross reference bits, search all will find this so you can redo the multiple outputs.

IF : you write a program that uses duplicate destructive data (not just bits, works the same for numbers, but the validation won't tell you that)....

AND IF : you make that program work correctly now ....

Sometime in the future you may want to modify that program, and you will NOT find a simple logical "model" that will always work, no matter what.

In my past employment, company standards used a "logic_extension" bit, that could be used, as an XIC (N/O) or XIO (N/C) bit on following rungs. I hated it - the verification would throw up 100's of "warnings" that duplicate destructive bits were present in the code.

We were told to switch off the verification for DDB's, which of course meant that we would not pick up any other instances that might be an issue.

Nowadays, I would never do it, my verification includes all the checks, and I also do a search for AFI's, and shorted branches. Any other bit or value I've created to say "not finished here, come back and check", these start with the letters "Dummy", eg DummyBit, DummyDINT, DummyREAL etc., so I can use the tag database filter to show anything I haven't finished.

So, on verification, NO errors or warnings. Tag databases, NO Dummy* cross-references (easy to spot, because you can't delete them if they are being referenced in the code).

Drive separate bits, and use "OR" logic to drive the bit you want to drive, and you then have a visual on what is happening, without it getting complicated or hidden by PC to PLC communications scan times.