02-13-2006 11:16 AM
02-13-2006 01:59 PM
02-15-2006 05:30 AM
02-15-2006 09:40 AM
Hi Antonio,
I agree with Alan - it might help to see your code to see if there is a better way to do your measurement.
How often do you need to measure the speed up the laser using the encoder? Once per second, once per millisecond, or as often as possible? If you need to measure the speed and produce a new output every once in a while, then you may be able to throw away some samples. With DAQmx you can do this by setting your OverWrite mode to "Overwrite Unread Samples" using the Read Property Node. An even better way solution is to slow down your acquisition rate somehow so that additional samples do not fill up your buffer.
It is possible that a buffered (continuous) acquisition is not the best way to control your laser. This is because when you read samples from a buffered acquisition, you are not reading the current value. Instead you are reading a value that may have been captured a while ago (depending on your acquisition speed and how far you are behind). Also, it sounds like you want to measure just one sample of your laser speed during every iteration of your control loop.
For control loops I usually recommend the Hardware Timed Single Point (HWTSP) timing mode with fixed sample clock signal. To use HWTSP, change your task timing from "Continuous" to "Hardware Timed Single Point". Another possibility is to use software timing (to use software timing, simply don't use the DAQmx Timing VI) and control your loop rate using a LabVIEW timer. Keep in mind that with either of these mechanisms you are still going to need to slow down your sample rate so your control loop can keep up. If you are using Microsoft Windows, you will see a lot of jitter due to the operating system so you may need to reduce your rate by a lot. Expect to be able to keep up at somewhere between 2 and 1000 samples a second, depending on the jitter of your system. If you are using a LabVIEW Real-Time system, then you should be able to keep up at a fairly quick rate (perhaps more than 10000 samples per second).
02-15-2006 11:21 AM
-200141 is specifically a counter overflow (kErrorCounterOverflow) and corresponds to a gate error. Your encoder output is connected to PFI9? Encoder signals are often noisy. Noise on the line could cause this error.
To see if you are using DMA to transfer data from ctr0 to your application, examine the Data Transfer Mechanism. It's on the channel property node under Counter Input: General Properties: More: Advanced:Data Transfer and Memory:Data Transfer Mechanism. You appear to have two timed tasks on that board. Most DAQ boards have three DMA channels and both your tasks would use DMA by default. Some boards only have one DMA channel. If you have only one, force your AI task to use interrupts by setting its Data Transfer Mechanism. You are only taking 90 points and that will fit entirely in the board's fifo so the transfer mechanism isn't very important there.
02-20-2006 12:19 PM