This should be very simple...

Question

using the usb 9171 chassis and a ni-9411 module and Labview 2012
I have one reflective optical reader wired to the 9411.
this is mounted to the side of a conveyor bed to detect boxes passing by
I've been trying to setup a VI to count the number of boxes that pass by the optical reader (that part is the easy part) but to also give me a gage that tells me boxes per minute (which could be as low as 1 box passes by per minute or up to 60 boxes per minute)
any help??

Answer 1

You could set up a frequency measurement task to do this.
The tricky part is that the read is a blocking call--it waits until you have a sample available which only happens when a box passes by (starting with the 2nd box, the frequency measurement is computed by inverting the time between consecutive boxes).  You don't want to be stuck inside the DAQmx Read call for up to 1 minute.  A few ways to go about this:
You can set the read timeout to some low value and discard the timeout error (-200284).  If you're using too much CPU you might need to add a wait to your loop in the timeout case (or maybe this is one of the rare times that setting the DAQmx Read Wait Mode to "Sleep" might actually help).
You could poll the available samples per channel property to see when to read, but unfortunately polling available samples per channel does not query the onboard FIFO or initiate a transfer back to the software buffer (last I checked), so you'll be reading "0" for quite some time until the on-board FIFO starts filling up, at which point a large chunk of data will be transferred back to the DAQmx buffer in PC memory at once.  Note that this does not apply to PCI/PCIe DAQ devices which transfer data to the PC buffer pretty much as soon as possible--USB and Ethernet devices try to minimize the overhead of unnecessary data transfers but in this case it is a hindrance.
Using the DAQmx Every N Samples event has the same problem as #2.
Reading -1 samples returns whatever is in the DAQmx buffer in PC memory, so it also has the same problem as #2 (the read will return 0 samples until the hardware decides to transfer the data over to the PC).
In your case, you might have luck with #2, #3, or #4 by setting the CI.DataXferReqCond to "Onboard Memory not Empty", but without being able to validate any of these workarounds I think I'm just going to recommend you use suggestion #1:
You can either run this task in addition to your current edge count task (there are 4 counters on the 9171 which should be plenty given you can only have 1 module), or you can run it instead of it (poll back the Total Samples per Channel and add 1 to determine the count of boxes, however you wouldn't be able to distinguish between 0 and 1 boxes this way since the first sample is returned after the 2nd box passes).
Best Regards,
John Passiak