Definitely good points, and I do think that using integers is a good approach - just not my favourite. Here's my take on your points, just in case you're interested. Not trying to "re-educate", just trying to show the other side of the coin
it should be noted that most of my sequences tend to be smallish - never more than 32 steps, so I've never had to use anything more than one DINT for a sequence. If you have more steps than that, integers do start to look more attractive, even to me
daba said:
1. The sequence can only have one step or stage active at any one time, because the "step-number" tag or register can only hold one value. Manipulating a bunch of bits will inevitably be more complex than using a value from an integer tag or register. How do you ensure that only one bit is on ?
I do this by using a CLR instruction right before the OTL instruction. Sure, it relies on the programmer to do that every time, but once the code is commissioned, no problem. But then as you say, it's physically impossible to have two values in an integer, so in all fairness your method does slightly have the upper hand here.
daba said:
3. The sequence logic can be more easily described in the functional specification, and vice-versa, the functional specification can more easily describe the logic.
I disagree with this one. "Step 5" can just as easily mean "Bit 5" as "Value 5". I also like the fact that you can individually comment each bit - so when I just to Step 6, there's a comment attached to that OTL describing what Step 6 does. You can't do that when MOV'ing a value into an integer.
daba said:
4. The sequence "control logic" is identical for all sequences, can be written as a subroutine and called for multiple sequences, or in the A-B world the sequence control logic can be (which I approve of) an AOI.
Couldn't you do this equally either way?
daba said:
5. A numerical sequence allows easy control of the sequence during commissioning and troubleshooting. In many applications I have worked on, I have had to put the sequence into a Hold condition, make some changes to the logic, revert the sequence to a particular step number, just by changing the value in the sequence "step" register, and restart it. The sequence restarts at the new step just as if it were running as normal.
This can also be done using bits, just by toggling on the required bit. Or if you must toggle one bit off and another bit on at the same instant, you can just move the respective value into the DINT as a whole - e.g. if you need step 2, set the DINT to 2^2=4. Sure, it's not quite a s simple as doing it using integer steps, so you again win out slightly here - but it's still doable.
daba said:
6. All the maintenance people I have worked with have loved it, on every rung of the sequence they can see what step number or stage the sequence is at, and can relate that directly to the functional spec.
Ditto
daba said:
7. A numerical sequence can have up to 2,147,483,647 steps or stages (using a single 32-bit signed integer), enough for most people. How do you decide how many BOOL bits to create ? (I'm assuming you'll be using bit arrays to be efficient). Inevitably you'll create far more than you'll ever need (or think you will), but that just wastes memory if you don't need the "extras". What happens if you need to extend the number of bits during commissioning when you can't shut the process down for a download ?
True - this one is definitely a winner. As I mentioned, most of my sequences are quite small - if you've got less than 20 or 25 steps you'll never have a problem, but if you have more than that - yes.
daba said:
8. I may need to do a bit of extra sequencing, say 20 or so steps, in the middle of the sequence. This isn't a problem with a numerical sequencer, I can simply jump to step (say) 800, do my new steps, then jump back. The sequence control logic or AOI handles everything I throw at it, so that doesn't need to be revisited.
You can just as equally do this with bits - just jump from bit 3 up to bit 21 and then back down. Again, longer sequences are a different ballgame, but for shorter sequences, no problem.
daba said:
9. A numerically driven sequence will survive "as is" if the power goes off, because the values in numerical tags or registers are usually "retentive", standard "bits" are not. In the A-B world we do not have separate "retentive" and non-retentive" memory - everything is retentive, but a pre-scan will reset bits that are not programmed as retentive (by using OTL and OTU).
If you're using bits in a DINT, they're just as retentive as the DINT you're using for your step integer. That being said, in most sequences I find that after a power failure, the most desired result is to abort the current sequence and return to the home position, so it seems a moot point. That again depends on what kind of sequence you're driving though.
daba said:
10. The current "step" or "stage" can easily be displayed on the HMI or SCADA if desired, not so easy if using bits to regulate the sequence.
Quite easy! In AB land you can select the LSB for your multistate indicator instead of the value - for any other visualisation solution that doesn't have that option, there's a simple calculation to convert a bit position to an integer - it's been a while since I've done it so I don't remember it exactly, but it's basically the reverse of 2^[Step Value]. I think Log 2 or something...
daba said:
11. Outputs can easily be driven using LIMit instructions, eg. ...
Functional Spec...
Step 15 : "Open Coolant Valve V107"
Step 39 : "Close Coolant Valve V107"
Code...
LIM 15, Step_Number, 38, OTE Seq1_V107_Slave
How do you achieve that using bits ?
How do you keep the valve open for steps 16 to 38 ?
True - that one IS easier with integer step values. You CAN still use LIM's and just put them in as binary: LIM 2#0000_0000_0001_0000, StepBitDint, 2#0000_0100_0000_0000 will keep the valve open for steps 4 through 10, for example. Or you can use my Log 2 trick above to give yourself a integer running alongside in paralell to use for things like this. But yes, a little more complex.
