Rotation Speed vs Time measurement - measuring 0.

[cbutcher]

---

@Kevin_Price wrote:

Two quick followup thoughts:

1.  maybe it'll be convenient to stop and restart the task at the Freq ~= 0 point?  Then you could query system time for t0 right when you restart.  That might help avoid managing a boolean flag across a producer/consumer boundary.

2. I think your device supports a frequency measurement mode that lets you use a constant-rate sample clock.  I've not yet had occasion to dabble with this mode however, so I can't say much on whether it's helpful for your case or any nuances of how it behaves for Freq ~= 0.

-Kevin P

---

1 - This is a good alternative, but would currently require manual intervention to restart the measurement once the rotation resumed. That's not disastrous because currently the motor requires manual intervention (via dial) to set the speed, so a person needs to be present anyway and once the motor is successfully connected to LabVIEW presumably the start command can be used to trigger a new frequency measurement start. However, I'd prefer to avoid it if possible since it allows for more user (i.e. my!) error along the lines of, "I started the motor, but forgot to go and press the restart freq.meas button, so we don't have any data for that set of experiments" or similar.

2 - Yes, I thought I'd seen this too. I previously struggled to find an appropriate way to get a clock to the DAQmx Timing node (it wants an external clock) but today I went ahead and set up a function generator to provide said external clock to a PFI terminal, since that was simpler than trying to run around triggering AI Sample Clocks or similar.

It looks as though there's a specific error corresponding to "The sample clock received multiple pulses before the source" or something - essentially a timeout but with a different number. The suggested error is jitter in the clock source, but if there are no pulses I guess this will happen regardless. It might be possible to use this error in place of a timeout error, but I suppose the handling would be the same either way.

[Kevin_Price]

1.  I'm unclear why a Stop and re- Start couldn't fit into your architecture.  You've got the task ref for the Read, why not just conditionally Stop & re- Start (while refreshing a t0 timestamp) when you get the timeout error?   You don't need to completely clear or reconfigure the task, just Stop and Start with the existing task ref.

2. I didn't realize that the constant rate freq measurement mode required an external clock, like I said I haven't really used it myself.

   The error is probably one related to a property known as "Duplicate Count Prevention."   Normal counter operation has a fast timebase coming into the counter's Source input, causing the count register to increment +1 per active edge.  In a normal buffered measurement, a slower "sample clock" signal comes into the counter's Gate input, causing the instantaneous count register value to be sampled and put in the task buffer.

  It's *abnormal* to have 2 successive "sample clock" edges with no "timebase" edges in between.  This typically results in the error msg you probably saw.  On most newer boards (like yours) you can probably suppress that error by setting the "Duplicate Count Prevention" property.  (Not sure whether it needs to be True or False, but you can quickly figure it out by experiment.)

   Note however that I'm not sure what kind of *data* you'll get in this constant-rate Freq sampling mode.  It might report the most recent valid measurement, or I could imagine it might report 0, Inf, or NaN.  (Due to raw measurement of 0 freq edges that interval, possibly followed by 1/x treatment in the driver.)

-Kevin P

[cbutcher]

Thanks again for your replies.

With regards point 1, it's certainly possible but I think I either earlier or now (or both times) misunderstood you.

Earlier, I thought you meant that the task should stop on a timeout, and then be started again once data was valid - my concern was without measuring, I would need to restart manually.

Now, I read your idea as more that I should immediately (or thereabouts) restart the task, and if it again hits a timeout then just restart over and over. I expect that wasn't exactly what you meant but I'll try reread a few more times and glean the real idea.

For point 2, thank you for the explanation. I'll have a look for the property you mentioned - perhaps working with it will allow the sample rate measurements to work more readily. 

[Kevin_Price]

1. Yeah,  I was thinking about restarting over and over.   With a pure read timeout error, I think you could just clear the error and not need to stop/start the task.  This would be the more likely error in a "regular" Freq measurement using Implicit timing.   The other error you get in constant-rate sampling mode (from consecutive sample clocks with no encoder edges) *would* require stop/start.

2. You can find the property deeply nested under a DAQmx Channel property node at:

Counter Input->General Properties->More->Advanced->Duplicate Count Prevention

Note: while searching for past posts on this, I saw some indication that X-series boards may not allow this property to be set False.   Again, I can't speak to the implications on a constant-rate sampling Freq measurement task.   You may need to use regular Freq measurement using Implicit timing, and then ignore/clear the often-expected timeout errors you can get when motionless.

-Kevin P