Step7 - philosophical question, = or S/R, which is better?

The system I'm working on at the moment uses marker-based SFCs ala Step5. About half the time a check is made at the start of the Step (i.e. as the first instruction group in the network - each Step has its own NW) to see if the Step is active, if not the rest of the code in the Step is jumped over.

In one of these Steps I want to set a Marker Bit TRUE under certain conditions and check the Bit in another SFC later on. I decided to use code of the form:

A "Condition"
= M999.0

This is easier than using the "S"et command and also means I don't have to worry about where to "R"eset the Bit (I would normally do this in the "Wait" Step, right at the start of the SFC.)

Now, unless I'm having another of my dopy days, the fact that this code is only executed during the period where the Step concerned is active (probably only a single cycle under most circumstances), shouldn't be a problem, the Bit will remain Set or Cleared until the next time the Step becomes active (with the next production unit).

Everything is working fine but for some reason, I find I have a slightly queasy feeling about this solution. I know some people don't like using "S" & "R", but I'm not one of them, in fact I often prefer them, however, this case is an exception.

I'd be interested to hear which solution others would prefer to use in this situation and why.

The logic you are using will store the condition state just as the Step is due to become inactive and move on to the next step. If this is the intention, then use the proposed solution.

Looks good. I like and prefer S/R approach. As long as you take care of all conditions of exit/restart/fault/pause it can be very solid.

I would sleep easy.

Nick

I think the S/R is a better approach because i see that it's more stable, just write down all conditions for set and for reset.

I'm not very comfortable with (A condition=Mx.x).
I think the S/R is a more professional programmig method.

I allso prefer S/R. As was said before me, you just define when a bit should be set or when it should be reset. It's better for troubleshooting as well.

At the risk of flying in the face of popular opinion, I prefer the = approach to the S/R. In this instance it won't make any difference, even if the state is only changed on a single scan, in fact, I've used the same approach on step5 myself.

My reasoning for avoiding the S/R approach stems from some 15 years ago when we were under pressure and had to sub-contract some of our machine control software. Coming back to some of this software when there was a service issue on a machine, we found one particular flag had over a dozen S/R points in the program. Clearly this isn't ideal for debugging or troubleshooting so we made the decision to avoid S/Rs and insisted our contractors did the same (along with insisting a flag or output is only driven by an = in one place in the program).

Just another view.

TGF - Do you always scan all of the program or do the = act as latches by selectively executing code ?

L D[AR2 said:

TGF - Do you always scan all of the program or do the = act as latches by selectively executing code ?

Click to expand...

It depends. If its a physical output then its always scanned (to make sure it goes off for an e-stop etc., the code should mirror the hard-wired safety circuit). If its a flag (and its a slow processor, like many of the step5 CPUs) then its only scanned when needed. There's nothing wrong with an = latch being set or reset with a single scan so long as its scanned at the correct time...

L D[AR2 said:

TGF - Do you always scan all of the program or do the = act as latches by selectively executing code ?

Click to expand...

Can I ask, what's the point of your question?

I was just curious as I have seen cases where there is a company standard to always execute all blocks and ladder, and also use = in one place for all logic.

L D[AR2 said:

I was just curious as I have seen cases where there is a company standard to always execute all blocks and ladder, and also use = in one place for all logic.

Click to expand...

Its certainly simpler to get your head round logic which is continuously scanned. For most applications using modern PLCs this is just fine.

For older hardware it was often the case that the only way to get a usable scan time was to only scan the logic as needed:

e.g.
* housekeeping - always scanned
* outputs - always scanned
* manual operations - only when selected
* auto sequencing - only when selected
* high speed positioning - run to the exclusion of everything else for 500msec

etc., etc...

It's better to execute only the logic needed but attention is required:

If i was executing a subroutine (e.g. manual operation) then i switched to automatic operation then just stopping the executing of the manual operation subroutine and starting the automatic operation subroutine is not a good practice. why? because the manual subroutine will be controlling outputs which their state will be the last state when i stopped scanning it. Thus i need to reset those outputs.
i hope i'm clear

that's a point where S/R is of benefit beacause one Reset condition will be changing operating mode.

AMAZINGAHMED said:

It's better to execute only the logic needed but attention is required:

If i was executing a subroutine (e.g. manual operation) then i switched to automatic operation then just stopping the executing of the manual operation subroutine and starting the automatic operation subroutine is not a good practice. why? because the manual subroutine will be controlling outputs which their state will be the last state when i stopped scanning it. Thus i need to reset those outputs.
i hope i'm clear

that's a point where S/R is of benefit beacause one Reset condition will be changing operating mode.

Click to expand...

Yes, perfectly clear.

I always used delay on timers to select auto and manual (in the housekeeping block) and executed manual on NOT auto selected and auto on NOT manual selected. That way you get an overlap when changing modes where everything is called. If your manual and auto code looks for the selector switch then everything resets itself nicely on a mode change. Worked for me, anyway...

I agree with that it is much easier to follow code that is constantly scanned and use "=" logic.
However, if the sequence is a bit complicated, then some kind of state machine is probably a better choise. And typically state machines are made with "S+R" logic.

I use S/R but only infrequently, my preference is =. The other technique some people love is the one shot, again I do use them but infrequently.

I have had problems where timing issues have occured because of the programmers infatuation with one shots, whether because of modifications or because of not enough thought when originally programming. As seen by the conveyor example on another thread, a one shot in the wrong place can cause unexpected actions also a one shot signal in amongst other logic can be lost of the other logic was not ready, once its gone its gone.

Funnily enough when I do use S/R, I have programmed multiple instances of the same address being switched, this is because, depending on the requirements of the code, I do jump around programs at times.