Parallel COPs with an MOV to boot!

The picture included here contains a rung of RSL5 logic that I think is causing some problems on one of our machines. Before this rung executes, N10:2 might be equal to 51, 52, or 53 and N10:3 will be one of the above values besides the one in N10:2. (So N10:2 could be 51 and N10:3 might be 53 - basically they're not equal.)

The basic theory of operation is that (let's say N10:3 = 53 and N10:2 = 51) the values in N32 would get moved into N53. The values in N51 would then get moved into N32. Finally the value in N10:2 would get moved into N10:3.

The file lengths are longer than 350, so that's not a problem. According to AB, these three instructions will execute simultaneously. The problem we're encountering is that some of the values in N32 which are supposed to be positive integers somehow get overwritten with zeros. I'm thinking this rung is the problem. Anyone care to agree or disagree with that?

Must be different on a PLC/5 than a SLC/500 (My only experience). On the SLC, the maximum length you can specify is 128 words.

But aside from that, if the 350 length is ok for the PLC/5 then your logic for this rung looks ok.

Wild guessing

This looks like some sort of "Recipe Edit" rung.

You've got a bunch of recipes (lets say 9) stored in N51 through N59.

The "Active Recipe" - the one that's displayed on the HMI - is in N32.

When a new recipe is selected (#3), N10:2 becomes 50+3 = 53 (but you had been editting recipe #1, so that N10:3 =51).

So this rung would
1) store the edits in N51 (COP #N32:0 #N[N10:3]:0 350),
2) pull the new selected recipe from N53 (COP #N[N10:2]:0 #N32:0 350), and then
3) set it so that the next time the recipe is stored, it will store it to N53 (MOV N10:2 N10:3).
It doesn't happen "simultaneously" The first COP will finish before the next one executes.

If that's what you've got, the rung looks fine. The reason for the zeros instead of something else is that the values were zero the last time you were looking at recipe #3.

You should have some method to change the current recipe setpoints. Based on this rung, those changes will stay until the next time the recipe is used and edited.

You don't say what sets B3/9, but I'd guess NEQ N10:2 N10:3, with the HMI writing (1 through 9) to N10:1, and N10:2 = 50 + N10:1. The only place that N10:3 should appear is on this rung. If something alters its value elsewhere - THAT's where your problem is (your recipes aren't being stored properly).

If you know what the values are supposed to be, set N10:2 and N10:3 to some value other than the N5x file you are interested in, and change them online. If they still don't hold, then you've got something else writing to that file.

Since a search doesn't show up indirect addressing, do a cross-reference, and look at each N[N...]: rung.

So how close am I?

---

Norm: The PLC-5 doesn't have the 128 length limitation on a COPy that the SLC does.

AB says they hapen at the same time?? I did not know that. If it's true, then your reading to and writing from the same n32 file at the same time. it sems that your n10;2 and n10;3 file data might get mixed up and/or bump heads somehow.

You might try to figure out how to sense when the first copy is finished and not start the second until it is.

To sense, maybe use a different instruction that has a position pointer and a done bit. Would a FLL work? Maybe a FAL with a times one function. Or maybe compare values from the copied from and copied to files to confirm completion of the copy. Maybe just use a timer and give it plenty of time to copy 350 words, then start the other copy. That would be an easy way to test the theory, anyhow--see if you still get zeroes.

Good luck--let us know what happens.

Turns out we had some other things overwriting data in the N5x files, so that was our problem. We've AFI'd the rungs that do this, since they're not needed anyway, and we'll see if it ever happens again.

Thanks for your input!

BTW, Allen, I'd say you were around 50-60% right.

John,
If only a single cpu is involved, nothing really happens at the same time with PLCs or computers for that matter. With the AB instruction scanning, each instruction is executed in it's entirety before the processor is directed to move on to the next one. In the example given the first COP will complete prior to the next one starting. The MOV will then be interpreted next.

John,
If only a single cpu is involved, nothing really happens at the same time with PLCs or computers for that matter. With the AB instruction scanning, each instruction is executed in it's entirety before the processor is directed to move on to the next one. In the example given the first COP will complete prior to the next one starting. The MOV will then be interpreted next.