Discussion: Counter used in RSLogix 500 like SFC... Thoughts for use in Studio 5000?

Tonight I'm contemplating using a technique I saw the other day while troubleshooting an installation of a legacy machine for a customer of mine. Who knows, this might be common... I don't program enough to know. Thought I'd bring it up here to get a feel for what you guys think.

I saw this on a rung at the beginning of a ladder file. The machine stacks boxes. The operator enters in a set point of how high the make the stack on the pallet before the machine releases it onto the conveyor. I hooked up my laptop to the SLC 5/02 and this (pic attached) is one of the first things I saw. At first I thought it was counting the boxes and comparing it to the setpoint, but you quickly realize that doesn't make sense. The setpoint is set and compared by a Red Lion device that keeps track of the count and closes a contact when the setpoint has been met. The PLC never counts anything. As I looked at the rest of the Ladder, I saw the C5 counter being used quite a bit, at the beginning of the several different rungs. I was talking to the guy installing the machine and said, "It seems like the C5 counter keeps track of what stage the machine is in." And then it hit me... This is like the SFC programming I've been reading about in Studio 5000. But the more I looked at it's use in the Ladder, the more I like it. It's so simple! An input can mean many different things, depending on what stage the machine is in.

I was thinking about using this with an HMI momentary PB input, where you have one master control button that changes it's function depending on the stage the machine is in, or in other words, the accumulated count of the counter. My customer wanted the HMI of his machine to be simple enough that the machine could be operated by a substitute if the usual operator can't work. So I'm getting ready to re-do the ladder to utilize this counter technique.

I'm not really asking a direct question, I'm just wondering if you've used this kind of technique (a counter) to put a machine in different "stages" in Logix or Studio 5000, and if you have anything else to add about doing it this way. I've done more in 500 than in 5000, so sometimes I question old techniques in new software. My brain hasn't fully grasped using SFC yet, so I'm wondering what will be said about the comparison between the two techniques.

Yes, this is one of multiple ways for implement a 'state like' execution of code. One advantage of using a counter's accumulator to hold the current state is assured holding of the value through a battery backed power off. Some other ways can be just using a standard integer or even a set of interlocked bits.

To me, this seems like a very clever solution to a simple problem. I hate clever. I love simple.
The only thing I would caution you on is make sure to leave good rung comments behind explaining how things are supposed to work. Otherwise, my other brother Bubba will be calling you because it's broke and he/she has no clue how to troubleshoot it.



Bubba.

Bernie: Thanks for pointing out the power-off feature... that's actually not a good thing for this program, but I could see where it could be for another situation. I'll have to search out the command to reset the counter on power-up.

Bubba: Yeah, I'll be documenting everything. I know that if I didn't have sequential function programming in my brain, it might have taken me a while to figure out the reason for using a counter like they did.

I'm starting to play with the concept. I'll be converting a project I did to this new 'counter-stage' method. Right away, what I like is that it gives me an organized, methodical process to think about how the machine operates. And it's "additive", meaning I don't have to hold the whole process in my head at once. I can add conditions to each stage without thinking about the whole ladder.

I also see how I can utilize the counter for trouble-shooting, just like you can with SFC. I could make it easy to tell on the HMI what stage the machine is in at any point.

The picture is my framework that I'll be adding conditions to advance the stages. I'm kind of excited about what I'm going to learn from this experience.

Look at that.... I spelled Increment wrong. I've wondered if I can edit the name, or if I have to delete and re-create the object. Anyone know off hand?

I'm pretty s u're you can change it without deleting and re-creating at least while offline.

Stage/step programming in ladder is quite common for loop systems where the machine repeats the same process over and over again. Sfc was developed for this exact process but to be more visual. I find that if you learned step programming in ladder first you tend to lean that way. If you learn to do it with sfc effectively you won’t go back to ladder. Edits and or additions to the process are much easier to do and now that it’s an iec language it’s easier to implement on multiple hardware platforms.

Sfc is also easy to teach to techs for troubleshooting, other advantages are being able to pause resume easily. Restart from multiple positions etc. the hardest thing for most that are new to it is the program control and understanding retentive and non retentive bit control.

If your contemplating sfc I highly recommend it.

I *am* contemplating it. I'm working towards it, but I don't have anything to use it on yet.

Even though I love the programming jobs I get, I'm first and foremost a tech. So making the machine easily serviceable is something I think about a lot.

I always try to do this in any new program I am making. What I do is create a UDT called stateStep or something. In that UDT I have a few flags that might be 'started', 'inCycle', 'done', 'overrun', 'fault' or what ever. Then in one ladder file I am only looking at each state once and making sure to get into state 2, state 1 needs to be done, but state 3 shouldn't be started yet and then in series with what ever other triggers get to the next state.

Always works out to be cleaner in my opinion as long as you don't have a crazy amount of states and also that the state transitions are obvious. I can send you an example if you need

mp91 said:

Always works out to be cleaner in my opinion as long as you don't have a crazy amount of states and also that the state transitions are obvious. I can send you an example if you need

Click to expand...

Absolutely! I keep trying to figure out a way to organize better. I think about it all the time. If you've got some techniques, I'd love to see them. How do you want to send them... PM?