Question about weird COP instruction behavior

Hi All,

I'm new at this, and I'm not able to understand what I believe to be strange behavior while using the COP instruction in my program.

I'm conditionally copying a block of data from the source N9 to destination N7. I then use some of the N7 words as parameters in a couple of SCP instructions (I mention this just in case is relevant).

The condition to copy the data is when a specific output is ON, so I'm additionally using an OSR instruction so it only executes once when the output cycles.

So it copies the block of data correctly, but when I go and change data from the source in N9, it changes in N7 without the COP (or rung) being executed! I added a CTU instruction in the COP rung to make sure it doesn't execute more than once and it doesn't. Please see screenshot of the two rungs below:



Does anyone have any idea what's going on here?

Happy new year (almost)!!!

Thanks in advance!
sb

Can you post the whole program or look to see if there is another copy instruction where N9:?? is writing to N7:??.

I added a CTU instruction in the COP rung to make sure it doesn't execute more than once and it doesn't.

Click to expand...

well, maybe it does ...

first step ...

change the CTU instruction to an ADD instruction ... for example:

Source A = enter an otherwise unused integer
Source B = enter the number 1
Destination = enter the same integer that was used for Source A ...

the reason:

the CTU must see a TRANSITION/CHANGE from false to true in order to count up ... so - the "test" that you're using is inconclusive ... specifically, if the rung is somehow staying true, the counter would NOT continually count - but the ADD instruction WOULD increment upwards each time the rung was executed as true ... so – the ADD would be a much more conclusive test of whether the rung is staying true or not ...

second step ...

is anything else in the program making use of your OSR bit B3:0/4 ??? ...

if these two suggestions don't help you nail down your problem, it would be a good idea to post the entire program ... you'll have to zip it first – forum rule ...

also ... notice that your SCP instructions are manipulating/controlling/writing to the addresses N7:69 and N7:119 ... and those addresses are included in the range of locations that your COP instruction has just written into ... that's not causing your problem is it? ...

ARRRRGHHHHH!

Hi Ron, you are right! It was the bit flag! I thought I could use it on 2 OSRs in 2 different rungs that used the same logic, but now I know they have to be unique per OSR. :nodi:

Thanks a lot Ron and Mickey!

Cheers!

Ron Beaufort said:

also ... notice that your SCP instructions are manipulating/controlling/writing to the addresses N7:69 and N7:119 ... and those addresses are included in the range of locations that your COP instruction has just written into ... that's not causing your problem is it? ...

Click to expand...

Hi again Ron. That's exactly what I want. I want to copy my "settings" stored in my N9 file to the general space being used by several SCP and PID instrucions and then move the results back to N9 when done.

Thanks!!!
sb

So it copies the block of data correctly, but when I go and change data from the source in N9, it changes in N7 without the COP (or rung) being executed!

Click to expand...

Yes, the way you designed your logic, the values in N7 could change on every PLC scan (depending on values of Inputs I:3.0 and I:3.1) whereas the values in N9 only change one time when O:1.0/1 goes from false-to-true. Your problem had very little to do with the behavior of the COP instruction.

Lancie1 said:

Your problem had very little to do with the behavior of the COP instruction.

Click to expand...

Yes, I realize that now. It was a novice mistake. Thanks for all the help!

I have done that before. Apparently-dependent events are the next thing to old-fashioned witchcraft - when they are actually independent.

Did you get it working?

Lancie1 said:

I have done that before. Apparently-dependent events are the next thing to old-fashioned witchcraft - when they are actually independent.

Did you get it working?

Click to expand...

Well, I'll tell you something, it felt like witchcraft, he he! Yes it's working correctly now.

Thanks again!

I take my biggest bit file in the data table and pick the very last whole word and symbol name it "1Shot" I then use the data table Usage View and drag and drop from there as I come across a need for an inline oneshot, already commented at the word level, you can name the bits as you use them if you want.

This also prevent that B file from getting shrunk when you switch controllers and resize data tables.

Yep, each oneshot needs its own place store whether it shot yet or not. The book says unexpected results may happen if you reuse them bit boxes. Actually the results are quite predictable but always unwanted...

The inline oneshot and the DDT instruction are among the few "input" instructions in RSLogix5/500 that are destructive.

To SergioB....

In my (nearly 30 years) experience with Allen-Bradley PLCs, "odd" behaviour from instructions is as rare as excrement from rocking horses... meaning there's almost always something else going on to give what appears to be odd behaviour.

The thing you need to ask yourself, when something like this comes around again, is "I have used a stock instruction, in a processor (and revision), thats been around for a while, how come no-one else is reporting any odd behaviour?".

No offence intended, but it is sometimes very easy to perceive a problem that doesn't exist. If you had allowed yourself the time to take a step back, and perform some basic troubleshooting exercises, I'm certain you would have resolved the issues yourself, and you'd have been rightly proud of doing so.

In your specific case, I would have looked at the conditions on the rung (you only have 2), and asked myself....

1. Is the output bit that drives the rung being turned on and off more than once to cause a repeat copy.....

2. Is the one-shot bit being reset somewhere else in the code....

For either of those scenarios, a quick foray with the cross-referencing tool is the best way to find the answer. I would have immediately suspected multiple uses of the bit used for the one-shot instruction... it's a common mistake.

The one-shot instruction needs to remember the logic state of the rung on each scan, so that on subsequent scans it can determine if the rung has changed state or not, and set the "storage bit" accordingly. The combination of "rung logic continuity", and the one-shot instructions memory bit, conditions what action the one-shot instruction does to both the "rung logic continuity", and the state of the storage bit.

Your "novice mistake" has taught you a valuable lesson that will be hard to forget, and that can't be a bad thing....

And have a happy new year....

OkiePC said:

..... Actually the results are quite predictable but always unwanted...

Click to expand...

Top trunps, good comment..

Hi

I trick I use in both slc and cld is a pick a word or words of bits and label the words as unused one shots and then when I pick a bit from that word it already has the comment in and then I change that comment to one shot. This helps me to keep track of the used ones.

Not saying its the right thing to do but it works to me.

Donnchadh

Hi

I trick I use in both slc and clx is I pick a word or words of bits and label the words as unused one shots and then when I pick a bit from that word it already has the comment in and then I change that comment to one shot. This helps me to keep track of the used ones.

Not saying its the right thing to do but it works to me.

Donnchadh

Sorry don't know how I posted it twice sure I can blame apple