Skip to Content

Register Login

Default Header

(header konnte nicht geladen werden)

Navigation

S7 programming behavior

Created by: Nico1985 at: 6/26/2012 12:43 PM (5 Replies)

Rating (3)

Thanks 4

6 Entries

6/26/2012 12:43 PM	Rate (0)
Nico1985 Posts: 33 Rating: (0)	Hi, I've encountered some strange behavior of S7 I've created an FC which has the following code. NW1: A M_RESET R TEST_OUTPUT NW2: A TEST_INPUT S TEST_OUTPUT TEST_OUTPUT is an output variable. TEST_INPUT is an input variable This FC works as long is a attach a marker to it (e.g. M86.0). When i try to attach a data bit (e.g. DB120.DBX11.0) then TEST_OUTPUT is high for as long as TEST_INPUT is high, but when TEST_INPUT becomes low again, TEST_OUTPUT also becomes low. Does anyone know what the difference is between a marker and e data bit? When i declare TEST_OUTPUT as an in_out variable, it works in both cases. I know that an FC cant store values, so i understand why it doenst work with the data bit. But i find it strange that this works with M86.0. Does anyone know how this comes? Tnx in advance, Nico
Nico1985 Posts: 33 Rating: (0)
Suggestion To thank Quote Answer

6/26/2012 1:49 PM	Rate (2)
fritz Diamond Expert Joined: 10/7/2005 Last visit: 9/14/2025 Posts: 3049 Rating: (1062)	Hello Nico1985 the behaviour you observe is (perhaps unfortunately) "normal". The root cause for the problem is that you do NOT always write to the FC OUT when you call it (your Set/Reset instructions are conditional writes) which leaves the OUT variable "unintialised" which in turn may lead to the OUT variable assuming random values. Attached is a pic from Step 7 inbuilt help about Functions which has more on this suject. If you are curious to find out why it works with M bits but not with DB bits, allow me to direct you to THIS thread which has all the gory detail on what goes on behind the scenes. I hope this helps Attachment Functions.jpg (150 Downloads)
	Cheers fritz The advice and opinion given in this thread is that of the author and does not necessarily reflect the views of I S Systems Pty Limited. To find out how I S Systems can help you with your automation needs please visit www.issystems.com.au.
Suggestion To thank Quote Answer
This contribution was helpful to 2 thankful Users Lucky123 Nico1985

6/26/2012 3:20 PM	Rate (0)
manmeet Gold Member Joined: 1/3/2006 Last visit: 2/19/2024 Posts: 726 Rating: (71)	Hi, Fritz hasexplained you the problem. Now as a thumb rule whenever you want to pass DBreference to IN, OUT, IN/OUT use FB.

Suggestion To thank Quote Answer

6/27/2012 7:36 AM	Rate (0)
Nico1985 Posts: 33 Rating: (0)	Tnx for the reply's. I thought that it was something like that. So if i got it correct, normally Step 7 does 'pass by value'. But in the case of I/M/Q/L it can also 'pass by adress'. That's the reason when i use M28.0, the FC does not write to the temp aera, but directly to M28.0. If i use DBxx.DBXxx.x we have a 6 byte adress. Step 7 cant pass this, because it only can pass a 4 byte adress. For this reason, the fc writes to the temp-aera, which cannot remember its original state, and that's why the problem occurs. Please correct me if i am wrong. Many thanks for this clearifying answers!!!
Nico1985 Posts: 33 Rating: (0)
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users fritz

6/27/2012 9:35 AM	Rate (1)
fritz Diamond Expert Joined: 10/7/2005 Last visit: 9/14/2025 Posts: 3049 Rating: (1062)	Nico1985 So if i got it correct, normally Step 7 does 'pass by value'. But in the case of I/M/Q/L it can also 'pass by adress'. That's the reason when i use M28.0, the FC does not write to the temp aera, but directly to M28.0. If i use DBxx.DBXxx.x we have a 6 byte adress. Step 7 cant pass this, because it only can pass a 4 byte adress. For this reason, the fc writes to the temp-aera, which cannot remember its original state, and that's why the problem occurs. Spot on correct dear Nico1985andyou very neatly summarised the essence of it. @ manmeet: manmeet Now as a thumb rule whenever you want to pass DB reference to IN, OUT, IN/OUT use FB. I can't stop you from having this rule of thumb, but I do disagree with it. There is nothing at all wrong with using fully qualified DB addresses (e.g. DB10.DBX7.1, DB17.DBW4 etc.) as FC Parameters (I do it all the time). What is wrong though is to NOT (orconditionally) write to FC OUT parameters.
	Cheers fritz The advice and opinion given in this thread is that of the author and does not necessarily reflect the views of I S Systems Pty Limited. To find out how I S Systems can help you with your automation needs please visit www.issystems.com.au.
Suggestion To thank Quote Answer

6/27/2012 1:05 PM	Rate (0)
manmeet Gold Member Joined: 1/3/2006 Last visit: 2/19/2024 Posts: 726 Rating: (71)	OK Fritz Will eliminate this rule. And instead remeber if want to SET/RESET inside the FC something likeDB10.DBX7.1then use IN_OUT and not IN and OUT !!
	Last edited by: manmeet at: 6/27/2012 2:52 PM Last edited by: manmeet at: 6/27/2012 2:51 PM
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users fritz

|

Share this page:

Share this page on...

Follow us on