RT Analog Input with Ext Sample Clock

[byronb]

I am trying to update an RT vi (LV 7.1/Traditional DAQ) to LV 2011/DAQmx.  Our application requires synchronized multi-device AI, AO and pulse counting driven by an external clock at a user specified frequency.  We use a PXI system: 1031 Chassis, 8175 Controller, 6608 System Timing card (Dev1) and two 6052E DAQ cards (Dev2 & 3).  The PXI system is updated to the current versions of LabVIEW and DAQmx and is properly configured in MAX (as far as I know).

As a first step, I've tried to write a simple AI acquisition loop driven by an external sample clock (see AI 0.vi in attached folder).  In this case, I'm using Dev1/Cntr1 as the AI sample clock on Dev 2.  I've assigned the remote vi (AI 0.vi) time critical priority and removed any front panel indicators.  I've used a local vi (Display AI Darta.vi) running on the Windows 7 PC to monitor the remote vi.

The remote vi runs but behaves strangely.  I'm assuming DAQmx Read.vi will pause the loop until a rising edge on the sample clock, then a single sample will be read and the loop will execute normally, returning to the wait state at the Read vi on the next iteration.  However, the loop counter increments by 2 for each data point.  I added some code to compute the actual loop frequency, which always shows 1/2 the frequency of the AI sample clock.  (This is true if you observe the data with the local vi across the network or if you add indicators to the remote vi front panel.)  It appears loop only executes on alternate triggers (but the loop counter updates properly).  This has me completely confused.

Note:  The Init SIM Counters.vi is a sub-vi to set up the various clocks required by our application.  It seems to work fine.  I've used an oscilloscope to verify the AI Sample clock (Dev1/Cntr1) is generating a square wave at the desired frequency.  Other counters configured in this sub-vi are not relevant to this test.

Eventually I'll need to extend this vi to include synchronized AI / AO and pulse counting across the three devices...  But fist I need to understand why a simple AI loop doesn't work as expected.

[Anthony_F]

Bryonb,

What operating system is on the PXI?  You mentioned it was a real time VI, are you deploting it on a real time system? Can you give me more information about your real time setup?

There seems to be a lot going on with your files you uploaded, can you reduce it to a minimal set of code and VIs so we can help you better?  I am also missing a dependency in the project explorer called DMS-APIMS, can you describe what this is?

Another bit of helpful information would be to have a screenshot of the data that's monitoring those variables.  (Is the data not changing, is it reading twice on the same point, etc)

[byronb]

Yes, we're using an RT controller in a PXI chassis.  There's a screenshot of the MAX setup in the attached folder.  Software was updated recently to LV 2011 and NI-DAQmx 9.3.5.  DMS-APIMS is just the name of our PXI system.

I've created a simplified version of the vi that illustrates the strange behavior (AI 0c.vi), eliminating the network variables and clock initialization sub-vi.  In this version I'm using the Dev2 6052E hardware only.  The AI sample clock is set up on the block diagram and configured from the front panel as Dev2/Cntr0 and a 2 Hz square wave.  I've included screenshots of the block diagram and front panel in run and stopped mode.  My oscilloscope verifys that the Dev2/Cntr0 is indeed producing a 2 Hz continuous pulse train. The vi is only attempting to read one sample from one channel (Dev2/AI0) at a frequency of 2 Hz.

At 2 Hz the loop is slow enough to follow the action.  When the vi runs, the loop counter indicator increments by 2 rather than 1 and the "Acutal Frequency" indicator reads "inf".  When the vi is stopped, the "Actual Frequency" indicator reads 1, which I assume was the last value.  I'm not sure why it won't display properly in run mode.  Using network variables and a separate vi to read the data the Acutal Frequency data displays correctly.  In either case, the computed loop frequency is always 1/2 the expected frequency (Sample Clock frequency).  So, it appears the code in the loop code is executing and indicators are updating only every other iteration but the loop counter is somehow incrementing correctly.  I don't understand this at all and wonder if there is some bug relating to the new verison of DAQmx or some incompatability with our hardware, which is admittedly old.

[Jesse_D]

Good morning byronb, 

I was thinking that this was just a programming issue so I ran your program on a USB 5353. It behaved as it should, that is, I didn't see the behavior you were seeing with loop increments of two and infinite frequencies. 

I still would bet that it is a programming issue but I don't know what is wrong off the top of my head. It sounds like it is reading one sample right after another then waiting almost an entire clock cycle to read another two. That would account for the loop increments of two and infinite frequencies.

What happens if you set the read to read say 10 samples? This should divide your actual freqency by 10. 

[byronb]

Jesse,

