Siemens S7 Indirect Addressing

[L D[AR2P#0.0]]

S5/IEC timers - how do you use an IEC timer in a function (FC) that is called many times ? IEC timers are the perfect choice for FB's, but for FC's I pass the timer number and value in as parameters and thus I have re-usable FC's.

 

[Ken M]

And just how many times can they be re-used exactly?
The actual number of S5 timers in an S7 CPU is ridiculously inadequate. You buy a CPU with x-squillion megabytes of memory and you get, what, 256 timers or something like that. (OK, hyperbole, I know.) You can use them all up just doing debouncing of contacts!

Ken

 

[Nick B]

I agree with Ken and much prefer the Multi-Instance model. It's far easier to troubleshoot for the "average" user. The limited number of S5 timers can be a problem but they are designed for another purpose in life.


Nick

 

[L D[AR2P#0.0]]

Ken - by re-usable I mean that once I have written the FC, I can put it my library and re-use it - not only on one project, but also on future projects. As you point out though, the number of available timers can be limiting. The CPU's I've used (317/8) have 512 timers available.

 

[S7Guy]

My S7 processors also have 512 timers, and that has been enough so far even though I have worked with very large control systems. I allocate them like this:

I have a DB with an array of 512 bools. On startup, I rip through all of the components that are enabled in my code, and "hand off" available timers. I "check off" the ones that I use in my DB, and pass an int value to the component that represents the timer. This way, none of my timers are ever dedicated for a particular purpose, and it's unlikely that I will ever run out of any. This has worked well so far.

 

[MaxRoberts22]

I tried to enter an IEC timer in my motor UDT, but that wouldn't work. What is the variable declaration type you used when creating your UDT (e.g. SFB4)?

 

[Ken M]

Yes indeed, SFB4 should be the correct data type for the declaration. Do you have a copy of SFB4 present in your offline project? Although these are automatically present in each CPU, a new offline project will be empty and start by assuming nothing. Drag a copy of SFB4 from the library in to your project's blocks folder and hopefully (!) when you then reference that as a data type STEP7 will understand what you mean.

On second thoughts, where were you trying to declare it? This should be in the STAT variables section of your parent FB.

What exactly "wouldn't work"? Were you able to declare it but the timer wouldn't work, or couldn't you declare it all, or ...

Ken

 

[L D[AR2P#0.0]]

He's trying to declare SFB4 as part of his UDT. This is not possible in Step 7

One possible alternative is to create another UDT which mimics SFB4's interface e.g.

TYPE UDT 2
VERSION : 0.1

  STRUCT  
   SFB4In : BOOL ; 
   SFB4PT : TIME ; 
   SFB4Q : BOOL ; 
   SFB4ET : TIME ; 
   SFB4STATE : BYTE ; 
   SFB4ETIME : TIME ; 
   SFB4ATIME : TIME ; 
  END_STRUCT ; 
END_TYPE

and include this in your motor UDT definition. You could then access SFB4's parameters via the UDT names. To call SFB4 you would have to set AR2 to point to the base address of the UDT for each "instance" of the timer, set the instance DB numer to the DB in which the UDT is being used, and then use UC SFB4 to call SFB4

 

[MaxRoberts22]

Well there goes my nice, neat package!

I've been able to create an FC for my motor logic and DB for my motor data (the DB contains four instances of my motor UDT). My FC has an IN/OUT parameter for UDT varaibles. This is my method of "indirect addressing" for each motor instance.

My goal was to keep my motor logic in an FC and my motor data in a DB, but these timers are making life miserable.

I'd like to keep my timers in my UDTs so I don't need to use an FB with STAT variables for timers. I'm not doing any elaborate timing, so technically an S5Timer would work, but so many speak so lowly of them. Using S5Timers would allow me to keep my approach narrowed down to an FC and a DB. I understand the concept of using a separate "IEC-like" FC block for timing, but I'd also like to limit my block nesting.

Again, maybe I ask the impossible.

 

[L D[AR2P#0.0]]

Use s5timers in your udts - use SFB4 everywhere else.

 

[MaxRoberts22]

Well, I put one of those damn S5Timers in my UDT and that worked. When I tried to use it in my FC, S7 gave me a "Compiler Information: type confict." error.

I'm attaching a picture of what the setup looks like. I declare my UDT, being passed into the FC, as an IN/OUT parameter. As you can see in network 23, I have no problem tunneling down into the UDT and assigning paramter addresses. But it won't accept the address for the S5Timer in network 22, which is clearly available and visible in the declaration area.

(EDIT: Okay, I can't add the picture, but I'll keep trying.)

 

[Ken M]

I think this qualifies as 'my bad' as my friends in the colonies might say.

I didn't read the question and just gave the answer that fitted in with my way of working regardless - I assumed it was in an FB not a UDT. Apologies.

I still don't understand Max's almost pathological aversion to FBs. They're there to be used just as much as FCs are. FB-ophobia is a dreadful thing - once it gets a grip you'll spend the rest of your life manipulating pointers and shuffling data here and there.

I think we'll have to agree to disagree!

Regards

Ken

 

[MaxRoberts22]

Every problem has a solution; I simply find myself in a "sticky wicket" as our gents across the pond might so eloquently say.

I hold no aversion, strong or weak, to the use of FBs. I can clearly see their usefulness in many situations. I trying to maintain simplicity here. The original solutions provided by others involved the use of pointers and true indirect addressing. The idea proposed to declare and UDT IN/OUT parameter really is the best; it uses one FC for logic and one DB for storing global data.

I might remind you that we in the "colonies" are more keen to use Allen Bradley and thus RSLogix 5000 products. While I would understand the use of pointers and muli-instance DBs, the people in charge of maintaining the system might not. So by finding the simplest solution up front, I save myself the headache of the 2 AM support call because the guy on the other end cannot understand statement list.

 

[L D[AR2P#0.0]]

A TIMER is not a data type and so hence cannot be included in a UDT, s5time is a data type and can. You can use an integer to store the timer number in the UDT and then you will have to reference the timer indirectly in your FC.

(For reference, if you wanted to use an indirectly addressed timer and view the logic in ladder mode, this would be possible inside an FB. Pass the timer into the FB as a parameter [but leave it blank in the call to the FB], then modify the parameter value dynamically by writing any timer number you want into the static data area associated with the timer parameter.)

 

[JesperMP]

Back again from some time at the beach.

I am the guilty party when it comes to the confusion about UDTs and IEC timers. I suggested to declare IEC timers in UDTs, but as L D[etc. etc.] states it is not possible. It seems that in UDTs you can only declare basic data types and other UDTs, No FBs or SFBs.
I jumped to thinking that you can do the same with UDTs that you can with FBs.
Sorry for the confusion.

I remember now that back when I started to figure out which 'concept' I should use with S7 I ran into the abovementioned problems with UDTs.
In the end I decided to go with a concept of using multiple instance within my standard FBs, and then use single instance for each call of these FBs.

There is the other possibility with UDTs to define your own timer standard with a selfdeclared UDT, not an FB. Drawback is that this timer will not be a standard timer type.

About the number of timers available. My projects have typically between 50 and 200 'objects', and each object needs 5-20 timers each. So if I used S5Timers I would run out of them very quickly.