Duplicate Destructive Bits Detected - Question

Hello, I have a project to upgrade a compactlogix CPU. The CPU that is currently in use is v15, and the new CPU is going to be v33. I have uploaded the programs from the v15 CPU, and imported into the latest version of Studio 5000. However, upon importing the project into v33, I get the warning of “Duplicate Destructive Bits Referenced”. This warning does not appear in v15 of the software. I’m assuming that the warning message was enabled in a later version of the software and that if the program has been working fine for many years in the v15 CPU, it will continue working fine in the new CPU. Am I correct in thinking this?

Also, can someone clarify something for me? I understand the meaning of the warning, but am confused on all of the elements that would cause it. Is it just the multiple uses of the OTE instruction with the same tag name or will using OTL and OTU similarly cause the same warning?

Please disregard any spelling/grammatical issues as I am on mobile. I appreciate it feedback. Thank you, much.

In general, you are correct. If it was working before, it should work now. Going from v15 to v33 is a very large jump, and there are certainly things that might catch you out, but the arrangement of OTE's/OTU's/OTL's will almost certainly not be one of them.

You will get the warning if you address a tag with an OTE and at least one other destructive bit instruction (another OTE, an OTU or an OTL). You can have as many OTU's and OTL's as you want; you won't get the warning unless there's also an OTE somewhere.

One reason this is commonly done is to unlatch a seal-in circuit. Something like this: It works just fine. IMO, it's not good practice, but if it were me, I'd leave it in place at least for now, so that you can be confident that your firmware upgrade is working as intended without any additional confusing factors thrown in.

And yes, the feature was enabled by default sometime in the v16-19 range.

OG

I run into that from time to time (usually when I'm writing ladder logic quicker than I'm thinking)
A simple example would be you two inputs on two different rungs driving the same output bit (Trigger_A is driving output 1 on one rung and trigger B is driving output 1 on another rung. What I usually do (depending on the complexity of the logic) is have one rung with trigger A as an input and trigger B is on a branch beneath trigger A with the needed output on the end (right side). That way the destructive bit is only referenced once.