RSLogix 5000 Pulse timer (high, low, high) bit

[ebolbol]

If any of you wizards can help in this I would be ever more grateful.

We have this device that generates 9 second pulses coming into a DI module as a bool value. 1=high 0=low. I'm in a situation where I need to time the pulse duration in it's high bit state (9sec) as well as low for a total of 18secs. to be defined as one complete cycle. Graphic attached. I've tried different things and have come close, but haven't found the magic simple route.

Thank you and have a nice day.

 

[joseph_e2]

How accurate does it need to be?
Since you're using RSLogix 5000, I would set up a periodic task with a short enough period to be accurate enough. If you need it to be +/- 100ms, set your period to 50ms or a bit less.

On every scan check for a high input. On the first scan it's high, zero out a tag. On every subsequent scan, add the task interval to the tag. The next time it goes high, store the tag's value into another tag and zero it again.


If you want to do it all in the main periodic task, you can have a TON instruction continuously running with a PRE that's a lot higher than you expect to see (or at a value where you'd set a fault or something). Every rising edge of the input will grab the timer ACC and store it into a tag before resetting the timer. Your accuracy will be less than with a periodic task by up to a scan time.


I've never done it, but some 5000 inputs can be configured to throw a hardware interrupt. You can use that interrupt to grab the system time on each rising edge and subtract the previous recorded time.

 

[widelto]

Use two timers. one for high Timer_HIGH (9 seconds) one for low Timer_LOW(9 seconds).
You start Timer_High initially and the when this timer ends , it will start timer_LOW
You can use .TT bits to turn on and off your digital output.
You also must provide some logic in order to start or stop if needed.

 

[ebolbol]

How accurate does it need to be?
Since you're using RSLogix 5000, I would set up a periodic task with a short enough period to be accurate enough. If you need it to be +/- 100ms, set your period to 50ms or a bit less.

On every scan check for a high input. On the first scan it's high, zero out a tag. On every subsequent scan, add the task interval to the tag. The next time it goes high, store the tag's value into another tag and zero it again.


If you want to do it all in the main periodic task, you can have a TON instruction continuously running with a PRE that's a lot higher than you expect to see (or at a value where you'd set a fault or something). Every rising edge of the input will grab the timer ACC and store it into a tag before resetting the timer. Your accuracy will be less than with a periodic task by up to a scan time.


I've never done it, but some 5000 inputs can be configured to throw a hardware interrupt. You can use that interrupt to grab the system time on each rising edge and subtract the previous recorded time.

I just need it to resemble 18 seconds to the human eye, don't need it super accurate. I have to display this timer on the HMI. So when you're looking at it, you will see a timer counting up to 18, and zeroing and starting over.

 

[ebolbol]

Use two timers. one for high Timer_HIGH (9 seconds) one for low Timer_LOW(9 seconds).
You start Timer_High initially and the when this timer ends , it will start timer_LOW
You can use .TT bits to turn on and off your digital output.
You also must provide some logic in order to start or stop if needed.

The problem is, this is not a fixed duration. The process is set to this duration now, if adjustments are made in the field, that duration can change, this is exactly why we need this, to see from it's baseline setting of 9 and 9, monitor any change in the field.

 

[plvlce]

I just need it to resemble 18 seconds to the human eye

The problem is, this is not a fixed duration.

So which is it? First you say you need a timer for a specific time (18s) then you say you don't want a fixed duration.

Don't expect detailed help when you don't supply a consistent explanation of your goal.

If the goal is to provide a timer showing how long the pulse is, then specifying how long the timer will run is counterproductive -- it will run as long as the pulse takes.

Simply getting a cycle time for your device is trivial and can be done in quite a few ways, for example simply run an unconditional timer and then reset it using a oneshot capturing the rising edge of the input.

Depending on what sort of problems are expected, capturing both the high and low durations might be more useful; that's not what you've asked for though.

 

[widelto]

To change timer duration is just matter of changing timers .pre data. It can be done thru HMI.

 

[Aardwizz]

To change timer duration is just matter of changing timers .pre data. It can be done thru HMI.

You're going down the wrong path. The OP wants to time the duration of the pulse, not trigger a .DN bit when time is up.

A timer can be used, just make the .PRE "infinite" (2147483647) and perhaps use an RTO instead of a TON so that the .ACC value is still there when the pulse is "done" so it can be captured and moved to an HMI tag.

Because this feels like a student exercise, I'm leaving out how to manage the RES of the RTO along with a few other details to the reader.

 

[5618]

