Timer in a FC Step7

[dahnuguy]

I have a FC in which I am running a timer.

The timer does not time down as it does if I put it in OB1.

What am I doing wrong here?

For this example to work , would it need to be in a FB or possibly included in the STAT area of the containing FB?

 

[ArikBY]

You need to use IEC timer SFB4 .

 

[krk]

Change your #OUT_PULSE to an IN_OUT type and use that in network 1 as the NC contact to run the timer.

 

[PeterW]

Depending on the type of data used at the call to the FC, an FC will sometimes remember the last status of an IN parameter or an OUT parameter on the next call.

Sometimes it does not.

It is good practice, if you require to remember the internal status of an external memory area, to program that data as an IN_OUT parameter.

In theory, an IN will update on the block call and will not update on exit.

An OUT will not update from the external memory on entry and will therefore contain indeterminate data. Once conditioned in the block will update the external memory on block exit.

An IN_OUT will update on entry and on exit.

LAR will tell you when it does and does not, myself, I prefer to always use an IN_OUT if I need to read back the last state because even if I program it with data types that do remember, I have no control over any future modification.

 

[Ken M]

I know it's a small addition to PeterW's points but since you're in the early learning phase with Step7/S7 I think it's important to be clear on minute details.

An FC will never "remember" (in the sense of being a deliberate action) values from a previous call.

What happens is that every time an FC is called, the S7 operating system allocates an amount of memory sufficient to hold all the input parameters, in_out parameters, out parameters and temp variables. The OS makes no attempt to control the values in this piece of memory. When the FC has completed execution that set of memory bytes are now freed by the OS for allocation to the next task that requires it. The OS still makes no no attempt to affect the values in the piece of memory.

If it so happens that a few microseconds before your FC was called that same corner of a RAM chip was being used by an FB or OB or another FC then there could be residual values left there. You can't ever assume what's going to be there at that instant, but you do have total control over what's going on inside your FC.

As soon as the FC gets called the allocated memory assigned to formal input parameters will get overwritten by the actual parameter values. The same happens to the in_out memory space. This much is automatic. Nothing happens to the formal output parameter memory or the temp memory area at all: you control this. You can assign any initialising values to these areas in the very first network to ensure you know what you're starting from. Thereafter when you use these variables within the FC you are certain of consistent repeatable results. Finally on exit the output actual parameters and the in_out actual parameters get updated with the contents of the formal parameter memory. The memory space allocated to the FC is then released to the next guy.

This is absolutely vital understanding as you start tinkering under the hood. We've all been there and done it at some point with S7 and spent ages trying to work out why a function sometimes works, sometimes doesn't. That isn't the only reason (as if!) but it helps to know.

 

[dahnuguy]

Change your #OUT_PULSE to an IN_OUT type and use that in network 1 as the NC contact to run the timer.

Sounds right , but doesn't work.

 

[L D[AR2P#0.0]]

This is nothing to do with parameters being remembered between calls. In this example, the timer status has to be used before the SD instruction otherwise you will not see the pulse.

As the timer is passed as a parameter, you will not see the timer value changing inside the FC as opposed to a directly referenced timer where you will. The timer value can be read and loaded into a temp variable if you really want to see the timer value inside the FC.

krk's method does work (you still wont see the timer value inside the FC though), however, you cannot use a temp variable for the pulse with this method.

 

[dahnuguy]

parameter assignments

Ken,

I don't think any of that was "minute". Very solid explaination. The details are what makes such a disscussion worth having.

I have attached 2 screen shots. Keep in mind that nothing is changing in these shots.

It looks to me as if the assignment from OB1 is not being applied to the variables in the FC. Should they be?

This is a very simple FC , I am using this as a simple example for the purpose of exploring what is and is not possible with a FC.

To those of you who have alternative suggestions, thanks, but I have several ways to make a timer...............that's not the question.

If I try to make the "TIMER_NMBR" an "IN_OUT" variable, there is no "timer" type available.

And it should work as it is without trickery or relocation. Or should it?

So when OB1 calls FC1040 in this case, the "IN" variables TIME_IN and TIMER_NMBR are defined in OB1 and passed into FC1040. Correct?

If so then why does the timer not run?

If I am just too dense to get what your saying I apologize.

Image "timer block03" is the equivalent logic, it does work this way. As expected. But I want a FC that can be plopped down with a click and then the timer number and time entered. It seems a small thing , but if I can do this, then I will build on this for other more complex FCs. No use trying to figure out why a complex block wont work when a simple one will do.

I guess the basic question here is, how do I use assigned parameters from OB1 to assign parameters inside a FC?

 

[dahnuguy]

oops,

image 3

 

[L D[AR2P#0.0]]

See post#7 in case you missed it.

 

[dahnuguy]

This is nothing to do with parameters being remembered between calls. In this example, the timer status has to be used before the SD instruction otherwise you will not see the pulse.

But it works if the same 2 networks are used in a FB, the timer changes the state of the first bit in the second network.

As the timer is passed as a parameter, you will not see the timer value changing inside the FC as opposed to a directly referenced timer where you will.

Got it.

The timer value can be read and loaded into a temp variable if you really want to see the timer value inside the FC.

I'll do that just for testing.

krk's method does work (you still wont see the timer value inside the FC though), however, you cannot use a temp variable for the pulse with this method.

Ah ha...............

Could I also use a midline coil for the pulse and simplify it further?

 

[L D[AR2P#0.0]]

Yes - your pulse will be high for most of the time if use this method.

But it works if the same 2 networks are used in a FB, the timer changes the state of the first bit in the second network.

- what makes you think that it works ?

 

[L D[AR2P#0.0]]

If you use the timer before the SD, it will give a pulse, if you use it after, it will not:

 

[krk]

Sounds right , but doesn't work.

I wouldn't have posted it if it didn't work.

 

[dahnuguy]

Well then this is the main issue then.

It is the order of events that is stopping it from working.