Clarifications regarding RLO in STL in Simatic Manager

orense

Member
O
Join Date
Apr 2006
Location
Norway
Posts
196
Hi,

I recently had an incident with a program that was written in STL. It went like this:

A M0.0
= Q42.0

A(
AN M6.1
AN M6.2
O M7.0
)
= Q42.1


When we ran the program I noticed that M7.0 changed status based on the RLO coming from Q42.0, and not by the conditions for M7.0, which were written in other part of the program. M6.1 and M6.2 did not change, so the only thing that changed when we ran program was Q42.0, and it had impact on condition of M7.0.

So I wrote CLR on the line after =Q42.0, and above A(, and the logic worked as intended.

So to me it seems that when one writes this code in STL one has to be cautious about the RLO from previous instructions in the code. Is this considered a bug?
What happens if I write this in ladder or function? Will simatic manager insert the necessary handling of RLO so that the code does what it is supposed to do?
 
You say "worked as intended". What was the desired result, and what specifically happened instead?




It's been a long time since I've messed with STL, but, as far as I know, there is no circumstance where the value stored in M7.0 should be affected by the code above. That's what it sounds like you're saying you think was going on.
 
Take a look at the current firmware version of your CPU and the available firmware updates from Siemens.
The updates may scare you, like "Multiple bit logical interconnections that concern the same byte will now be executed correctly."
 
mk42 said:
You say "worked as intended". What was the desired result, and what specifically happened instead?




It's been a long time since I've messed with STL, but, as far as I know, there is no circumstance where the value stored in M7.0 should be affected by the code above. That's what it sounds like you're saying you think was going on.
Click to expand...

Thanks !

In this particulary case, M6.1 and M6.2 were both high, so since they are inverted the contribution was low. M7.0 was high, so therefore Q42.1 should stay high. Prior to me putting in CLR, when Q42.0 went high, it changed the RLO on M7.0, which put Q42.1 low. I agree with you, I did not expect that the RLO from Q42.0 affected M7.0, but I saw it happen. And when I put in CLR, Q42.0 did not have any affect anymore.

What I meant by "as intended" was that what I explained here should happen, and M7.0 not being affected by anything prior in the code.

I recorded the screen while monitoring this, and I slowed it down so I could see specifically what happened afterwards.
 
orense said:
Thanks !

In this particulary case, M6.1 and M6.2 were both high, so since they are inverted the contribution was low. M7.0 was high, so therefore Q42.1 should stay high. Prior to me putting in CLR, when Q42.0 went high, it changed the RLO on M7.0, which put Q42.1 low. I agree with you, I did not expect that the RLO from Q42.0 affected M7.0, but I saw it happen. And when I put in CLR, Q42.0 did not have any affect anymore.

What I meant by "as intended" was that what I explained here should happen, and M7.0 not being affected by anything prior in the code.

I recorded the screen while monitoring this, and I slowed it down so I could see specifically what happened afterwards.
Click to expand...








A M0.0

= Q42.0



A(

AN M6.1

AN M6.2

O M7.0

)

= Q42.1




It should be



NW1:
A M0.0
= Q42.0


NW2:

AN M6.1
AN M6.2
O M7.0
= Q42.1


And if you wrote only this to intependent network

A(

AN M6.1
AN M6.2
O M7.0
)

= Q42.1


Siemens converts it



AN M6.1
AN M6.2
O M7.0
= Q42.1


Looks like lonely A( makes error on Siemens STL.
 
Originally posted by orense:

I agree with you, I did not expect that the RLO from Q42.0 affected M7.0, but I saw it happen.
Click to expand...

orense, I want to confirm this statement. Was the value of M7.0 changed or was the state of the RLO at the execution of M7.0 changed? Those are two very different things.

I'm pretty sure what Lare shows with the addition of the network delimiters will make the difference. The value of the RLO is only explicity set by the plc in specific circumstances. One of those is at the beginning of a new network. The fact that the state of the RLO remains based on the previous logic in a network allows one to do some pretty cool things in STL. However, it requires the user to really understand what is going on. With great power comes great responsibility.

For you AB Logix users out there, this would be the equivalent of multiple series output instructions in one rung separated by additional logic.

Keith
 
kamenges said:
orense, I want to confirm this statement. Was the value of M7.0 changed or was the state of the RLO at the execution of M7.0 changed? Those are two very different things.

I'm pretty sure what Lare shows with the addition of the network delimiters will make the difference. The value of the RLO is only explicity set by the plc in specific circumstances. One of those is at the beginning of a new network. The fact that the state of the RLO remains based on the previous logic in a network allows one to do some pretty cool things in STL. However, it requires the user to really understand what is going on. With great power comes great responsibility.

For you AB Logix users out there, this would be the equivalent of multiple series output instructions in one rung separated by additional logic.

Keith
Click to expand...


Im not good on STL, but CLR instruction reset FC-bit. (first check bit) So next instructions uses allways RLO = 1.
Also = (assign) resets FC.


If code is divided to different networks, then it should work allways (and only difference is FC and RLO bit states)



It looks likes that it is error and Siemens actually reads it now like this. (which is different than Siemens should work, but same than some other STL compilers?)






A M0.0

= Q42.0 





 A Q42.0 

A(

 AN M6.1

 AN M6.2

 O M7.0

)

 = Q42.1


https://support.industry.siemens.co...-of-networks-in-stl/138693?page=0&pageSize=10


https://support.industry.siemens.co...nd-stl-instructions/113425?page=0&pageSize=10




p.s If you write it like this on one network, is Q42.1 intependent of status Q42.0?



A M0.0
= Q42.0


AN M6.1
AN M6.2
O M7.0
= Q42.1
 
Last edited:
As I remember it, if the STL is written as:

A M0.0
= Q42.0


AN M6.1
AN M6.2
O M7.0
= Q42.1


the state of the RLO will be 1 and the state of FC will be 0 after execution of "= Q42.0" if "A M0.0" was true. Without any parentheses present, the statement "O M7.0" is really "RLO OR M7.0". I'm not sure if this is correct but it looks like the compiler would have interpreted the "AN M6.1 AN 6.2" combination as a separate logical statement to be OR'ed with the RLO prior to the O M7.0 statement. Since the RLO was 1 at that point, any OR operation will result in an RLO of 1 after the operation. The addition of CLR after the = Q42.0will set the RLO to 0, which would require at least one true statement in the next set of instructions in order for the RLO state to be 1 at the = Q42.1 statement.

I guess the moral of the story is make sure you use a new network for logically unrelated statements. It is the network divisions that put the processor status bits in the state required for the subsequent statements to act the way most people expect them to. I don't think there is anything specifically wrong with what orense originally posted as long as it is understood what is happening. I'm not a big Siemens user but back in the day I know I wrote STL sections that took advantage of the fact that the RLO is not set to a "known" condition until a new network is established.

Keith
 
Last edited:
When we ran the program I noticed that M7.0 changed status based on the RLO coming from Q42.0
Click to expand...

This will never happen. You've got something else going on. Cross-reference address M7.0, and also check for addresses MB7, MW6/MW7, and MD4/MD5/MD6/MD7. Your M7.0 might be an overlapped bit.

Once you have an assignment statement (=), a new series of logic starts.
 
sigmadelta, run that same example but remove the A( set around the second logical construct. I don't have any Siemens stuff to play with or I would give that a try. This structure is the initial thing that OP was talking about.

Keith
 
That surprises me. Granted, I haven't done a huge amount with Siemens since I was working with S7-300 plcs in 2003. But that isn't the way I remember things working.

Why do you think this made a difference:

originally posted by orense:

So I wrote CLR on the line after =Q42.0, and above A(, and the logic worked as intended.
Click to expand...

Keith
 
Same result also with Step7 classic simulator.


Chech also that you don't have clock byte (classin and TIA) or allways false bits (TIA portal) configured to MB0 on hardware

RLO_test.jpg
 

Similar Topics

V
OMRON CPM 2A & RS 232 CLARIFICATIONS
Dear All, I am Using Omron CPM 2A PLC in a Application. This controller has 2 ports a) Pheripheral Port and b) RS 232 Port. Pro Face HMI...
Replies
1
Views
5,057
gtsuport
G
A
serial communication(more clarifications)!!
1.Why RS 232 cannot be used for multidrop applications? 2.Why RS 232 can be used only up to 15m but RS 485 for longer distance? 3.Which factor...
Replies
7
Views
3,225
abhilashponoli
A
A
Regarding: Cause and Effect Diagram
Hi everyone, I need a solution based on the cause and effect diagram, especially a macro sheet or VBA script in Excel, which will help me generate...
Replies
0
Views
70
Arbind Kumar
A
T
IT question regarding wireless access to PLC device using a typical wireless router..
I know this can be done, but I can't get the router config right. My goal is to physically connect(using an ethernet cable) a device(PLC, RTU...
Replies
9
Views
1,012
I_Automation
I_Automation
A
Query regarding common positive and common negative in a stepper driver
Hi, I am connecting an Autonics make stepper driver type, MD5-ND14 to a Kinco PLC (K205 series) this has a sourcing output which cannot be...
Replies
2
Views
1,112
arbj
A
Back
Top Bottom