Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

Communication between Safety and non-safety programs

Created by: PAUL H at: 6/23/2009 8:09 AM (14 Replies)

Rating (2)

Thanks 5

Result pages:: |; 1 | 2; |

15 Entries

Entries per page: 10 | all

6/23/2009 8:09 AM	Rate (0)
PAUL H Posts: 1 Rating: (0)	I have worked with Step7 for a while, but this is my first safety PLC applicationso I may not have followed what one would consider as standard practice. My initial safety program is active and I have tested the functionality of the safety I/O. When I compile the program I receive two warnings: W: The safety program contains no reintegration for the F-I/O with the start address (LADDR) 0. W: The safety program contains no reintegration for the F-I/O with the start address (LADDR) 16. I believe these warnings are due to the fact that I have set the system up as redundant I/O using a FDI24xDC24V (I address 0...9) & FDO10x24V/2A Q (address 16...21) and did not use any of the library F_FUNC blocks, but simply referenced the raw I/O directly in the logic. The next phase of development is requiring connections between the safety and non-safety programs. Specifically I need to be able to monitor the status of some safety memory bitsin the non-safety program and write to safety memory bits from a HMI runningWinCC. I am running the following on my PC: Step7 V5.4 + SP4 S7 Distributed Safety Programming V5.4 + SP4 S7 F ConfigurationPack V5.5 + SP5 WinCC V7
PAUL H Posts: 1 Rating: (0)
Suggestion To thank Quote Answer

6/23/2009 8:42 AM	Rate (0)
yy1 Gold Member Joined: 3/24/2009 Last visit: 7/9/2024 Posts: 535 Rating: (112)	Dear PAUL H, PAUL H My initial safety program is active and I have tested the functionality of the safety I/O. When I compile the program I receive two warnings: W: The safety program contains no reintegration for the F-I/O with the start address (LADDR) 0. W: The safety program contains no reintegration for the F-I/O with the start address (LADDR) 16. I believe these warnings are due to the fact that I have set the system up as redundant I/O using a FDI24xDC24V (I address 0...9) & FDO10x24V/2A Q (address 16...21) and did not use any of the library F_FUNC blocks, but simply referenced the raw I/O directly in the logic. You get this warning, because you have no code for reintegration of the failsafe-modules in your code. To program this reintegration, you can either add the F_ACK_GL-block to your program (this block can reintegrate all used F-modules), or you can reintegrate one module with a positive edge on the ACK_REI-variable of the F-I/O DB PAUL H The next phase of development is requiring connections between the safety and non-safety programs. Specifically I need to be able to monitor the status of some safety memory bitsin the non-safety program and write to safety memory bits from a HMI runningWinCC. You can read any of your safety-memory bits in your standard program. Writeing to memory-bits from the WinCC should be possible, but don't write direct to variables in an F_DB (this will cause an error at runtime). Hope this helps! Regards, yy1

Suggestion To thank Quote Answer

6/26/2009 2:22 AM	Rate (1)
Safety1 Posts: 73 Rating: (20)	Hello yy1, The message you received "warning no reintegration" is generated by the compiler. If the compiler does not find a reintegration function [eg F-I/O-DB.ACK_REI] or other reintegration method the message is displayed. You will find a very good app note on the F-I/O DB reintegration for S7 Dist Safety at http://support.automation.siemens.com/WW/view/en/22304119 You mention configuring redundant I/O. I am assuming you mean a dual channel input such as CAT4 and not redundant I/O modules.S7 Distributed safety cannot be used with redundant I/O. Unless may be you create some safety logic to switch between two channels. You can use the safe input addresses in your standard program but in order to have the actual status you must also look at the QBAD bit. The easier method is to add a non safe bit [eg address M0.0] in parallel with a safety output or at the end of a rung for HMI status. The M0.0 bit can then be used in the standard program. Please be careful with using inputs Mx.x bits as inputs in the safety program. If the status of the M bit can change while the safety program is running the safety system may detect this as a RAM fault or other fault and stop the PLC. It is better to buffer the non safe data into another area just before you call the FCALL. Please see section7, 7.1 7.2http://support.automation.siemens.com/WW/view/en/22099875 See also page 124 for info on the F_GLOBDB also referred to as F Shared DB. This DB contains the safety signature which can be displayed on an HMI. Once in the HMI you can archive it or create an alarm if the value changes. May be you want to put the PLC into stop if the value changes. The system is very flexible to allow you to do just about anything.
Safety1 Posts: 73 Rating: (20)	Last edited by: Safety1 at: 6/26/2009 2:47 AM
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users Kahl

