piece per min calc

[strner]

hello, i am trying to come up with the logic for calculating a running pieces per min from the output of a PE to use as feedback to the system. any help will be appreciated. using logix5000 btw.

 

[drbitboy]

PE = Photo-Eye?

May we assume the data are debounced rising edges then?

How long between rising edges would be considered "rate is 0?"

What is a typical rate? 1 part per minute? 10? 0.1?

Over how long a period, or over how many parts, do you want to filter the value? Over how long a period do you want to calculate the value?

E.g. you could divide the number of milliseconds between successive rising edges into 60000, that would amount to a filter of 1 part, so 1500ms between the rising edges of two parts would be a rate of 40 parts/minute.

Or you could count the number of parts, pop the oldest value (FFU) and push (FFL) that newest count from a .Length=60 FIFO once per second, and the difference would be the parts/minute; that would be a 60s filter, with a new rate estimate every 1s.

 

[parky]

It depends on what sort of ppm some examples are measure the time between parts, varies too quickly for some applications, one of the best I have done & seen is count the parts over say 6 seconds, put them in a shift register array of 10 then simple maths for parts per minute, this then gives you a curve from starting to normal speed & back down again.
in other words add the 10 samples so assume 12 parts per 6 seconds, times 10 = 120 ppm.
Many prefer this to instantaneous speed as it gives a sort of running average for small stoppages or slow downs.

 

[strner]

yes triggered from rising edge on PE. the rate can vary from 0 to 100 or so per minute. this will be used in a feedback loop to smooth the output from spiking. essentially a three stage choke. something like less than 50 per min> no choke 75 per min> half choke 100 per min full choke. it will need to be a running actual number and not average. And will need updated every few seconds.

 

[Steve Bailey]

How accurately do you need to display the speed?

For example, if you count parts over 30 seconds and the actual rate is 100 parts per minute you can reasonably expect an accumulated count of 49, 50, or 51 which gives per minute rates of 98, 100, or 102. Counting over a shorter increment means you multiply a plus or minus one count variance by a larger number.

Another alternative is to track the time between successive pulses from the photoeye, but that only works if the parts are all the same size and the distance between them doesn't vary. It also depends on how accurately you can measure time in your PLC. The scan time becomes a factor unless you can get the photoeye to trigger an interrupt.

 

[strner]

the accuracy doesnt have to be extremely accurate. this will be used to control the output rate on a conveyor divert. the pieces vary in size and distance apart. but it will need to update quickly as pieces are moving nearly 600 fpm. this is more brute force smoothing than precise accurate control.

 

[drbitboy]

have a CTU of rising edges with a preset of 5, and it's counter.DN bit resets itself (after the falling edge e.g. [XIC counter.DN XIO photo_eye RES counter]).

at 100part/minute or more it will take less than 3s to count to 5.

at 75part/minute or more it will take less than 4s to count to 5.

less than 75part/minute it will take 4s or more to count to 5.



Have two TONs: ton075 with a .Preset of 4s and and ton100 with a .Preset of 3s, both running when [XIO counter.DN] (you might need something else to ensure the timer restarts on the rising edge of the counter.DN, and does not have to wait until it goes back to 0 e.g. [BST XIO counter.DN NXB counter.CU BND TON ...]?).

Every time it counts to 5 i.e. every time counter.DN is 1

• XIC counter.DN
  • BST XIO ton100.DN OTE full_choke
  • NXB XIO full_choke XIO ton075.DN OTE half_choke
  • BND

Obviously you can play with the count and times, and put in some hysteresis (Start/Stop ladder logic pattern), so if does toggle full choke because of noise near 100ppm.

this could also be done with a single timer with a very long .Preset, and then you check the .Accumulator value when counter.DN is 1; implementing hysteresis around the break points might be easier this way; or .Accumulator value could be linear with %choke.

 

[cwal61]

hello, i am trying to come up with the logic for calculating a running pieces per min from the output of a PE to use as feedback to the system. any help will be appreciated. using logix5000 btw.

Rung1. One shot your PE to an OTE
Rung2. XIC of OTE Mov Timer.ACC into DINT Then Divide 60000 by DINT and store result in your PPM DINT.
Rung3. XIO of OTE Run Timer.

 

[drbitboy]

Rung1. One shot your PE to an OTE
Rung2. XIC of OTE Mov Timer.ACC into DINT Then Divide 60000 by DINT and store result in your PPM DINT.
Rung3. XIO of OTE Run Timer.

As noted earlier, there is no filter there, so it will be a bit noisy, especially with real data. But yeah, pretty simple:

 

[JTCat]

This begs the question;

Average PPM over a duration of time? Or Running PPM? Or Parts per the previous minute?

Or all 3?

 

[drbitboy]

This begs the question ...

See posts #6, 4; also #2 two where that question was first asked. The one-sample-per-estimate (non-)filter approach suggested in posts #2, and implemented in posts #8 and #9, may be a bit severe, as noted.

The approach suggested in post #7 would update every five parts (3-6s or so), but the parameters could be tweaked to suit, as noted.