LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Time channel skips ahead or behind

Setup:

I am acquiring Data from NI PXIe-1078 chassis, with 5 NI PXIe-6368 cards and 1 NI PXI-6683 timing module. In the “Acquire Data” while loop, an “analog 1D Wfm NChan NSamp” waveform and an IRIG timestamp is acquired (for each card). Then they are bundled, passed to the “Log Data” while loop through a queue, unbundled, and finally, the t0 for the waveform is overwritten with the IRIG timestamp. The waveform is then converted to x-y pairs. The waveform, x, and y data are all logged in different groups in a TDMS file.

(Ignore the Slave Cards for now)

Issue #1:

When the x (IRIG Time) data is viewed in DIAdem, the graph is not completely linear. There are jumps to ahead or behind of time.

X channel from HSCard5/ai0 is shown in Pic 1.

 

The graph (pic2) compares the waveform (red) and the x-y pairs (blue) of HSCard5/ai0.

As you can see the waves are synched until .01 seconds which coincides with the “samples per loop” parameter. There appears to be some type of delay, glitch or what have you between each frame for the x-y pair graph (blue). However, the waveform (red) does not have the same issue even though it has the same t0s.

 

 

Why is there time jumps in the x(IRIG time) channel?

 

 

Why is it that the waveform (red) has the correct graph shape of the square wave but not the x-y pairs (blue) graph? Can the waveform correct the t0 timestamp discrepancies automatically?

 

Download All
0 Kudos
Message 1 of 9
(3,974 Views)

Hello A.Ramirez,

 

Do you observe the same behavior on the waveform indicator on your LabVIEW program?

Saki K.
Applications Engineer
0 Kudos
Message 2 of 9
(3,914 Views)

it  appears normal in the waveform indicator.

0 Kudos
Message 3 of 9
(3,909 Views)

Plotting the WF data type will use the "t0" of the waveform to plot the date on the X Axis.

 

Speculating...

 

Since you are reading a single value from the IRIG but acquiring multiple samples from the DAQ tasks, I will speculate that the IRIG infor is coming back right away. The DAQmx task however will wait until the specified number of sample has been transferred by the driver. There is jitter involved in that buffer transfer.

 

An alternative approach would not acquire a fixed number but rather check the backlog to determine how many samples are available and then aps that to the DAQmx read. using approach will avoid the DAQmx read waiting for the data.

 

Done speculating for now,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 9
(3,902 Views)

I will look into this...

0 Kudos
Message 5 of 9
(3,891 Views)

Check the backlog BEFORE your seq frame and pass the backlog count into the frame to grab the data.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 9
(3,889 Views)

I have tried checking the backlog using the available samples per channel property node and it is still giving me jitter.

 

I am really stuck here.

0 Kudos
Message 7 of 9
(3,865 Views)

Share your most recent code so we can take a peek.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 9
(3,858 Views)

I apologize for the delay as I had to jump to another project for a bit. I attached the  code where I read the number of available samples per channel. I tried reading it before reading the daqmx inside the sequence and before the sequence. It still gives me jitter in every case when I graph the xy pairs in diadem.

 

however, I think I know what the problem is. It appears that diadem only sees up to 4 significant digits of the timestamps (for the xy pairs; the waveforms graphs fine). so, for example at time 12:10:10.0012, it sees several samples on the same timestamp.

The limited resolution might be causing a variable offset, about +/- .0001, between each iteration/generation.

Is this theory plausible? or am I completely off?

0 Kudos
Message 9 of 9
(3,845 Views)