Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

Good Coding Structure / Practice

Created by: FatRich at: 10/27/2008 7:37 PM (8 Replies)

Rating (3)

Thanks 5

9 Entries

10/27/2008 7:37 PM	Rate (0)
FatRich Posts: 24 Rating: (2)	Hi In the past I have only used FB's for blocks of lower level code that are to be used multiple times (e.g. pump). The higher level codeI have stored in FC's and used a shared DB. I'm working on a new project for which I am being forced to use FB's only. My query: Its possible tousestatic variable from one FB in another FB. Is this deemed to be reasonable practice? Or should any variables that need to be read outside the generating FB be declared as OUT and therfore IN on the recieving FB? Also is the practice of reading static variable outside the generating FB reliable? It is quicker to code this way rather than having to declare lots of in/out variables but it seems like bad practice to me. Infact I think FB's should only be used when the code is to be called multiple times, otherwise I think an FC with a shared DB is a better method. Any comments would be appreciated.
FatRich Posts: 24 Rating: (2)	Last edited by: FatRich at: 10/27/2008 11:54 PM
Suggestion To thank Quote Answer

10/27/2008 10:03 PM	Rate (0)
FunStuff Posts: 103 Rating: (10)	I don't know why you are being forced to program in this way but in my opinon you are correct in your thinking. I use FB's typically for redundant blocks like valve control where a state needs to be maintained within the block or for min/max functions etc... I tend to use FC's with global DB's for most code. I don't think there are any problems with coding using all FB's. But from experience reading code that was left to me by predecessors that was written with all FB's and instance DB's I can tell you that you can't use cross reference easily. It becomes a real pain when trying to quickly review code when you can't right click and go to the next point of use. Instead you have to find the exact data inside the instance data block and reference it from the cross ref tool each time you want to find something.
FunStuff Posts: 103 Rating: (10)
Suggestion To thank Quote Answer

10/28/2008 1:00 AM	Rate (3)
fritz Diamond Expert Joined: 10/7/2005 Last visit: 11/7/2024 Posts: 3026 Rating: (1057)	Good practice in general would be to use an FBfor "functions" that need to have a "memory" and an FC for "functions" that do not need to have a "memory". As for your specific questions, yes, you can use the STAT variables from on FB in another FB. A good practice way of doing so would be via Multi-Instance calls (i.e. embedd FB'sas multi-instance calls inside a "main" FB). A "bad" practice (albeitworking)wouldbe to access them just like you access data inglobal DB's. Example: FB 7 has Instance DB 7 (Symbol: "FB7_IDB") and an INT type STAT variable called "Volume" in DBW10 of DB7. Even though DB7 is the instance DB of FB7 and acts as its "memory", it is "just" another DB at the end of the day. As such you can access DB7.DBW10 (Symbol: ""FB7_IDB".Volume") everywhere in your program (in other FB's, FC's orOB's). While I have seen this done in other people program,I do not recommend doing this and personally would avoid doing so. My main reason foravoiding this"bad practice" is thatInstance DB's are automatically generated. Imagine someone changing the interface declaration ofFB7 sometime in the future and adding or removing variables from it which werelocated before DBW10. Any access insideFB7 does automaticallystay "intact"when done so (assuming access to the FB variables has been done via good practice fully qualified symbolic access). Any access to DB7 outside FB7 howevernow needs to be checked which is easily "overlooked" after recreation of FB7's Instance DB. While working withfull symbol prioritycan overcome this issue, it is still "bad practice" in my book to access instance DB's data outside the FB they belong too. Apart from this, you would also "violate" IEC61131-3 guideines if you were to accessInstance DB dataoutside the FB to which they belong (note that you will NOT "violate" IEC61131-3 guideines if you do the multi-instance calls as there is only one Instance DB for all embeeded FB calls). Last but not least, even though you are "forced" to program only FB's, what stops you from declaring Global DB's anyhow and use themjust like you would have used them to share data amongst FC's? Enough said, this is my take on this subjectandI hope it 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
This contribution was helpful to 2 thankful Users KayBee kohhal

10/28/2008 11:31 AM	Rate (0)
FatRich Posts: 24 Rating: (2)	Thank you for your comments. I agree. I think it bad practice to access instance data outside the respective FB. Even when using symbolic access. I am reluctant to go down the multi-instance route as this can create problems when making changes to a live plant. A minor change to the higher level FB can impact on all the nested FB's. This could cause a problem to the plant operation when the change is downloaded (as the nested FB static variables may have been re-assigned new addresses which will contain different data, initially). As you suggest I could declare global DB's and use the FB's as I would an FC. However this would mean I end up with twice the number of required DB's, which does not seem right. With regards to IEC61131-3. Does this the state that instance data should not be used outside the FB? I have found a couple of statements that would suggest this but not implicitly: "Only the input and output variables shall be accessible outside of an instance of a function block, i.e.the function block's internal variables shall be hidden from the user of the function block". "The scope of an instance of a function block shall be local to the program organization unit in which it is instantiated, unless it is declared to be global in a VAR_GLOBAL block as defined in 2.7.1." What is the S7 equivalent of a program organization unit?
FatRich Posts: 24 Rating: (2)
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users KayBee

10/28/2008 4:08 PM	Rate (0)
Jason. Experienced Member Joined: 7/13/2008 Last visit: 9/20/2024 Posts: 107 Rating: (9)	I think reliability depends on not changing of the interface structure if you must code all blocks as fb's. The structure can be handy if you have big interface descriptions that can all work within the same architecture. Data availability for certain is nice, as the program can be quite clean to read, and the cross reference list can be relatively small. On the flip side, you find that you have many data blocks, and troubleshooting end-end can be interesting if your instance db does not contain useful diagnostic data. I see components of some of the systems that I work on constantly coded in this fasion. As long as there is a map of the instance data block that is available, I don't typically have a problem with dealing with it from the diagnostic point of view. As you implied, the nightmare comes when someone doesn't understand what it means when the interface is changed.

Suggestion To thank Quote Answer

10/29/2008 8:45 AM	Rate (0)
fritz Diamond Expert Joined: 10/7/2005 Last visit: 11/7/2024 Posts: 3026 Rating: (1057)	Hello FatRich The following three types of POU’s (program organization Units) exist in IEC61131-3: 1.) PROGRAM 2.) FUNCTION 3.) FUNCTION BLOCK Item 2 and 3 are (somewhat obvious but nonetheless elegantly) implemented in the Siemens S7 world as FC’s and FB’s respectively. Item 1 (PROGRAM) exist in an S7 as a combination of the Operating system, I/O configuration (e.g. HWconfig) and OB’s. The following statement from IEC61131-3 that you mentioned is definitely somewhat confusing and ambiguous:"The scope of an instance of a function block shall be local to the program organization unit in which it is instantiated, unless it is declared to be global in a VAR_GLOBAL block as defined in 2.7.1." As far as the S7 implementation of IEC61131-3 is concerned, I would not worry about this too much though. You can NOT create an Instance DB (IDB) with a “VAR_GLOBAL” property attached to it. What you can do is to create a “Shared DB” (which cannot be used as an IDB) or an Instance DB (which needs to be assigned to an FB if explicitly inserted as a new object into the program, typically you’ll auto create it when you do the FB call). Either way, an IDB always belongs to an FB and is NOT/can NOT be classified as Global memory (and I'm sure I'm telling you lots of things you know already). Ideally you convince the powers to be that it does not make too much sense to be forced to program the S7 only with FB’s (which you’ve probably tried already). Should you be forced to do so anyhow, perhaps this little trick helps with the commissioning and the required software changes that are typically require during commissioning: Declare a fair amount of extra spare STAT variables (e.g Name: “SPARES”, Data Type: “Array [1..20] of INT”) at the end of every FB as you develop your program with FB’s (and multi-Instance calls where appropriate/useful). If you now need for example a new STAT variable of type REAL in an FB during commissioning, you’ll simply reduce the array count by 2 and declare a new REAL variable in front of the “SPARES” array. The important things here are: - The overall length of Instance Data Block must NOT change - You only download the FB but NOT the instance DB - Once you’ll finish with commissioning you’ll find a suitable shutdown time during which you’ll download all the (re-create Instance DB’s) This may sound a bit weird, but actually works well, simply because the instance DB’s already exist in the correct length in the PLC and the MC7 code that is executed in the PLC couldn’t care less about data type matching or symbolic name. Note that you’ll miss out on being able to monitor the Instance Data Blocks directly for FB’s that you’ve changed this way (as Step7 will realize that there is type/structure conflict). Note too that the above “trick” does not work well with multi-instance calls (as the calling FB will complain about a change in structure and you can’t save it anymore unless you correct this conflict). Nonetheless, it may help, but please test this for yourself as it is not an intuitive way of making S7 program changes and requires some care when employed. Good luck with your project and continue to be persistent to convince whoever had the “brilliant” idea to program only in FB’s to reconsider his request.
	Last edited by: fritz at: 10/29/2008 8:48 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

