S7 - SET the RLO question

Hi

I'm looking through some software that contains a lot of 'SET's and I can't quite understand why the programmer has done them. The easiest way to explain this is to give you some snippets of code...

SET

S M 10.0

SET

R M 45.0

R M 1.0

R M 1.1

R M 30.1

S M 30.2

S M 30.3

SET

S M 30.4

I know that SET sets the RLO to a 1 but I just can't see what effect those SET's are having in the examples I've given. Either the SET's are superfluous to the program or I'm not understanding something... so... over to you. Any ideas?

Many thanks

JT ;-)

You can look at a SET (or CLR) as "unconditional" logic. They are used to create boolean results without corresponding logic.


I use them a lot to create one shots that combine other operations. For instance:

A I 10.0
AN M10.0
JC M001

SET
= M10.0
L MD20
+ L#1
T MD20

M001: NOP 0

Somewhere else in the program, M10.0 could be used again and reset there.

If you analyze your code you will probably see the same application.

Also, I use SET/CLR a lot to initialize values in start-up OBs. I see a lot of programmers use something like this instead,

A M10.0
AN M10.0
= #AlwaysOff
or
O M10.0
ON M10.0
= #AlwaysOn

but I think it's better to use the SET/CLR.

The S and R commands are only executed when the RLO is high/on. This can cause very misleading problems. When you read S M 0.0 you think M 0.0 is being set. but this is not always the case.

So just to be on the safe side I always put the SET command before setting/resettings bits.

Werner, S7Guy

Many thanks for the replies. I've gone back to the code and analysed it based on your posts and I think the original programmer has used both of your techniques. It was confusing but since reading your posts I can see that it makes sense.

Thanks for clearing that up for me.

Cheers

JT ;-)

JT-

Your code snippets don't give us enough information to know if these sets have any immediate effect.

The S7 operating system takes specific actions at the beginning of a network to make sure that the RLO 'acts correctly' immediately. This is done using a separate internal flag whose name escapes me right now. However, as soon as the first operation occurs that influences the RLO the RLO becomes the singular controller of any function dependent on the RLO.

So in you snippets the programmer wanted to make sure the bit was set (S) or reset (R). The set (S) and reset (R) boolean operations are contingent on the RLO (the set will only occur if the RLO is equal to 1). If there are any logical operations in the network above the set or reset operators, the only way to guarantee that the RLO is equal to 1 is to use the RLO set function (SET).

SET is something specific to STL. The Step7 ladder editor won't let you enter an unconditional output so the RLO will always reflect what you want the output to do. In STL you can enter multiple logical constructs in a single network. SET and CLR allow you to separate those logical constructs.

Keith

kamenges said:

JT-
The S7 operating system takes specific actions at the beginning of a network to make sure that the RLO 'acts correctly' immediately. This is done using a separate internal flag whose name escapes me right now.

Click to expand...

Keith I think you are probably thinking of the /FC bit of the Status Word (First Check) maybe??

Thanks for the post and you are right that it appears the programmer is using the SET command to 'guarantee' the RLO state prior to SET'ting or RESET'ing the various markers etc..

Cheers

JT ;-)

Johnny, one thing to remember in regard to Set / Clr, is the difference between the 300 and 400 Series CPUs regarding Jumps. Unlike the 400 Series, in the 300 Series, a conditional Jump (JC, JCN etc.) carries the RLO result with it, i.e. it does not set the /FC Bit. This can lead to unexpected results if after the Jump you immediately perform new logic operations. For example the following would give problems:

A M10.0
AN M10.1
JC LBL
.
.
.
LBL: nop 0

O M10. 2
O M10.3
= M10.4

In the above, If the Jump were performed, M10.4 would be set to 1 even if M10.2 and M10.3 were both FALSE.

To some extent, you can get round the problem by using JCN as the test for undesired conditions, but this just changes the problem to hit the situation if the following logic begins with an AND.

By using SET and CLR before a bit of logic, you have a defined condition, regardless of whether this bit of code is being jumped to or is being reached after simply running through preceding code.

Cheers

Roy

Roy,

Thanks for the information. I can see why this would cause a head scratching session!

Cheers

JT ;-)

need to use CLR

So I need to put CLR above this code,right??

CLR
O M10. 2
O M10.3
= M10.4

manmeetvirdi said:

So I need to put CLR above this code,right??

CLR
O M10. 2
O M10.3
= M10.4

Click to expand...

Not necessarily, you could adjust the code to:

A M10. 2
O M10.3
= M10.4

It's explained here...

http://support.automation.siemens.com/WW/view/en/188959


**Edit**
For clarification: This post applies to the behaviour of the OR instruction after a jump in a S7-300 CPU.

Yes, this is true, but as I mentioned above you could then have problems if it was preceded by a JCN, which would prevent your A M10.2 from working correctly.

Berger also recommends that one should write the logic to reflect the functional intention and Step7 seems to be of this opinion as well. If you take the above STL statement and convert it to function block (and I suspect Ladder as well, although I haven't tried it) then convert back to STL, you'll find that your "A M10.2" has magically become "O M10.2"!

By the way krk, thanks for the link to the Siemens FAQ, I had a quick look and couldn't find it yesterday, although I've also posted it myself in a previous Thread! Come to that, I couldn't find the old Thread either!

Cheers

Roy

Roy,

RMA said:

Yes, this is true, but as I mentioned above you could then have problems if it was preceded by a JCN, which would prevent your A M10.2 from working correctly.

Click to expand...

Ahh, but if it was 'carrying the RLO state' then for a JCN, the 'carried RLO' would be a 0 so the A M10.2 would work OK.

RMA said:

Berger also recommends that one should write the logic to reflect the functional intention

Click to expand...

Absolutely, I agree with this and follow it when coding.
I wasn't saying that changing the 'O M10.2' to 'A M10.2' is good practice, just an alternative...[sound of back-tracking ]


Just out of curiosity, I thought I'd have a look at this 'RLO carry' on a test rig. The one I had available was fitted with a 317 2PN/DP which did not exhibit this behaviour at all. Perhaps this is a 'ASIC' machine rather than a 'compiler machine'.
(See the FAQ)

I then had a look using PLCSIM, the 'RLO carry' behaviour only occurred with the JU instruction (I only tested JU, JC & JCN).


I have a newish(MMC) 315 2DP around, if I get time I'll connect it up and test it.


Later,

Kevin

Sounds interesting, my original meet-up with this problem was with a 317-2 DP not PN, so it looks as though there's more of a difference between the two 317s than one might assume!

Ahh, but if it was 'carrying the RLO state' then for a JCN, the 'carried RLO' would be a 0 so the A M10.2 would work OK.

Click to expand...

Mmm, I think we need to test this as well. I must admit, I just assumed the problem would also affect JCN (although I suspected JU might be different), but I hadn't actually tried it out. It would be nice to get the whole business firmly tied down, because I know from experience that you can spend a heck of a lot time searching for the problem in your program, if you don't know about it!

My reasoning was that if the carried RLO was "0" it would effectively be AND'ed with the A M10.2 leading to a result of FALSE even if M10.2 were TRUE. I'll need to find a test machine as well I think!

Cheers

Roy