6533 delay trigger
in [LabView]
|
Prev: CRIO web page does not update
Next: How do I read the channel numbers using a 34970A DAQ with the34908A MUX in Labview
From: jjohannsen on 21 Dec 2007 15:10 Jaime, Thanks for reviewing this. The only difference I can see in the example vs. my code appear to be "Finite" vs. "Continuous". Could this be causing a problem with the external clocking? Did I miss any differences? If I set the sample mode to Finite, and set the buffer size to greater than the expected # of samples for one cycle, will this work the same way as setting to Continuous as it is now? Keep in mind I am stopping and starting the task every cycle, with approx 3000 samples being received over a 30+ second cycle. Stopping and starting the task (with "DAQmx Start Task" and "DAQmx Stop Task" VIs) will reset the buffer, correct? To find velocity, I just post-process the recorded angles and CAN message timestamps. Then do a Vel = [Angle(x + 1) - Angle(x)] / [Time(x+1) - Time (x)] calculation where x is index of array. Thanks, Jason
From: jjohannsen on 26 Dec 2007 17:10 Hani, I am starting the tasks at the start of each cycle, reading the buffers later on during the test, when power is applied and the CAN device starts transmitting messages, and stopping the tasks at the end of each cycle. I can specify the # of samples to read at the DAQmx Read VI even when set to continuous acquisition, correct? Then the Read VI will only take as long as it needs to read out that # of samples from the buffer? i.e. if the buffer size is 1000, there are 350 samples in the buffer, and I set the Read VI to read 350 samples, there should be no wait time? I read all available CAN messages, and the corresponding digital input samples, every 100 ms or so, in order to keep the CAN buffer from overflowing (max buffer size of around 75 messages with my configuration and both ports being used). I have attached the portion of code I use to do this. My question now is, using "continuous" sample mode, and having the buffer size manually set to 1000 samples, could this cause a problem with "re-sizing" the buffer as more samples are placed into it, and old samples are shifted out once 1000 samples have been collected and read? I expect around 3000 messages and corresponding digital input readings for each test, so would setting the buffer size to ~4000 samples solve this issue (if it actually is a problem)? Or would I need to set the mode to finite to truly stop any "re-allocation" of memory. Or am I totally in the wrong place to be looking. Thanks, Jason Read buffers.vi: http://forums.ni.com/attachments/ni/170/292068/1/Read buffers.vi
From: jjohannsen on 27 Dec 2007 09:10
The encoder has a 10 KHz update rate. It is a parallel output gray coded binary 14-bit encoder. It has 14 individual 5 V TTL outputs to the 6533. The encoder outputs do not have a frequency, they just turn on or off depending on the angle. I take each encoder measurement from the 6533 and convert it from gray code to a decimal value, then convert to degrees by dividing by 16384 and multiplying by 360. There will be a new encoder reading for every CAN message since the CAN card triggers the timer card, which then triggers the 6533 after 5 ms. RTSI (PXI bus) triggers are used. Please check the above VI that contains the configuration VIs. Thanks Jason |