10/28/2008 1:00 AM | |
Joined: 10/7/2005 Last visit: 9/1/2024 Posts: 3018 Rating:
|
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 |
|
This contribution was helpful to
2 thankful Users |
10/29/2008 8:45 AM | |
Joined: 10/7/2005 Last visit: 9/1/2024 Posts: 3018 Rating:
|
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 AMCheers |
|
10/30/2008 1:15 PM | |
Posts: 24 Rating:
|
Thanks for all your comments. |
9/17/2015 11:58 AM | |
Joined: 9/1/2005 Last visit: 8/12/2024 Posts: 4104 Rating:
|
New question published by eamonnatwork is split to a separate thread with the subject STEP-7 -- IEC61131-3 Certification (second thread). Best regards |
My Forum is the place to personalize your profile, |
|
Follow us on