determine time between conveyor flights

This seems like it should be easy, but I can't seem to get it...


If I have a photocell that is blocked by material being dumped every time a conveyor flight comes by, how can I determine the length of time that elapses between the leading edge of the photocell being blocked and the leading edge of the next blockage of the photocell?

In other words... what is the frequency of the flights passing by a point?

thank you

In general, I would use a Counter and a Timer.

The Counter would count leading edge inputs, and would be set for a value of 2. It would self-reset when it got to a value of 2.

The Timer would measure how long the Counter was at a value of 0 or 1. This would be the period of time between the leading edges.

Once you have that time, you can divide or multiply or do whatever you wish to get a value of flights/minute, seconds/flight, flights/fortnight, or whatever expression of speed you want.

If you'd like actual examples, post some details about the PLC make and model you are using.

Actually, I think I was overcomplicating even that.

Use a timer that runs whenever the conveyor is running. Every time the Photoeye is triggered, grab the accumulated time from the timer and that's your time in betwen flights.

Try this. I use this for RPM but works the same for PPM. So this would give you the number of flights per Min.

absolutely! ...It took me a bit to see it even though you both explained it.


thank you both very much

is there system clock slc 5/03

is there a system clock on the slc 5/03 that could be "polled" by the photoswitch and the former value subtracted from the later value?

or control logix and micro logix etc.?

There is S:4 in the SLC that is kind of like a free-running clock. But it has very limited range and only has 20msec resolution. So that isn't a great option for you. In addition the control engine in the SLC doesn't handle integer rollover and subtraction across an integer boundary seamlessly like the C-Logix engine does. So I wouldn't try looking directly at time deltas with an SLC.

If you are using a ControlLogix or CompactLogix then looking at the time delta of the lower DINT in the Current Time array would be a good way to go. that value gives you microsecond resolution (within the bounds of your scan time), is a 32-bit quantity so it has decent range, and the CLX engine will take care of the math across the rollover boundary for you. If I were using a CLX family processor I would use the Current Time to determine delta.

Keith

You could use discreet io wired ms1 speed sensor on the tail spool of the conveyor to generate a pulse per rpm then through simple math get your lugs per minute into your rpm

well, I didn't really want to do any more than just time the piles of stuff coming off the flights so I would know when the photocell was blocked longer than one flight time ...

then I kinda got to thinking about timing stuff in general, and I realized that I didn't know whether or not the PLCs had a clock that could be accessed for timing. Seemed like something a rookie would know


thanks to everyone who responded.... as dense as I am, I have never come here without learning something, or left without a solution to my problem

sounds easy..

realolman said:

This seems like it should be easy, but I can't seem to get it...


If I have a photocell that is blocked by material being dumped every time a conveyor flight comes by, how can I determine the length of time that elapses between the leading edge of the photocell being blocked and the leading edge of the next blockage of the photocell?

In other words... what is the frequency of the flights passing by a point?

thank you

Click to expand...

I actually tried this, one boring night.
I had a BeltOnRollers conveyor, conveying fixed length boxes, guided at perfect right angle to the belt, with a retroreflective photoeye, as you describe.
The belt never changed speed, and there was always a good gap between boxes.
I expected that the time delay from the Rising Edge of the box to the Falling Edge of the box to remain the same.
The PLC was a lightly loaded CompactLogix 5000 (L32E), and I discovered that the variation in the timing made my boxes appear between 19 inches and 28 inches long.
The photo eye was "local I/O", and I was not writing functional logic for long term use, so I never attempted to fix it.
But, if I had, I would have generated an EVENT task, and likely used a DC Send-Receive PhotoEye.

you lost me with the 'generating an event task' ??

for what it's worth, the photoeye is a send receive fiber optic

19" to 28" seems like an accuracy that should be achievable with a calendar