A/B Sequencer Instruction

Hello Everyone,

I've been trying to expand my knowledge of the SQO instruction. I've got an A/B 5/04 set-up as a test rack, and I'm using RsLogix 500 release 5.20. First, let me explain what I've been able to accomplish. I've written and debugged the logic to "step up", "step down" and reset a sequence to "step 1". By using indirect addressing for the destination, I am able to go beyond 16 steps, and again, I'm able to manipulate the steps as necessary.

Now to the point of this post. Earlier today, I discoverd that if I left the bit I'm using to trigger the SQO, in state "1", the sequencer would cycle repeatedly throughout the steps. In the A/B help section of RsLogix, it states that a false to true transition is required to step to the next step. I ASSUMED that it meant one step for each false to true transition. Well, now here's where it gets weird, I inserted an OSR after my trigger, and it worked as expected.
But, during further edits, I removed the OSR, and now the SQO only steps one time for each false to true transition of the trigger. No matter how long the trigger stays high.

Can anyone tell me any reason why the behavior of the instruction has changed? Could it have anything to do with the index (S:24) value?

Thanks to all who take the time to read this long post. I'll be glad to send the file to anyone who might want to take a look.

Sounds weird, that it didn't behave, then did. Maniulating S:24 shouldn't have anything to do with it, becasue the PLC will set S:24 when it hits the SQO, and set it to R6.POS

To help you with this, I'd have to look at the code. I don't want it in my InBox, though. Zip it up and attach it to your reply. That way, shy lurkers can see it too.

I zipped the entire .rss progam file.

I guess I might add that the SQO I'm refering to is in File 4. Also, when I remove the OSR ahead of the SQL instruction in file 5, the SQL will continually cycle thru the steps when the trigger is held high.

In file 4, what turns on B3/10, and B3/5? Are these MMI inputs?

When you say cycles through the steps, do you mean you see R6:0.POS changing or B9:1, the "destination" word changing?

How fast does it seem to be stepping?

Good questions.

I haven't spotted the problem, but here's a programming tip/trick for having more than 16 bits in a sequence.

Rather than doing the indirect address, just use two SQO blocks, each with their own File and Destination, but using the same control element, like this:

                    +--------- SQO --+  

   toggle           | File:   #N10:0 |

----| |------+------| Mask:    FFFFh |

             |      | Dest:     B9:5 |

             |      | Control:  R6:1 |

             |      | Length      16 |

             |      | Position     1 |

             |      +----------------+

             |

             |      +--------- SQO --+  

             |      | File:   #N11:0 |

             +------| Mask:    FFFFh |

                    | Dest:     B9:6 |

                    | Control:  R6:1 |

                    | Length      16 |

                    | Position     1 |

                    +----------------+

You don't have to worry about the second block causing a second step
The SQO block uses the R6.EN bit as it's check for false-to-true condition. Since the .EN bit got set in the first block, the second block won't add. But since it is scaned and enabled, it will still move the data from N11 to B9:6.

Of course, you always could use different control words, but you run the risk of the two sequencers getting out of step if you forget a RES for one and not the other.

I also like to keep the SQO blocks always enabled, and have the transition pulse a true-to-false-to-true. That way, I can write to the R6.POS and the SQO will jump to that step. For the most part, that's all they are, a combination of a counter and an indirect Move. And that's how we used to do it in the PLC-5/25's (old platform), before the invention of the SQO. ( uragod "Yep, shunny, back in the old days.....")

Can't guess what your SQO problem was but I suspect it may be similar to the problem you have with the SQL - You've use R6:2 for the SQL in file 5 and for the BSR in file 4.

Tsk Tsk!

Darn it!! that was the first thing I looked for, but I only looked for multiple usage of R6:0.

After changing the address for the control register in file 5, the SQL worked fine. So, I suspect that I duplicated the same control register for the SQO in file 4 in more than one instruction. But, I honestly don't recall myself doing that.

Allen, from your example I don't understand how using two SQO instructions in parallel would allow more than 16 steps. Could you explain just a little more? From what I see, it would move data into two seperate words simultaneously. I'd like to point out that I've got all of 11 months as a programmer working for an OEM. I've got a long way to go to be "bonafide".

The value of the R6.LEN determines the number of steps, nothing else.

Right now, the way you are thinking of "steps", you have one bit for each step, and are using the SQO to set that bit for the step. There are, of course, better ways of doing that like (OTE B9:5/[R6.POS], for example). In my example, and the way you are programming it, you would be setting the B9:5 bits N10:0, just as you are. The first 16 words of N11:0 would be zero, and then it would have the bits for B9:6.

But you really need to change how you think of the sequencer and the steps. When I use the SQO, I'll set bits that represent an output (I don't drive O:'s directly, but bits that will - if interlocks, faults, auto mode, etc are met - drive the outputs.)

So if a valve has to be open on steps 5 through 10, the bit that represents that valve will be '1' on steps 5 through 10. The pump that starts aftr and closes before the valve will have a differnt bit assigned, and have a '1' on steps 6 through 9.

You can even mis the two techniques. N10 could be the file for what transitions you need to see to step (which could be linear like you have, or some conditions may be repeated (a done timer, for example). N11 would be the outputs that that step drives.

I've done several projects like this, and it works nicely.