Very interesting.  When I modify the vi for N Samples, it works fine.  Attached are screen shots of the front panel for the RT vi running on the remote system at 2 Hz and 20 Hz.  The computed frequency is 1/10 the Sample Clock frequency, as expected, and the loop counter increments by 1 with no problem.  The issue seems restricted to a 1 sample read.  (I've tried 1 sample N channel, which also produces the error.)  Does this point to a bug in the 1 sample read vi???  Is it possible there's something about our old 8175 controller that is incompatible with a 1 sample read???

I should note it was a struggle to update the controller with new software.  This controller can only be formatted successfully with a version 7.1 PXI Format Disk floppy.  However, once the controller disk was formatted with the old floppy, the software upgrade with the new version of MAX seemed to go smoothly and the test panels seem to work fine.

I'm also getting a message about a missing serial.dll library on the controller whenever I connect, but I'm assuming this is not related.

Byron

[Jesse_D]

Got it! Can't believe I didn't remember this before but daqmx reads a minimum of two samples, which explains why n-samples works well for you.  I will track down some more documentation and post why this works a little later later in the day

[byronb]

This seems a bit surprising to me...  If you can't read less than 2 samples, what are the 1 Sample 1 Channel and 1 Sample N Channel instances of the DAQmx Read vi for??  Are these instances imcompatible with an external sample clock??  I don't need 2 samples per channel and may run into a problem passing the data from the remote system vi with a network variable - I don't think the network variables support a 2D double array number type.

In any case, I decided to try out a bit more complex AI loop with multiple channels on two devices, taking 2 samples per channel rather than 1.  I tried synchronized and sequential acqusition (AI 2.vi & AI 2b.vi, see attached files).  This is a more realistic version of the analog input I need in the working vi.  Both versions run, but halt on a buffer error (-200279, see screenshot jpg) after 12 seconds or so, regardless of the loop frequency or size of the buffer specified in the Timing / Sample Clock vi.  Am I overlooking something here??  Sorry for the multiple problems.

Byron

[Jesse_D]

It has to do with the minimum 32bit dma transfer, as referenced on this thread. A single sample is only 16 bit usually, so you have to wait for two to read them. I have run into this problem before in c. You can get around it by enabling interupts instead of using dma transfers. I also recall rumors of a propery node that would pad the extra 16 bits but I would have to go track it down. I have drawn a little diagram of what is going on, you shouldn't run into problems with this as the actual data acquisition is hardware timed. 

The single read just reads data from the software buffer into some array in the application memory. The transfer from the board to the software buffer is taken care of behind the scenes by daqmx, usually by dma. The daqmx read vi never actually talks to the daq board.

You buffer error is saying that you need read data more frequently, I would change your samples read to -1.

The topic is a little confusing, I will post a diagram tomorrow.  

[byronb]

I must admit I'm becoming discouraged.  The old vi ran on this hardware without problems for years with legacy DAQ drivers and LV 7.1.  The legacy AI Single Scan.vi node waits for a rising edge on the scan clock and had no problem taking one sample from a group of channels.  Loop timing was controlled by the AI scan clock, set to a user selected frequency.  If I understand you correctly, this sort of functionality is either impossible or very difficult with DAQmx.  Setting the samples per channel parameter to -1 destroys loop timing in the multi-device vi posted above; the loop runs away at 500 Hz, ignoring the sample clock...

Please let me know if there's a way to get around the dma transfer limitations or pad the bits.

[Jesse_D]

Good morning byronb, 

I have made a diagram of what is going on: 

The daq board is collecting data into the FIFO buffer. It collects data using an on board clock (or external clock) to get high precision data. However, it doesn't transfer the data into memory until there is 32bits worth. The daq board fifo buffer is small, so data must be transfered quickly from it. DMA tranfer allows data to be transfered to memory much quicker than possible with other methods. This data transfer happens automatically and is transparent to the user. 

The daqmx read transfers data from the daqmx software buffer, which is located in computer ram, to the labview application memory, which is also in ram. The read.vi never actually sees the fifo buffer on the daq board. 

However, despite this your program is working properly. The FPGA on the data board is collecting data just like you thought it was, it just doesn't transfer the data out of the FIFO buffer and into the daqmx software buffer until there are two samples. From your labview program's perspective there are no samples to read until two suddenly are put there by the dma transfer. This is the behavior you were seeing with your earlier benchmarking program.  

I should have posted this diagram much earlier in our conversation, I am sorry for any confusion it has caused you. 

As for syncronization, it is controlled by hardware also. The daqmx driver takes care of routing a clock between two devices so they can syncronize data collection. The way you use the Read.vi will not affect the actual data collection.

Does this explanation clear things up?