AB Black-belt – Siemens Virgin – Siemens Timer Choices

20 years plus with AB PLC programming. PLC2, PLC5, ML1400, Compact Logix, Control Logix. Small machines, up to multi-station assembly lines for just-in-time manufacturing.
New project, 8 machines for a European corporate, but US based manufacturer. Enter Siemens.
Project size about 400 digital, 40 analog I/O. (x 8 machines)
Our intent was to execute established, functioning ladder code (AB) in the alternate Siemens PLC platform. Good news, AB UDT author, pleased Siemens UDT capable. Bad news, need to go to Siemens school.
Bad news, can’t get started. RE: Timers
I think we have three choices with Siemens timers:
1. S5 style timers
2. Hybrid AB emulated timers via custom STL function calls
3. IEC FB Timers
I have been reading all PLC related forums, and am surprised about all of the strong opinions and experiences programming simple PLC timers.
Customer requires us to learn last gasp of Step 7, does not want to migrate to TIA Portal (yet).
Simple request:
What timer platform should we adopt? (This project Step 7, next project TIA Portal?)
2. Hybrid AB emulated
3. S7 IEC FB timers
Checking the Siemens Website, there is ALWAYS an example of one timer, we need an example of one hundred timers with DB or UDT discipline. We do not want a symbol table massively populated with individual like elements.
Thank you, my peers for helping us to join and support the Siemens platform, and be International programming capable.
Plastic

i would suggest IEC timer. they are far easier to understand and use, are not limited in number (only by available memory) and unlike s5 timers can count up to 42 days or somethnig, while s5 can count up to 2 and something hours.

IEC timers are quite similar to AB as i understood. they don't have timer timing bit.
PT i ET are TIME in/out in ms as DWORD

IEC timers in step7, not TIA, are called as SFB but i don't know exact numbers.
there are TON, TOF, TP variation, but not quite sure for their retentive counterparts.

Absolutely go for the IEC timers.
They are as balash said very similar to ABs timers.

Checking the Siemens Website, there is ALWAYS an example of one timer, we need an example of one hundred timers with DB or UDT discipline. We do not want a symbol table massively populated with individual like elements.

Click to expand...

You should learn to program FBs with the IEC timers embedded into the instance-DB of the FB.
This tecnique is called "multiple instance".
It is quite simple really.
Search for "multiple instance IEC timer".

+1 IEC timers.

If your need for accuracy is high, yes IEC.

If you don't need more accuracy than 100-200ms then count clock pulses. Math is often faster and easier than timers.

inalvor1 said:

If your need for accuracy is high, yes IEC.

If you don't need more accuracy than 100-200ms then count clock pulses. Math is often faster and easier than timers.

Click to expand...

Hello,could you kindly point out which IEC block is working for this, I had some problem with clock pulses which effect a lot by the PLC scan time.Thanks advance.

hill831017 said:

Hello,could you kindly point out which IEC block is working for this, I had some problem with clock pulses which effect a lot by the PLC scan time.Thanks advance.

Click to expand...

I'm sorry that confused me abit.

As for IEC, just use SFB4-5. (In a 300 system)

As for clock pulses, just counting positive flanks on 100ms works pretty well.


Another way of getting a decent measurement over longer periods:
Store current Date&Time in seconds, then do a regular compare vs the stored data. If current - stored = target seconds +- compare interval, then trigger.


*Stands ready to be corrected by a proper expert*

*Stands ready to be corrected by a proper expert*

Click to expand...

I don't consider myself an expert but...

I see no reason to use a counter, but each to their own.

I would always try to use an IEC timer for the purpose of 'timing'.

Your counter is always going to have a potential 100ms error depending on the flank rising edge being 'high' at the correct point in the scan and could be even worse if the scan time peaks over 100mS so the pulse time is basically extended.

If your process is simple and not time sensitive then sure, a counter would be work just fine but why not use the tools provided

cjd1965 said:

I don't consider myself an expert but...

I see no reason to use a counter, but each to their own.

I would always try to use an IEC timer for the purpose of 'timing'.

Your counter is always going to have a potential 100ms error depending on the flank rising edge being 'high' at the correct point in the scan and could be even worse if the scan time peaks over 100mS so the pulse time is basically extended.

If your process is simple and not time sensitive then sure, a counter would be work just fine but why not use the tools provided

Click to expand...

As you said.

But I'd still give adding pulses to registers a little bit more merit. It is very seldom I see a process needing timing down to a scancycle of accuracy and numbers are so much easier to work with than calling fb's.

inalvor1 said:

As you said.

But I'd still give adding pulses to registers a little bit more merit. It is very seldom I see a process needing timing down to a scancycle of accuracy and numbers are so much easier to work with than calling fb's.

Click to expand...

Sorry for my poor understanding, So I would like to use an example to review this topic.

Under my standard, I use pulse memory bit generate all necessay pulse,tact(100ms,200ms,1s...).
Then in the FB we use (for example 100ms) to count delay for the output.

My problem - I have a system with more than 100 drive, and big profinet network - arround 200+ deivce.Scan time of PLC is 45-55ms.
Some place I need stop delay, but under this scan time every time part stop on different place. After optimize scan time lower than 50ms, then part mostly stop on rigt postion.

So I guess it's should more or less relate with scan time and pulse which I use. It seems not like following equation when scan time is above 50ms.

Part Stop distance 30mm = 0.6mm/s*(100ms*5(Setting from IDB)+Communication delay(could be ignor))

Real stop different can be 30-80mm, which means it may cause by miss counting 100ms by each 100ms.

if scantime is long maybe to use interrupt to stop part?

To use counters instead of proper timers is something you would do in the old S5 days, when you were running out of timers because the CPU only had maybe 32 regular timers.
Today, I dont see any good reason to use counters as timers.

hill831017, what CPU are you using ? edit: Exact type no please. 6ES7 ???-???-????
(and next time, start a new thread).

Even if you'd use IEC timers that can be accurate down to 1ms(but not faster than the scan cycle), your scancycle time & bus update time will limit how fast your signals are anyway.

Instead of waiting until the scan cycle completes to update I/O area, force updates by putting/getting data directly into/from PI/PQ area.

Other suggestions would be to speed up scan times:

Put all code that's not very time critical into OB that updates every 500ms, so the rest updates faster. This will still lead to some scans being longer though.

Split code into several CPUs.


(I guess I presumed you already use the fastest 400 and ProfinetI/O)

JesperMP said:

To use counters instead of proper timers is something you would do in the old S5 days, when you were running out of timers because the CPU only had maybe 32 regular timers.
Today, I dont see any good reason to use counters as timers.

Click to expand...

I'm sorry, but I have to verify.

When I count, it's "time:=time+increment;" on an INT or DINT, does this still count as a counter?

Because I find that the build-in "S_CUD", "S_CU", "S_CD" are rather useless.



Then again, I'm sitting and playing with a S5-100U 103CPU at office atm...

inalvor1 said:

When I count, it's "time:=time+increment;" on an INT or DINT, does this still count as a counter?..

Click to expand...

To me yes.
I dont mean the archaic S5 counters.
What I mean is the difference between using the standard, and programming ones own function. One shall have some compelling reason in order to deviate from the standard.