Best practice for programming in Step 7

glnassaf

Member
Join Date
Dec 2008
Location
Rehovot
Posts
30
Hi,

Following a large project our company recently finished, I would like to ask what is the best method for object oriented programming.

We program based on S-88 standard.
We programed a unit (e.g. a reactor) using a FB with a single instance DB for eachof its instances.
Inside that FB we called other FBs as instances defined in the STAT of the units FB.

we had quite a few instances of exactly the same type of unit, so we used instances of the same FB class using different DBs for each instance, and entered the I/O in the INs/Outs of the units FB.

That way, any change, made to one of the FBs was included in all instances (exactly as object oriented programming should be...).

The problem occured when we wanted to add variables or simply alter the big instance DB's structure.
when downloading the SW to the PLC, all of the instance DBs Data was reset.

We found 2 alternatives for solving that problem:

1. using source generation to save the data of online DBs and insert it into the altered instance DB. This method turned to be very uncomfortable when you have dozens of DBs to change.

2. Adding "Spare" spaces in each of the FBs or UDTs used so the DBs structure won't change when adding new variables. Besides that, we created a mechanism that saved each of the DBs to a backup DB in runtime and once we changed the DB and downloaded it to the PLC, copying the backup DB back to the original so it will receive all of its data back. That is a good mechanism if you keep your DBs structure and not going out of the "spare" boundaries.

Both ways are bothersome and requires a lot of handling.

We used Siemens OPC so we were able to use symbolic addresses from the HMI.

Now I face a new big project with a few duplicated units and I wonder if there is a better way of using Step 7 to implement Object Oriented Programming without the hassle around the lost DB data.

I thought using an external DB (and not an instance DB) would be nice, but it seems it is not possible to pass a udt from one function's in/out to another.

Can someone share the best way to implement object oriented programming in step 7?

Thanks in advance,
Assaf
 
We use PCS7 eventually also with the Simatic BATCH option (S88 compliant).
In PCS7 you call your FBs from CFC (it looks very nice and tidy this way!), and there is a mechanism for readback from the instance DBs (I/O pins) back into the offline project in the engineering station. If you change an FB/Instance structure, you read back the online (pin) values first, then compile and download the new FB. Unfortunately the PLC must be in stop mode when downloading a changed instance structure.

Here is the PCS7 home page:
https://www.automation.siemens.com/...control-system-simatic-pcs-7.aspx?HTTPS=REDIR

Kalle
 
Dear Kalle,
Thanks for your reply.
Unfotunately we arent using PCS7 (in the current project we use standard WinCC 7.0) so using the CFC readback option isn't an option.
Even though, stopping the PLC sounds like something I would'nt like to do to the customer, every time I want to change the DB's structure.

I'll be happy to hear some more alternatives...

Regards,
Assaf
 
Thanks for your answer Nick.

I agree with you.
However, the question is how to use a standard DB and call multi instance functions.
As I mentioned, passing UDT from one function's IN/OUT to another is not possible.
How do you suggest dealing with that limitation?

Regards,
Assaf
 
As I mentioned, passing UDT from one function's IN/OUT to another is not possible.
How do you suggest dealing with that limitation?

A bit of DIY is required. Declare the UDT in the STAT area, copy the IN_OUT UDT to the STAT area, call the FB you want to pass the IN_OUT on to using the STAT variable. Copy the STAT variable back to the IN_OUT of the calling block. Cludgy, but it can be done. (FC1 in my example returns the size of the UDT in bytes)

asa.jpg
 
Yes, What LD said. I was looking for an example but only came up with an FC example. Think carefully whether you really need an FB and if you do use an FB think carefully what you place into static data, for example don't put configuration data in static data or, as you've noticed, it will get returned to default if you regenerate the instance data for any reason.

Something else to bear in mind when using UDTs is that if you pass a UDT to a function then there is a hidden penalty every time you access it because it has to be de-refferenced every time. To avoid this penalty, pass a pointer to the UDT and then copy it to local data, execute your function and then copy the local version of the UDT to the original location (as shown by LD and the FC example below).


Code:
FUNCTION FC 87 : VOID
TITLE =
VERSION : 0.1

VAR_INPUT
  pRunningData : ANY ; //Pointer to Running Data
END_VAR
VAR_OUTPUT
  iTransResult : INT ; //Result of Last transfer
END_VAR
VAR_TEMP
  pRunningPointer : ANY ; //Pointer to Running Data
  iTemp : INT ; //Temp
  wTemp : WORD ; //Temp
  bTemp : BOOL ; //Temp
  dwAreaPointer : DWORD ; 
  iDataBlockNumber : INT ; 
  iNumberOfElements : INT ; 
  iSize : INT ; 
  RecipeTemp : "T_Recipe"; //Recipe Data in temp memory