10/30/2008 1:15 PM	Rate (0)
FatRich Posts: 24 Rating: (2)	Thanks for all your comments.
FatRich Posts: 24 Rating: (2)
Suggestion To thank Quote Answer

9/17/2015 11:58 AM	Rate (0)
CS Moderator Moderator Joined: 9/1/2005 Last visit: 11/8/2024 Posts: 4111 Rating: (195)	New question published by eamonnatwork is split to a separate thread with the subject STEP-7 -- IEC61131-3 Certification (second thread). Best regards CS Moderator
	My Forum is the place to personalize your profile, track your topics, and maintain content that interests you. Best regards CS Moderator
Suggestion To thank Quote Answer

9/17/2015 3:02 PM	Rate (0)
Piotr.M Platinum Expert Joined: 6/24/2013 Last visit: 11/6/2024 Posts: 1652 Rating: (426)	Hi What I do is I use FBs for every big part of the machine (like conveyor, heater, etc.) and use FC for all small, frequently used tasks (drive control, timer, etc.) . should FC need items with memory they are passed as IQ and linked to STAT in calling FB. For global variables I use GLOBAL data block - divided into structures - one for each MC part. this way globals are nicely structured and Markers (Ms) are used strictly for testing only. then after tests it is easy to find and remove all test - only code and frigs. moreover, I use following naming: - inputs/outputs (analogues: comment show standard and range): I_<area>_<ID from drawings>_<function> for example I_DESK_S1_START I_<area>_<ID from drawings>_<function> for example Q_DESK_H1_RNG_LAMP - function interface: I_<name> - FB/FC Inputs Q_<name> - FB/FC Outputs IQ_<name> - FB/FC Inputs/Outputs <NAME> - FB Static Variables [UPPERCASE] <Name> - FB/FC/OB Temp Varaibles in HMISCADA data block (divided into structs for each part of MC): H_<NAME> - HMI indicators (hmi read only) HS_<NAME> - HMI Setpoints / Buttons (hmi read/write) HA_<NAME> - HMI Alarms this way you do not need to look at interface when scrolling through function - variable names tells everything. (i..e if it is in/out or a local temp/stat variable)
	Last edited by: Piotr.M at: 9/17/2015 3:12:29 PM
Suggestion To thank Quote Answer
This contribution was helpful to 2 thankful Users zzVss kohhal

|

Share this page:

Share this page on...

Follow us on