Scaling wizard-interval mode

[rln401165]

I have a DAQ about the unit/count variable in the unit definition section of the scaling wizard. I have them working and they seem to be accurate. But the method I used to determine the Count/Unit variable was trial and error and with no understanding of what the variable represents in the real world.
What I read seems to say that the unit=the time selected in the unit time base, hours minutes, seconds or milliseconds and the counts=the number of input pulses or counts received within the selected time frame. If I’m wrong about this then I am hopelessly lost. But if I’m right then how do I determine the Count/Unit variable when the count changes with velocity change?
Here is what’s contained in the physical environment and scaling settings.
PNP proximity with one pulse=10.2 inches
One revolution=8 pulses (81.6 in.)
Line speed=0-250 FPM
Count/Unit=1.14
Time base=minutes
Scale offset=0

[BobO]

Truthfully, the Interval scale really shouldn't use Counts / Unit, and yeah, that's confusing.

Some background: While developing the CTRIO, we used a CTRIO prototype in ADC's race car as part of a telemetry system to display car stats. We were having problems with the wheel and crankshaft counts coming in too slow to get good data at a fast rate. So I came up with the idea of computing RPM and MPH from the pulse time, rather that pulse count. So I added Free Run and the Interval scale to turn a precision timer into an accurate rate computation. The Interval scale was nothing but the Rate scale, but with inverted math. It worked so well that we decided to make it a standard feature of the module...although apparently I never changed the unit terminology. Fun.

It's actually pretty simple. Starting from the basic y = mx + b scale function, we have a scale term (m) and an offset (b). For both Rate and Interval scaling, the m term is what you are getting from the Counts / Unit field. The b term is Scale Offset. Since we are starting with time (in us) in the Interval scale, which will get divided into the microseconds per unit time to produce events per time unit, the m term is applied to the raw time prior to normalizing. After normalizing, we add the b term.

In your case you are looking for feet per minute, and your pulse is 10.2 inches, or 1.1765 pulses per foot...pulses being our 'count' and feet being the 'unit'. As an example, if the line was running at 250FPM, you would be seeing 250 feet * 1.1765 pulses/foot or 294.12 pulses per minute...which translates into 204,000 microseconds per pulse. Reversing the math, 60,000,000 us/min / (204,000 us/pulse * 1.1765 pulses/foot) = 250 feet/min. Maybe. If I did the math right...

[rln401165]

Thanks BobO
I've got it now, I don't know why I didn't see it before. May be I'm just getting to old. I started off in the trade in 1966 and I'm 70 now and mostly control was relay logic for me until the 1980's and even then PLC control systems were too expensive for most of my clients, not to mention plant maintenance personnel resisting change to something they did not and cared not to understand.
But the change did come and now thanks to companies like Host Engineering and Automation Direct are affordable. Now, if a control system has 3 or more relays for logic my first thought is a PLC.
Thanks for the support.
Ron   

[BobO]

You're doing great Ron. I'm 49, an automation professional my entire career, I wrote the CTRIO...and it confuses me too.