I'm probably missing something on branch syntax in this pseudo code (NXB for Next Branch). Have a free running timer. When input turns on, oneshot reset the timer. Show the timer accumulated value on the HMI. I also thought about capturing and displaying the on duration for that cycle while input is off (XIO Input MOV .ACC) and also the previous cycle values. You might not care about that. You probably want to do something else when the pulse device is not running. OnTime, PrevCycleTime, PrevOnTime, & PrevOffTime are DINTs.

XIC Input ONS MOV Timer.ACC PrevCycleTime NXB MOV OnTime PrevOnTime NXB SUB PrevCycleTime PrevOnTime PrevOffTime NXB RES Timer

XIO (Input) ONS MOV Timer.ACC OnTime

When Input turns on, capture previous cycle values and reset the timer. When Input turns off, capture current cycle on time.

 

[widelto]

@Aardwizz: Sorry you are right.
In order to count time. I Would would use RTC and catch uSec value or SEC value when pulse train goes from low a high or vice versa. With two values you get the difference that is low or high pulse duration.

I could even try to use an Event Task to get pulse duration, this way is more sophisticated.

Aardwizz, Thanks for let me know.

 

[ebolbol]

So which is it? First you say you need a timer for a specific time (18s) then you say you don't want a fixed duration.

Don't expect detailed help when you don't supply a consistent explanation of your goal.

If the goal is to provide a timer showing how long the pulse is, then specifying how long the timer will run is counterproductive -- it will run as long as the pulse takes.

Simply getting a cycle time for your device is trivial and can be done in quite a few ways, for example simply run an unconditional timer and then reset it using a oneshot capturing the rising edge of the input.

Depending on what sort of problems are expected, capturing both the high and low durations might be more useful; that's not what you've asked for though.

@plvlce

I just didn't want to give you a huge back story and drown the main point in 5 paragraphs. Bottom line is we want the 18 and any operator that fiddles with adjustments and the duration goes up or down, I want to be able to graphically display that to let us know it's been messed with.

There used to be a battery operated device counting cycles and its behavior was an led would blink at the rising edge of an initial pulse and the next time it would blink was 18 seconds later, spending 9 sec's each at hi and lo and that 18 secs was displayed on a little LCD screen. Messing with the flow, would change that duration.

Trouble ism when the battery would die, we would get a no flow condition. I got a proximity switch now watching that process and am trying to replicate that devices behavior and instead of the LCD, display it on the PV600 display.

sorry for not being concise enough.

 

[drbitboy]

Here is a minimal approach using RSLogix 500 (Micro Starter Lite; see LAD 3 MEASURPULS on the right; the rest is for simulation and testing). RSLogix 5000 would be similar, although the timers could count to 2Ms+ (two billion milliseconds).

This code shows

• F8:1 - the last total cycle time i.e. the elapsed time between the last two rising edges, s, float;
• F8:0 - the elapsed time into the current cycle i.e. since the last rising edge of the pulse, s, float;
• N9:1 - the elapsed time of the pulse signal being high during the current cycle, ms, integer;
• N9:2 - the elapsed time of the pulse signal being low during the current cycle, ms, integer;
• the state of the pulse (1=high; 0=low).

Those values could be displayed in an HMI; other values and/or quantities and/or units could also be calculated and displayed e.g. a bar chart of the last 10-20 cycle times.

Caveat

The time values are not exact as they lose a scan cycle here and there, but as that is only a few ms out of several seconds, I suspect that is acceptable.
​

 

[TheWaterboy]

So do you really care about the 18 seconds or just that the heartbeat pulse keeps changing? Its dead simple to monitor a heartbeat pulse if all you are looking for is a sign of life. We just need to know how important that 18 seconds really is.

 

[Steve Bailey]

you will see a timer counting up to 18, and zeroing and starting over.

A simple timer reset by the low-to-high transition of the pulse signal. Set the preset greater than 18 seconds and display the accumulated value on the HMI. If you want to display the time remaining instead of elapsed time, subtract the accumulated time from 18 seconds.

 

[ebolbol]

You're going down the wrong path. The OP wants to time the duration of the pulse, not trigger a .DN bit when time is up.

A timer can be used, just make the .PRE "infinite" (2147483647) and perhaps use an RTO instead of a TON so that the .ACC value is still there when the pulse is "done" so it can be captured and moved to an HMI tag.

Because this feels like a student exercise, I'm leaving out how to manage the RES of the RTO along with a few other details to the reader.

I tried something similar to this, but having a hard time telling the PLC what I want the end of a cycle is to restart the timer. I tried using a CTU to count the high bit and after two, RES, but not giving me what I need.