S7 - Timer with variable times

I need to start a Timer following the use of a Module to inhibit its reuse for a period of time which is determined by the energy which has been used. This will vary from a maximum of 20 mins at the maximum 24 kV down to no delay under 1 kV. I've worked out a cooling curve, so I know approximately how long I need to delay for x kV, but what I'm looking for is more elegant way of loading the Timer than the Spaghetti method of:

Set-Point >= 24 kV T = 20 min, if so exit
SP > 23 kV T = 20 min, if so exit
SP > 22 kV T = 19 min...

and so on

I feel there must be some way of doing it that is efficient, but doesn't totally blow my KISS principles out of the water.

Any suggestions?

Roy, if the timer value can't really be calculated and is better served by some sort of lookup table (as yours seems to be), you might want to investigate the JUMP LIST instruction. I use it all the time and it saves a bunch of comparisons. You can set up a list of up to 255 jumps, and it will jump to a jump variable (i.e. M001) based on the value of a jump index. It's very useful, but not very many people use it.

Thanks S7Guy, don't know why I didn't think of that myself, I'm using JUMP LIST at least 3 or 4 times in other places.

One of those situations where once you start off in a particular direction, you put the blinkers on and stop looking at other possibilities!

Roy.

Maybe the previous solution is the right one for you, I just want to mention an alternative.

I am assuming that you are using IEC timers.
If you have a simple formula, then you can calculate the time setpoint with a formula using DINT math.
The setpoint is a TIME variable, but as it is really just the time counted in milliseconds, then it doesnt matter.
The trick is to do the math in STL in order to avoid the type checking in STEP7.

Roy

There is a single FC which I think should handle this. Take a look at FC103 in the STEP7 standard library TI-S7 Converting Functions. This is a look up table function. I've never actually used it in S7 myself (ahhh, now the truth emerges!) but I did have quite a bit of TI experience in years past. All of these FCs/FBs in this library are re-codings of what were standard instructions in TI, and I certainly used the CDT (Correlated Data Table) in TI. It worked a treat for situations exactly like this where you have a list of empirical values but no algorithm to relate them.

If I get some time I might experiment with it. It's always good to learn.

regards

Ken.

Hi Jesper,

In this case I'm thinking of using (after a lot of thought) S5 timers, mainly because they're down counting so that I can easily show the remaining time in ProTool. The cooling curves that I've calculated are extremely theoretical and will almost certainly change when we get the first module up and running and can take some measurements, so I'm using a lookup table for the different delays. I've dumped these delays in a DB so that I can easily modify them later, if necessary. The steps for the JUMP LIST are easily provided by taking the Voltage Setpoint and doing an INT divide by thousand giving me a 24 point List.

I was intending to use the word format rather than the S5T format, so that I know my time base is seconds - the only problem is that that only gives me a maximum delay time of 16,65 minutes, so I somehow need to cope with the remaining 3+ mins.

I don't think it is necessary to show the down count the whole time, starting at ten minutes to go would be more than adequate. What I can't decide from the manuals and help files is what timebase the DUAL output has - if I start the Timer with S5T#20M, do I get a count based on 10 sec timebase the whole way down, or what?

Ken, we were both busy typing at the same time, thanks for the suggestion, I'll go and have a look at that, although at present it's the lesser of my problems, the main problem being the display of time remaining.

I've just had a look at FC103 - I thought TI stuff was supposed to easy! Or is it just the Siemens implementation - I had to read that at least three times before I (think I) understood how it works.

At the moment I'm not sure if it would be a good idea to use this, I think it probably collides with my KISS philosophy. Since somebody else is going to have to look after this in future, once I'm long gone, I suspect the JUMP LIST solution might be more intuitive. Still, it's nice to know about it and I'll have a further look at it before making up my mind.

Thanks anyway Ken, as you say, it's always good to learn something new - and I've been doing a lot of that in the last few months since discovering :site: !

..if I start the Timer with S5T#20M, do I get a count based on 10 sec timebase the whole way down..

Click to expand...

Yes.
It won't switch to the finer graded timebases when the remainder of the time gets so small that, in principle, it could do so.

To get the remaining time with an IEC timer would only require you to subtract the .ET value from the .PT value. Again you will have to do it in STL.

I think I must be on about my fifth time round this loop, but especially when I take Ken's FC103 into account (KISS or no KISS - that just requires better documentation) I think I find myself heading back towards a down-counter triggered from a 1 sec Takt-Merker. If I'm not mistaken, it will make the display in ProTool simpler as well.

Decisions, decisions!

PS, STL is no problem, I'm quite happy there (SCL is another story!), but the customer wants as much as possible in FUP (where I'm also quite comfortable).

