NI-5133 Losing Trigger and Returning Fake Data

[pschmal]

Hello!

I have a NI-5133 USB acquisition device. I am taking in two channels of data, and triggering the device with a function generator on the PFI1 port. I am using digital edge triggering.

I use in a while loop, nScope Intiate Acquisition, then nScope Multi Fetch to acquire the two channels simultaneously. It runs great, for a while.

After a couple minutes it appears to lose the trigger track, and the waveform starts shifting wildly in time. However, the data is not real. I change the stimulus of the device I am measuring, but the waveform does not change. I turn the device off (at this point it should just return thermal noise), but the scope still returns the waveform that it read out right before it lost track. If I stop the VI and start again, it picks the trigger back up and returns the correct waveform for a few minutes, until this happens again. Is there a buffer filling up I can flush or something? The trigger is only running at 100 Hz, and I'm reading out 512 points at 150 kHz sampling frequency... So it should be ok... but it is not!

[pschmal]

I should add that my device name is 'Dev 1'. For some reason, many Dev 1 have been added to the I/O resource list. It now contains 'Dev 1' 'Dev 1 (1)' 'Dev 1 (2)' ... 'Dev 1 (22)', and seems to add them regularly. Is this part of the problem?

[pschmal]

Out of frustration, I unboxed another NI-5133 unit I had, and hooked it up. It now sits on the 'Dev 2' address.

Everything runs fine now. Is my other unit toasted?

[pschmal]

Nobody has had this problem before?

[Michelle_N]

Hrm, so you've tested two devices with the same software. One works fine and the other has strange behavior. Before assuming it's a bad 5133, try placing it in another usb port. Also open up Measurement and Automation Explorer (MAX) and run a quick self test on the device (right click and choose Self-Test). Does this pass? If you see multiple device numbers in your software, this should show up in MAX as well. Does MAX reflect these duplicate Dev 1?

[pschmal]

Michelle, Thank you for your attention to my issue. It passes self-test without a problem. The additional devices do not show up in MAX. In fact, when using the Test-Panel the problem does not occur. Yet switching back to the VI (with the duplicate device names) or any nScope example with triggering, the problem reoccurs. I will try placing it on another USB port next time I have a chance. Thanks, Paul

[pschmal]

I have been investigating this further.

Whenever some invalid choice is made on the front panel (like choosing something that causes no waveform), the VI will crash out with an error message. This means that the niScope session is not closed. When a new one is open, instead of closing any existing ones, it creates a new Dev 1 (n) device. This seems to cause the problem I described earlier when there are too many Dev 1 (n) devices (Why this behavior surfaces though, I don't know).

Is there some way to get all open devices and close them in the first part of the VI? I can only find blocks to close the current session.

[Michelle_N]

Yes - this is not usual behavior. What is your error - screenshot? And how can I reproduce it here - i.e. what do you mean be choosing something that causes no waveform?