3 5102DAQ will hang work together

[alex.]

I am trying to make the three cards synchronization, triggerred at the same time.

But sometime the waveform refreshment will stop for a few seconds, this happened randomly.

When the waveform display stopped, I monitored and found, the pc's cpu usage will drop to zero. After it start display again, the cpu usage will rise again.

When the card start display again, the waveform will be distorted in the first cycles, seems the hardware of the card has been reset.

[danvilla]

turbot,

It seems that your code is actually sampling from the three different NI SCOPES in a sequential manner, not synchronously. The sampling may happen close enough to each other that you may not be concerned about this fact.

First of all I would suggest some error handling to go along with your loop. I see that you are actually ignoring the errors reported by the niScope VIs. See if you can actually display all errors during execution to determine if the scope is reporting any errors.

I see that you have a filter variable reference (Filter_para) that you pass to the conditional statement.  Do you get the same problematic behavior whether or not this variable is true?

Question: What is the number of samples (called “record length” in your VI) you are trying to obtain from your 5102?

I think we can better help you if you provide this and any other info that may be helpful about your project.

Thanks,

Daniel V.

[alex.]

I am following the sample of synchronization of 5102 ni scope.

Curently, I am not using filter yet.

The recorder length is 400k

[danvilla]

turbot,

In the example code for synchronizing the 5102 devices there are VIs that handle trigger signals between devices (i.e. “niScope Configure Trigger Edge.vi” and “niScope Configure Trigger Digital.vi”). I don’t see those in your code. Those trigger signals are used to synchronize the separate sampling clocks in the 5102 boards.

Also, 400K samples will slow down your refresh rate significantly. Try lowering the number of samples to something in the 10K order and see if that improves performance.

As to the fact that you see the scopes power cycling, my only guess is that you are somehow exiting the while loop in the Curr_Hist_Display and closing the session to scope 1 while the other two scopes still have open sessions. The delay that happens before turning them back on may be caused by other VIs that are saturating your memory.

I have attached some code that I built which is similar to your code but plots the three scope outputs in different graphs.  While this code is NOT the ideal way to acquire from niScope it looks like your code and it also works on my hardware. Try this code while your application is running to see if you get similar results.

[alex.]

Sorry, I am still using 8.2.1. May you help to save the file in the older version. Thanks.

[danvilla]

Sorry 🙂 Here is the code in 8.2.1