Counter/Timer
Issues with Counter on 9411
Solved!
Hi Ricus,
I'm actually still using LV 2011 so can't view your VI (if you post a screenshot or VI saved for 2011 I can take a look).
From the method you described, the VI itself should probably look something like this (you'll want the 3 second interval to be clocked somehow in hardware if you aren't doing this already, the PFI filter would be helpful if the input signal is noisy):
If this is in fact a torque sensor (does it output pulses at a frequency proportional to torque or something like that? a link would be helpful) the shape of your curve might not be so unusual depending on the type of motor you are characterizing:
@Ricus wrote:
What I would like it to do is measure the number of edges over a 3 second interval so that I can divide by the number of pulses/revolution*60*1/3 to get rpm.
If the sensor outputs a fixed number of pulses per revolution then this would work, but then it wouldn't be measuring torque.
Best Regards,
Ahh ok, that makes more sense--it seemed like a weird way to report back a measured torque but now I understand that your torque sensor also measures RPM via this speed pickup option and this is what you are asking about (I didn't see how many pulses/rev the sensor is on the Honeywell website though, do you know offhand?).
The software-timed 3 seconds is going to introduce a good deal of variability to your measurement but wouldn't explain the strong negative correlation between RPM and output frequency of the speed sensor (we're talking several ms of non-determinism for a 3 second window). Eventually you'll want to fix this as well but it's not your primary issue right now (as an aside--it would actually be more accurate to measure the frequency of the encoder signal using the 80 MHz timebase as a reference and averaging the result over a 3 second window, the general idea is sort of explained in the 9188 manual here, but I'm digressing).
I think it's more likely that the signal from the speed sensor is a bit noisy (pretty typical for optical encoders) and during transitions the 9411 is picking up multiple edges. A slower RPM equates to longer transitions and thus more false edges. This is just a hunch though, but it's what I can think of off the top of my head that might be causing what you're seeing (If the number of pulses read back is higher than what you would expect given the pulses/rev of the sensor across all RPM ranges than this would support my theory). If you want to ignore the measurement method for a second and try to fix the noise issue (assuming there is one), you can add the following property node to your existing code before you start the task:
You can start by setting MinPulseWidth to 6.4us (which is one of the built-in clock divisors available for the PFI filters on the 9188). You want the MinPulseWidth to be short enough to guarantee detection of a legitimate pulse but long enough to block out any false edges that occur during transitions.
Best Regards,
