SCXI-1600 Sample Clock Problem - Large Lag

[RVallieu]

I am attempting to use an SCXI-1600 to digitize and route signals from an SCXI-1540 LVDT module.  The system is an SCXI-1000 Chassis.  USB cable goes back to my dual core machine.

I am setting up a FINITE acquisition task in which I want:

* Four channels of LVDT - I have each one being added to the task with its own values, except that the measurement ranges must be the same.  I create a DAQmx task, then add the channels to it iteratively - this is giving me no errors.

*Sample clock driven by the AI Sample Clock input PFI7 which is the BNC connector on the front of the SCXI 1600. 

*Encoder with 2000 counter per rev drives the AI Sample clock input.

*DAQmx Read - want to Read N Channels, N Samples to return all 4 channels, but be able to specificy the number of reads in each return until I reach the Finite Acquisition NUmber of Samples to read.

I get no errors on this set-up.  The problem I am seeing is that the DAQmx read in my loops is not returning when it has acquired the specified number of reads set by the input "Samples per Channel".

In the instance where I specify that the Finite Acquisition is to read 4000 points, and the DAQmx Read is to return 5 Samples per Channel, the DAQmx read is returning after 38 collections of 5 samples, for a total of 190 points per channel ACTUALLY collected.

I EXPECT the DAQmx read to return 4 channels of 5 reads. 

I have done similar tasks and DAQ timing with external clocks on other projects - is the SCXI-1600 not able to handle this set-up?

[RVallieu]

I did a sanity check replacing MY SCXI system in my architecture with my PCI DAQ card and a Signal Accessory.

I left the same number of channels in the the task, left it set for Sample clock input from the encoder.  I mimiced my previous code exactly expect for using the PCI card, setting the sample clock source as a counter input and reading four channels of Analog Input.

The task worked perfectly as expected - it returned the number of samples requested (5) until the total number of points was acquired (4000) and then stopped the acquisition on its own.  The task only read when the encoder was spun by hand.

After that I changed conditional diagram disable back to my SCXI-1600 and SCXI-1540 hardware.

Something is up with using the SCXI-1600 and external clocks!! 

Why am I not able to perform an externally timed data acq as expected.  I just read through the SCXI-1600 manual and nothing indicates that this should be a problem.

[RVallieu]

No one has a clue?  Is there some minimum buffer for the SCXI-1600 DAQmx Read?

[PBear]

Hi Ryan,

Sorry about the functionality problems you are having. While I don't have an explicit answer for you now, I would like to see your code to make sure that I'm reading your post correct. I agree, using your encoder to generate the sample clock pulses and having DAQmx Read set to 5 should return five samples when they are available in the buffer. When you used the PCI DAQ device, where you still using the encoder on a PFI line or were you using a counter pulse train that you were generating. It sounds like you were using a PFI line but I want to make sure. Can you try doing a couple things: 1.) put your encoder into an AI line and see if the pulses are accurate. 2.) Run a simple edge counting VI on the encoder to see if there is a problem on what it's reading (it may need to have a digital filter applied, which can be done with a property node). 3.) Using property nodes, monitor the available samples in the DAQ buffer during acquisition. This will probably be a good indicator of what is happening in the background.

[RVallieu]

I used the encoder for all testing.  I put the encoder signal into PFI8 on the DAQ accessory which is a counter input, and I got the exact number of pulses per revolution expected.  The signal is not noisy from the encoder.

Case in point, I am not missing ANY points in the returned data from the SCXI-1600, they just don't come in the specified chunks of 5, they come back in large groups of 5, like it is buffering reads of groups of 5 and then returning them once it has reached some setpoint of storage size. 

In this case, it is always 38 groups of 5 readings (190 points).  When I rotate the encoder 2x, I get all 4000 points of data using both the SCXI-1600 and the PCI daq card.  Only the PCI-DAQ card returns the 5 points when it has 5 points.  When I probed the code, the DAQmx read was not returning in the While Loop until it had reached said 38 groups of 5, but then the loop iterates 38 times - returning the 5 points on each iteration.  After that the DAQmx read sleeps again for 38 groups of 5, and then does the same thing.  It still ends the task after the 4000 points are collected, so I am not sure where the 38 groups of 5 is coming from.

I will try to get you some screen shots of code.

I will also try number 3.

Message Edited by RVallieu on 03-26-2008 07:58 AM

Message Edited by RVallieu on 03-26-2008 07:59 AM

[PBear]

Hi Ryan,

I've set up a test rig on my side and haven't been able to reproduce the poor funtionality. I used this simple VI and every 5 pulses had 4 channels output 5 samples everytime. If you were having missing samples, I'd be curious as to termination but that isn't the case as you've received all the samples, just your delivery is not as expected. I too confirmed that this works on a PCI DAQ board and then moved this over to my SCXI 1600. Try using those property nodes to view the available samples in buffer and also cross reference this screen shot.

 


Message Edited by Patrick_Ba on 03-27-2008 03:56 PM

[PBear]

Hi Ryan,

You may also be running into an issue of USB latency. If your quadrature pulses are coming quickly, the data may be sent far after the first 5 pulses are received. This is because while USB 2.0 does have enough bandwidth for many of our DAQ applications, latency is slow. You can try and force the USB device to send more frequently by placing down a channel property node as this picture shows and setting the value to 'Onboard Memory Not Empty.'




Message Edited by Patrick_B on 04-04-2008 01:48 PM

[RVallieu]

UH-oh...well I tried that suggestion and now the application is not transfering any data.....

[RVallieu]

Another error in the system was causing the problem - forgot I didn't change the sensitivity for one of the LVDTs and it was out of range.

I put down a read for the property of AI.DataXferReqCond and the default setting was already set for "Onboard Memory Not Empty."  So setting this has made no difference.

[PBear]

Hi Ryan,

Sorry that didn't help out but it was worth a try. The root cause of this is most likely due to the USB interface which, regardless of device, is a bus that is highly latent. If you change the speed of your encoder, it's likely you will see a change in the number of sample groups that are sent back. For example, if your encoder went slower, I would expect the USB to send data more comparable to the 5 sample / 4 channel performance you'd expect.

USB has a high bandwidth when constantly sending data (i.e. a continuous flow of samples, sending pictures from a digital camera, a mouse) but intermittent starts and stops of data transmission will be effected by the latency of the bus. While NI's USB products encompass and push the entirety of the USB standard in order to make USB DAQ a reality, there are some bus limitations that are inherit and unavoidable.