Oh come on Roy, where's your sense of adventure? FC103's not that bad. Admittedly, I have the advantage of knowing what it's supposed to be doing, from TI days.

It requires you to identify two tables of data: the IN_TBL and the OUT_TBL parameters. These may be in a data block or in two separate data blocks or wherever you choose. In your case, the IN_TBL will hold all your energy values in ascending order (sorry, but it does have to be ascending) and the OUT_TBL will hold all your corresponding timer values, one per energy value.

You then use the next two parameters IN and OUT to tell the FC where to get the input value (i.e. what energy value are we looking up) and where to place the output value (which timer value corresponds to that). The IN parameter uses a >= (greater than or equal to) relationship with the IN_TBL. So if you have three consecutive energy values specified of 22, 24 and 26, and feed in an input of 23 it will return the timer value corresponding to the 22 energy value.

The main difficulty may be that as the tables can be whatever length (and therefore resolution) you require, and they may consist of integers, reals, etc, all the parameters have to be specified as ANY-type pointers. Hey, that's not such a big deal, surely!

Good luck

Ken

OK

RMA I may be wayout in left field, but why couldn`t you just scale your kv to time 24 KV = 1200 seconds 1 KV = 0 seconds. And use your
scaled value as your preset for the delay. If your time is a function of KV

Hi Ken,

you won in the end!

The deciding factor was when it occurred to me that the JUMP LIST is all very well if I was just going to be doing this one time, but of course, I've got to do it 21 times - and that is REAL spaghetti - and no longer KISSable either!

It's too late to test it today, whether I'll get round to it tomorrow with my short Friday I'm not sure. But if it does work, it'll be quite neat, because the whole network for one Module fits on the screen in FBD (funnily enough this is one of the few times I've seen something take up more screen area in ladder than in FBD). So if I commecnt it properly it should still be fairly comprehenible to my successor (or me in 8 months time at final handover!).

Tracy H,

These are cooling off times, so in fact they are approximately proportional to the square of the voltage. Calculating that would also be no problem, however, the real problem is that these values are VERY theoretical. They are based on some figures which we got from the resistor manufacturer, but we have no information for the remaining components - capacitors, coils and fuses, we neither know how much they'll heat up nor how fast they will cool down again. So everything is going to be on a trial and error basis. What we finish up with will almost certainly be easier to handle as a look-up table, rather than trying to work out some appropriate formula.

Mmm! Turned out not to be quite as easy as I thought!

The main difficulty may be that as the tables can be whatever length (and therefore resolution) you require, and they may consist of integers, reals, etc, all the parameters have to be specified as ANY-type pointers. Hey, that's not such a big deal, surely!

Click to expand...

Do you mean by that that in my IN_TBL and OUT_TBL DBs although I'm working with INTs, I've still got to define them as being ANYs? If so that's probably one problem - I've read the help file at least three times and there's no mention anywhere of the Data Type in the DBs!

The second point is that in the example shown in the help file, they use a table with five values then they use following Pointers

P#DB1.DBX0.0 for IN_TBL
P#DB1.DBX100.0 for OUT_TBL
P#DB1.DBX200.0 for IN
P#DB1.DBX210.0 for OUT

now this is typical Siemens, are IN and OUT five words apart because of the five entries in the table, or is it, as I suspect, just an unfortunate choice of "random" Pointer addresses. After all you're only working with one value at any given time.

Now for the main problem, when I try to enter the Pointers even though I've switched off "Symbolic representation" in the view menu, after entering my "P#DB10.DBX0.0" and hitting RETURN twice, the entry immediately changes back to "Reuse Module Delay".Table_Length - or to be more precise, it disappears completely and you get the symbolic address up when you click on the box to edit it. This implies that it has change back to word addressing of the first Word, rather than being a Pointer. I've had this problem with disappearing entries before, but usually if you scroll the screen up and down they become visible again - not this time!

Any thoughts?

Roy

I don't know if I want to win! My opening gambit said

There is a single FC which I think should handle this.

Click to expand...

'Think', 'should' - these are pretty vague, general terms. It's more like a politician's promise than an engineering solution.

One disadvantage I've realised (oh, great, says Roy, now he tell's me!) is that the two tables have to be of the same datatype. You may have to do a little additional conversion coding to get your times in a suitable fashion. Using a catch-all of WORD for both the energy and the timer duration may be the KISSest answer.

I think I'll start a contest to see who can get the most 'think's, 'maybe's, 'perhaps's, 'might's and 'should's in a single answer. As I remember seeing on a sales brochure once "The large print giveth and the small print taketh away."

regards

Ken

Ooops, looks like our posts got overlapped.
I definitely started typing my excuses before you started typing your complaints!

Ken

PS : I haven't even tried this yet - it's all theory with me so far. And I guess that can sometimes be fatal with Siemens.