END_VAR
BEGIN
NETWORK
TITLE =
//Generate pointer to Running Data
      L     P##pRunningData; 
      LAR1  ; 
      LAR2  P##pRunningPointer; 
      L     D [AR1,P#6.0]; //Area pointer
      T     LD [AR2,P#6.0]; //Area pointer
      L     W [AR1,P#4.0]; //DB Number
      T     LW [AR2,P#4.0]; 
      L     W [AR1,P#2.0]; //Size
      T     LW [AR2,P#2.0]; 
      L     W [AR1,P#0.0]; //Type
      T     LW [AR2,P#0.0]; 
NETWORK
TITLE =
      CALL "BLKMOV" (
           SRCBLK                   := #pRunningPointer,
           RET_VAL                  := #iTemp,
           DSTBLK                   := #RecipeTemp);
      NOP   0; 
NETWORK
TITLE =
//Manipulate some data
      A(    ; 
      L     #RecipeTemp.Step0.rAmount; 
      L     1.000000e+000; 
      +R    ; 
      T     #RecipeTemp.Step0.rAmount; 
      AN    OV; 
      SAVE  ; 
      CLR   ; 
      A     BR; 
      )     ; 
      A(    ; 
      L     #RecipeTemp.Step0.rAmount; 
      L     1.000000e+004; 
      >R    ; 
      )     ; 
      JNB   _001; 
      L     0.000000e+000; 
      T     #RecipeTemp.Step0.rAmount; 
_001: NOP   0; 
NETWORK
TITLE =
      CALL "BLKMOV" (
           SRCBLK                   := #RecipeTemp,
           RET_VAL                  := #iTemp,
           DSTBLK                   := #pRunningPointer);
      NOP   0; 
NETWORK
TITLE =
//Set BR Bit
      SET   ; 
      SAVE  ; 
      CLR   ; 
END_FUNCTION

Nick
 
... Even though, stopping the PLC sounds like something I would'nt like to do to the customer, every time I want to change the DB's structure. ...

o_O try to increase the UDT-sizes and see what happens.


Back to best practice and PCS7: If you use SFC TYPES (instancable SFCs with I/O's) to structure your recipe data<>process interface, these can be altered and downloaded with the PLC in RUN mode.

(For info only, i have caught the point that you won't use it)

icon12.gif


Kalle
 
Thank you all for your replies!

Let me see if I get you straight.
1. I use a standard DB (not an instance DB) with UDTs as I wish.
2. I define the UDTs in the in/out of a FB.
3. I define all the parameters in the stat as well.
4. I copy the UDTs to the stat UDTs and then pass to the inner function.
5. I copy back the data from the stat UDTs to the in/out udts.

Did I understand correctly?

That's the best solution you think of (thats a lot of work!)?

Thanks,
Assaf
 
Thank you all for your replies!

Let me see if I get you straight.
1. I use a standard DB (not an instance DB) with UDTs as I wish.
2. I define the UDTs in the in/out of a FB.
3. I define all the parameters in the stat as well.
4. I copy the UDTs to the stat UDTs and then pass to the inner function.
5. I copy back the data from the stat UDTs to the in/out udts.

Did I understand correctly?

That's the best solution you think of (thats a lot of work!)?

Thanks,
Assaf

The solution posted is for passing UDT's on to another FB for further processing as you asked how to overcome this limitation. It is not related to your question about using Step7 for an OO solution.
 
I mentioned the way I used Step 7 for OOP and the limitations involved in it.
You suggested a workaround for the limitations.
If you have analternative for OOP using Step 7 I'll be happy to hear...

Regards,
Assaf
 

Similar Topics

hi al.. i am a bigginer to plc programming..ladder logic can anybody pls suggest the best programming practices using in industries..
Replies
21
Views
5,156
Out of interest, I'd like some thoughts on what would be considered best practice with regards to a 2-position turntable control scheme (see...
Replies
17
Views
1,031
Had a philosophical discussion with a colleague of a related discipline today and I want to get the opinion of the folks here. The most common...
Replies
5
Views
2,539
Hi, I am looking at the setting up some new ethernet comms which is originating from an SLC 5/05 to four new identical CompactLogix L24ER's...
Replies
6
Views
2,528
Hi! When using a PLC and HMI from different brands i have to write up every variable on the HMI end. Whats the best practice on this? Is it a...
Replies
2
Views
1,684
Back
Top Bottom