Rev/minutes.

[Wile E Coyote 0]

Has anyone got a neat little programme that works as a rev counter or product per minute accurately? I need to display a "Envelopes per Minute" on an HMI but I need it to be accurate. I have proxies where a pulse per revolution can be used. I have an Omron Cam Positioner module which gives 60 pulses per revolution. I have tried timers and counters and the "SPD" utility, not accurate enough. Can anyone assist? Thanks in advance. What I need to add is that I need to count up to 1500/minute. Thanks again Edited 21 Apr 2007 by Wile E Coyote

[Crossbow 297]

What PLC are you using? The options vary by the family. I've done something similar with a high speed counter. We had a system where we needed to totalize water flow. The flow meter gave us a configurable number of pulses per gallon (we set it to 10), so we got a pulse for every tenth of a gallon. Then in the PLC I had a numerical value of the number of pulses it had received. This was on a Q Series, so I set it up in a periodic pulse count mode where it gave me the total number of pulses once per second. Then I subtracted my previous reading, and had that second's usage. Sum of 60 of those, I had usage per minute. Then further to sum hours, days, and months. How do you know an envelope went by? You mention proxes and a pulse output cam. What are you trying to totalize off of?

[waynes 8]

What about using the spd funtion to count the amount of pulses per second. This will give you an "instantaneous" reading. Otherwise, count the amount of pulses over 5 seconds and convert it to pulses/ envelopes per minute.

[Wile E Coyote 0]

I am using the SPD function at the moment. The problem is you have to multiply it by something to get to minutes. That makes it inaccurate by whatever you multiply it if it changes by 1 on the SPD calc. Originally from Durban myself. Thanks for the reply.

[Colin Carpenter 10]

>>I don't have a high speed counter in the system. Would I need one for these kind of speeds?<< Depends on the cycle scan time of the PLC. General rule is that if the pulse duration is shorter than the scan time, then there will be times when a pulse "happens" during the scan time between refreshes, and the pulse will be missed. If you are looking to count 1500 pulses per minute, then this equates to 40 ms per pulse, but, the pulses have to go on and off in that time, so assuming the on and off times are equal, then, as long as your scan time is less than 20 ms, you should be OK. It is possible with IEC Developer to interrogate the PLC for its current max and min scan times, (and presumably also with GX Developer) In the past, if I've had to do high speed counting for several inputs and I'm concerned about the main PLC's ability to see all the pulses, I've often installed a small FX (cheap as chips on E-Bay) and used the multiple high speed counter options on the FX to count the pulses, then give a slower, longer pulse to the main PLC every time (say) 10 pulses has been counted. The FX range is really good at this. Regarding working out the speed, the longer you let the PLC analyse the pulses, the more accurate it will become. For example, if you're counting something that is generally giving 10 pulses per second, but sometimes 9 and sometimes 11, then the scaled up value (per minute) will be 540, 600 or 660, which is a big difference. However, if you write some simple code to count the pulses for 1 minute, then display that value, then the inaccuracy is only 1 part in 600, in other words, very accurate. Just experiment with moving counter values to data registers, resetting the counters and doing a bit of subtraction.

[Crossbow 297]

You don't need to multiply it to calcuate value, simply add several reading together to come up with reading over a time base. Like speed readings every 10 seconds, then add 6 readings to get a minute.

[waynes 8]

By using the spd function over 5 seconds you would be able to display an instantaneous speed throughput. If you do use Colin or Crossbow's methods, it would be delayed, either by 10 seconds or a minute. It all depends what you want. I like Crossbow's idea.

[KenE 0]

What is the prox pulse length? It could be that at full speed the prox is only on for microseconds, or a small number of milliseconds. Mitsu has a fast general purpose input card (good to 0.1ms I believe). You have to configure it to get the faster response. If that is not enough you will have to go with a high speed counter card for looking at really fast signals, or add a device that has built in "off-delay" or a device that generates a 10-20ms off delay. If you have access to an oscilloscope you should look at the prox "on-time" at the full operating speed. Depending on the flag that signals your prox, you can extend it to cover up to 50% of your revolution (i.e. the prox is detecting for 180 degrees of the shaft rotation, giving it a 20ms on-time at full speed). If your input signal is too fast for your Input card you will never get an accurate number, especially at higher speeds. That, and scan time can burn you.