6/30/2009 9:40 AM	Rate (0)
Kodknackare Posts: 10 Rating: (0)	Safety1 Hello yy1, ... Please be careful with using inputs Mx.x bits as inputs in the safety program. If the status of the M bit can change while the safety program is running the safety system may detect this as a RAM fault or other fault and stop the PLC. It is better to buffer the non safe data into another area just before you call the FCALL. ... This is something that is carefully pointed out, but how is this practically implemented? Taken from page 126 of the A5E00109537-04 manual: "You must use dedicated memory bits if you want to read data from the standard user program (bit memory or PII of standard I/O) in the safety program and these data can be changed by the standard user program or an operator control and monitoring system during runtime of the F-runtime group in which the data are read - for example, because your standard user program is being executed by a higher priority cyclic interrupt. You must write the data from the standard user program to these memory bits immediately before calling the F-runtime group. You can then only access these memory bits in the safety program." What dedicated memory bits? Is there anywhere to configure this area? Simply assigning a Mx.x to another Mx.x does not change the possibility of the Mx.x to be changed while the F-Runtime group is running. Can someone shed a little bit of light on how to do this? A little bit of code maybe? If my safety program is triggered by OB35 (100ms) and all my other code is triggered by OB1, do I need to take this into account?
Kodknackare Posts: 10 Rating: (0)	Last edited by: Kodknackare at: 6/30/2009 9:42 AM
Suggestion To thank Quote Answer

6/30/2009 10:18 AM	Rate (0)
yy1 Gold Member Joined: 3/24/2009 Last visit: 7/9/2024 Posts: 535 Rating: (112)	Dear Kodknackare, Kodknackare What dedicated memory bits? Is there anywhere to configure this area? There is no special configuration for this area - you can define it for yourself. Kodknackare If my safety program is triggered by OB35 (100ms) and all my other code is triggered by OB1, do I need to take this into account? as the OB35 interrupts the OB1, there is no need to take this into accout, because the memory-bits can not be changed while the failsafe program is executing. You only have to take care, if you change the memory bits in an OB with a higher priority than your failsafe program! Regards, yy1

Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users Kahl

6/30/2009 10:26 AM	Rate (0)
Kodknackare Posts: 10 Rating: (0)	Ok, then I have no problems with that.
Kodknackare Posts: 10 Rating: (0)
Suggestion To thank Quote Answer

6/30/2009 11:12 AM	Rate (1)
fritz Diamond Expert Joined: 10/7/2005 Last visit: 12/12/2024 Posts: 3029 Rating: (1057)	yy1 as the OB35 interrupts the OB1, there is no need to take this into accout, because the memory-bits can not be changed while the failsafe program is executing. You only have to take care, if you change the memory bits in an OB with a higher priority than your failsafe program! yy1 Be careful guys as the above statement is not quite the whole truth. For example,the MB that you assigned to the CPU clock bist is updated by the OS asynchronicallyto you S7program. What this means is that these clock bitscan change during the execution of your safety program and MUST NOT directly be used in it (i.e. copy this CPU clock MB toanother MB within the OBfrom which you do your F-Call). For the same reason, if a SCADA or HMI writes tobits that you need in your safety program, you are better off to marshall them before the F-Call. The reason while one mustavoidthe possibilty of "changing bits during the execution of the Safety program" is becauseyou safety program is actually executed twice within the F-Call. First it executes the safety (LAD or FBD) logic that you programmed, followed by an execution of the (automatically generated during compile)inverted and WORD based (for diversity reasons) execution of your safety logic. At the end of these two executions, the Safety "OS" compares the result of both which must come up with exactly the opposite output state. If this is NOT the case the CPU assumes data corruption took place and does a (failsafe) shutdown. Obviously, if you have "bits" that change state between the twoexecutions you are asking for trouble. Attached is a pic which hopefully makes the above "mumbling" a bit clearer. I hope this helps Attachment S7-F Time redundancy & diversity.jpg (912 Downloads)
	Last edited by: fritz at: 6/30/2009 11:25 AM 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 yy1 Kahl

6/30/2009 11:56 AM	Rate (0)
yy1 Gold Member Joined: 3/24/2009 Last visit: 7/9/2024 Posts: 535 Rating: (112)	Thank you fritz, you are right. Asynchronous changes (e.g. by an OS) also have to be considered! Regards, yy1

Suggestion To thank Quote Answer

2/20/2012 8:21 AM	Rate (0)
h2_504 Experienced Member Joined: 11/8/2011 Last visit: 9/19/2023 Posts: 89 Rating: (1)	yy1 There is no special configuration for this area - you can define it for yourself. Dear yy1, How do you define this area? Is it a setting where you declare the start and the end of this area? Best regards, h2_504

Suggestion To thank Quote Answer

2/21/2012 12:17 AM	Rate (0)
fritz Diamond Expert Joined: 10/7/2005 Last visit: 12/12/2024 Posts: 3029 Rating: (1057)	Hello h2_504 there is no special "definiton" or "declaration" of the M bit area that you want topasson from the standard to the safety program. You simply decide on which M bits you want to use but must pay heed to chapter 7 of the SIMATIC Industrial Software S7 Distributed Safety - configuring and programming manualwhich will tell you the do's and don't's concenring this. I hope this helps
	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

|

Share this page:

Share this page on...

Follow us on