Find duration of a high pulse by plc

Hi
I want to calculate the time duration of a high pulse in milliseconds in ST language.It would be very helpful if I get the proper suggestion. Thanks!

Which PLC??

I would say that if you launch an infinite timer when your start condition happens and read the elapsed time when the signal goes negative you achieved it.

Beckhoff PLC. Could you please let me know how can I use That in ST

No. What you want is for me to do the work for you. Give it a try, post where you got stuck and me or someone else will surely step in to help you. Not do the work for you.

I wrote the code. WHich is like
IF NOT Out THEN
Timer1(IN:=NOT Out, PT:= T#4S);
Out:=Timer1.Q;

END_IF
IF Out THEN
OUT:= FALSE;
Timer2(IN:= NOT Out, PT:= T#10S);
IF NOT OUT AND In THEN
Duration:=Timer2.ET;


Sir I think you do not understand me. I only ask what would be the infinite timer as an example. I did not get any infinite timer in Beckhoff or ST.
Thanks!

I am not sure what is your goal with those timers but are you looking something like this?

Timer1(IN:=NOT Timer2.Q ,PT:=T#4S); //TON timer
Timer2(IN:=Timer1.Q ,PT:=T#10S); //TOF timer
Duration:=Timer2.ET;

Thanks a lot . I am looking something like this.

I usually avoid the Timer functions in ST since they look cryptic, though I have used in FBD where they look nicer. I find it more direct and readable to just count PLC cycles. You zero the counter to start, count, then save the value when stopped. Something like:

IF flgStart Then i:=0; flgStart := False; END_IF
i:=i+1;
IF flgStop Then ElapsedTime :=i * Tcycle; flgStop := False; END_IF

Don't use literally, I typed this ST from thin air and don't use it often.

You might hard-code the PLC cycle time if you can assure what it will be, or better to read the current setting via a TwinCAT function. 1 ms is the default setting, but you could set to 0.05 msec for highest resolution.

You might also use functions like GetSystemTime or GetCPUTime (recall). I have used both and don't recall a difference in performance. I recall they return <<1 ms resolution, but there may be a slight transfer time.

Are you sure that your PLC can handle timers in ms. I'm not familiar with Beckhoff, but on lot PLCs you can define time in ms, but PLC can't handle less than 10ms or even 100ms.

goghie said:

Are you sure that your PLC can handle timers in ms. I'm not familiar with Beckhoff, but on lot PLCs you can define time in ms, but PLC can't handle less than 10ms or even 100ms.

Click to expand...

Off course it depends used cpu but for example Beckhoff CX10xx series minium cycle time is 50 microseconds and therefore i believe that timer can do the same.

Mara said:

Off course it depends used cpu but for example Beckhoff CX10xx series minium cycle time is 50 microseconds and therefore i believe that timer can do the same.

Click to expand...

I can't remember PLC with cycle time more than 1ms, but again it is very rare to find PLCs that can handle timers that last less than 1ms. Also could you put that "high speed" timer in normal scan and be sure that it will be precise, and on other side if you put it in fixed scan, then you will change normal scan period. And at the end why would you normally need that fast timer, when your inputs and outputs have longer latency?

Good point, since piash didn't mention what CPU he is using. The higher-end Beckhoff CPU's like CX1020, CX2020 can run 0.05 ms cycle time (w/ reasonable amount of PLC code and I/O). I usually run them at 0.1 ms cycle since fast enough for the A/D rate of most analog modules (10 kSps). I ran timing tests on a CX5010 (Atom CPU) and found it exact at 1 ms cycle, but lagged proportionately at faster cycle times, so don't exceed 1 ms for critical timing tasks. For reference, I recall the lags were ~0.05% at 0.1 ms cycle. I ran these tests against a high-speed data recording system, with the PLC toggling a digital output each cycle. I recall the BX series processors (ASIC, non-Windows) can't run faster than 10 ms, which is typical of common A-B and Siemens PLC's. Years ago, I tested a CX1000 (now obsolete) at 1 ms cycle and found it lagged 30 ppm, which is near PC clock spec's, but still unexpected. At 10 ms cycle, it was exact.

Re the fastest PLC's, I looked at Beckhoff's EtherCAT and B&R Automation's Ethernet Powerlink in 2005 because they were the only PLC's which could respond to an analog input with a digital output in <2 ms. I had a strong internal push to use A-B if at all possible, since my boss claimed "industry standard". We tested a Control-logix w/ fast A/D module. I recall we could get it down to ~4 ms, but only with a few analog channels. I also noticed National Instrument's ads for their "fast" CompactRIO, but they gave no specs. I am glad I chose EtherCAT since it became widespread. Years later, NI gave specs at a seminar saying CompactRIO could read analog at 1000 Sps for 4 channels, or 100 Sps for all channels (10 ms updates), using their built-in functions. I commented, "that isn't what we call 'fast'". They said one might do better by writing custom FPGA code, but that seemed a daunting task. NI adopted EtherCAT for their Compact module expansion chassis. I think B&R is still the only competitor to Beckhoff for high-speed PLC's. BTW, A-B salesmen have made the most absurd claims to me about Beckhoff, saying it can't be real-time since "it runs in Windows" (not true), so process such comments appropriately.

You can store the TIME in a variable and after the pulse do a subtraction of the newtime.
This is the fastest you can get inside a PLC.
If you n

something like oldtime:=TIME;
newtime:=TIME;
elapsed:=newtime-oldtime;
timeused:=TIME_TO_INT(eleapsed);

This is a job for a FPGA. Back in the dark ages Intel made an 8253 chip that would do the job.
http://www.alldatasheet.com/datasheet-pdf/pdf/66098/INTEL/8253.html
Its amazing this is still a problem 30+ years later.
It may be possible to do this with an extremely fast PLC but the PLC would need to be able to generate interrupts on rising and falling edges and can't be delayed by having the interrupts off during house keeping time.

In PLC land the word timer is a misnomer. What you guys call timers should relay be called delay blocks. I think the OP's problem points out why.