You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

Reply
 
Thread Tools Display Modes
Old June 27th, 2020, 04:27 PM   #1
orense
Member
Norway

orense is offline
 
Join Date: Apr 2006
Location: Norway
Posts: 183
Clarifications regarding RLO in STL in Simatic Manager

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?
  Reply With Quote
Old June 27th, 2020, 05:45 PM   #2
mk42
Lifetime Supporting Member
United States

mk42 is offline
 
Join Date: Jun 2013
Location: MI
Posts: 2,604
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.
  Reply With Quote
Old June 27th, 2020, 06:02 PM   #3
Thomas_v2
Member
Germany

Thomas_v2 is offline
 
Join Date: Apr 2009
Location: Ger
Posts: 442
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."
  Reply With Quote
Old June 27th, 2020, 06:13 PM   #4
orense
Member
Norway

orense is offline
 
Join Date: Apr 2006
Location: Norway
Posts: 183
Quote:
Originally Posted by mk42 View Post
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.
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.
  Reply With Quote
Old June 29th, 2020, 01:12 PM   #5
Lare
Member
Finland

Lare is offline
 
Join Date: Jan 2006
Location: Finland
Posts: 1,471
Quote:
Originally Posted by orense View Post
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.





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.
  Reply With Quote
Old June 29th, 2020, 02:15 PM   #6
kamenges
Member
United States

kamenges is offline
 
kamenges's Avatar
 
Join Date: Nov 2002
Location: Brillion, WI
Posts: 4,138
Quote:
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.
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
  Reply With Quote
Old June 29th, 2020, 02:41 PM   #7
Lare
Member
Finland

Lare is offline
 
Join Date: Jan 2006
Location: Finland
Posts: 1,471
Quote:
Originally Posted by kamenges View Post
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

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.com...=0&pageSize=10


https://support.industry.siemens.com...=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 by Lare; June 29th, 2020 at 02:44 PM.
  Reply With Quote
Old June 29th, 2020, 03:01 PM   #8
kamenges
Member
United States

kamenges is offline
 
kamenges's Avatar
 
Join Date: Nov 2002
Location: Brillion, WI
Posts: 4,138
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 by kamenges; June 29th, 2020 at 03:03 PM. Reason: Clarification
  Reply With Quote
Old June 29th, 2020, 03:39 PM   #9
sigmadelta
Member
Canada

sigmadelta is offline
 
Join Date: Apr 2016
Location: From Canada - Living in Bulgaria
Posts: 1,559
Quote:
When we ran the program I noticed that M7.0 changed status based on the RLO coming from Q42.0
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.
__________________
Automation Programmer
PLC / HMI / SCADA / SQL
New Systems, Modifications
System Upgrades & Conversions
Siemens EPROM & EEPROM Service
------------------------
Visit: contrologica.com
Email: info@contrologica.com
  Reply With Quote
Old June 29th, 2020, 03:47 PM   #10
sigmadelta
Member
Canada

sigmadelta is offline
 
Join Date: Apr 2016
Location: From Canada - Living in Bulgaria
Posts: 1,559
See example (I left M6.1 = 1 and M6.2 = 1 to emphasize the O M7.0 instruction).
Attached Images
File Type: png S7_STL_RLO.png (16.1 KB, 37 views)
__________________
Automation Programmer
PLC / HMI / SCADA / SQL
New Systems, Modifications
System Upgrades & Conversions
Siemens EPROM & EEPROM Service
------------------------
Visit: contrologica.com
Email: info@contrologica.com

Last edited by sigmadelta; June 29th, 2020 at 04:00 PM.
  Reply With Quote
Old June 29th, 2020, 03:53 PM   #11
kamenges
Member
United States

kamenges is offline
 
kamenges's Avatar
 
Join Date: Nov 2002
Location: Brillion, WI
Posts: 4,138
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
  Reply With Quote
Old June 29th, 2020, 03:57 PM   #12
sigmadelta
Member
Canada

sigmadelta is offline
 
Join Date: Apr 2016
Location: From Canada - Living in Bulgaria
Posts: 1,559
Quote:
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.
Same result:
Attached Images
File Type: png S7_STL_RLO_example2.png (15.6 KB, 36 views)
__________________
Automation Programmer
PLC / HMI / SCADA / SQL
New Systems, Modifications
System Upgrades & Conversions
Siemens EPROM & EEPROM Service
------------------------
Visit: contrologica.com
Email: info@contrologica.com
  Reply With Quote
Old June 29th, 2020, 03:59 PM   #13
sigmadelta
Member
Canada

sigmadelta is offline
 
Join Date: Apr 2016
Location: From Canada - Living in Bulgaria
Posts: 1,559
STL doesn't care whether it is split into networks or not.
__________________
Automation Programmer
PLC / HMI / SCADA / SQL
New Systems, Modifications
System Upgrades & Conversions
Siemens EPROM & EEPROM Service
------------------------
Visit: contrologica.com
Email: info@contrologica.com
  Reply With Quote
Old June 29th, 2020, 04:07 PM   #14
kamenges
Member
United States

kamenges is offline
 
kamenges's Avatar
 
Join Date: Nov 2002
Location: Brillion, WI
Posts: 4,138
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:

Quote:
originally posted by orense:

So I wrote CLR on the line after =Q42.0, and above A(, and the logic worked as intended.
Keith
  Reply With Quote
Old June 29th, 2020, 04:09 PM   #15
Lare
Member
Finland

Lare is offline
 
Join Date: Jan 2006
Location: Finland
Posts: 1,471
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
Attached Images
File Type: jpg RLO_test.jpg (119.6 KB, 39 views)
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
stl in Simatic manager version 5.5 Alkantara John LIVE PLC Questions And Answers 0 October 8th, 2018 11:00 AM
S7 300 with Profibus communication jayasiri LIVE PLC Questions And Answers 26 August 27th, 2015 06:00 AM
STL programming on SIMATIC Manager Step 7 v5.5 Rogalson LIVE PLC Questions And Answers 2 June 4th, 2015 02:47 PM
STL programming on SIMATIC Manager Step 7 v5.5 Rogalson LIVE PLC Questions And Answers 1 June 4th, 2015 02:31 PM
DIGSI 4.83 with simatic manager v5.5 panthripu LIVE PLC Questions And Answers 7 May 11th, 2014 08:51 AM


All times are GMT -5. The time now is 08:59 PM.


.