PXIe-4304 and PXIe-4353 with custom scales, simultaneous aquisition for long periods of time

[larserike]

Hello experts of the internet!

I'm currently debugging a PXI-system with two cards, PXIe-4304 for Voltage inputs and PXIe-4353 for Thermocouples.

The attached code uses a shared clock signal from the PXIe-1062 Chassis with a shared start trigger.

Everything seems to work as expected for a while, but after som time the data gets corrupted for all inputs without stopping the loops or producing any errors.

The data from PXIe-4304 "recovers" and logs real data, while PXIe-4353 collapses until restart of the VI.

Every third hour or so if the system is running, a similar occurence happen.

I can see that the error is cyclical, but the first time data gets corrupted happens at a seemingly random time after start.

I'm working in Labview 2018 with DAQmx driver 21.0.

Any input would be highly appreciated!

Notes to the screenshot:

I've displayed the same channel from two different tests, and they have the same time between the bug, but they start at different times as shown.

X-axis is in seconds.

Regards

Lars Erik

[l.hovs]

Hi Lars Erik, 

Can I know what kind of error you see is cycling? Please shar information about that error, any error code or hex to be clearer. 

Regards)

[larserike]

Hi! Thank you for your reply.

The only error i get is "physically" shown in the waveform graph in the screenshot from my original post.

"Simple error handler.vi" shows no error upon completion, sadly.

I'm using a Fluke 5500A and applying a 0.1Hz sinusoidal signal in the mV range to simulate K-type temperatures between approx 250 degC and 950 degC.
In the following images white signal "EXT1" is from the PXIe-4304 (voltage, scaled to ease comparison with thermocouple data) and the red signal "EXT2" is PXIe-4353 (thermocouple).

Also, during debugging I used the clock on the computer when I started and stopped and I end up with more samples than I should.
It seems like whenever the error occurs the system logs more data than it should (overflow of some sort?). 

If you look at the zoomed in graph the faulty data "takes up" around 100 seconds in the TDMS file.
In this specific test there were 8 such occurences, so around 800 "extra" seconds compared to what's expected.

By removing these 800 seconds I got about the expected length of data compared to the computers clock.

Overview full test (93 000 seconds):

Zoomed in on the first error:

 

Regards, Lars Erik