High-Speed Digitizers

cancel
Showing results for 
Search instead for 
Did you mean: 

Max time exceeded w/o trigger -- niScope Multi Fetch WDT.vi

I am attempting to perform both single-shot and continuous acquisition as needed, using niScope Multi Fetch WDT.vi. My current program structure is as follows:

Do

Perform init routines as needed, or if settings have changed since last loop iteration:
{
Init Horiz
Init Vert
Init Trig
Clear init flags
}

niScope Initiate Acquisition.vi //start up the digitizer

niScope Multi Fetch WDT.vi //get data

Display data on waveform graph

Loop


So the problem I'm having is the timeout on the Multi Fetch WDT when the trigger level is set outside of any level the current signal will ever hit.

niScope Multi Fetch WDT.vi
Error -1074126845: Maximum time exceeded before the operation completed. Possibly no trigger received. Buffers done: 0, Points done: 0.00000

For example, using a 100mV input signal with the trigger level = 150mV will make the Multi Fetch WDT.vi eventually timeout after the timeout delay has been reached. This timeout is not a problem in a case where the trigger level is within range of the signal being measured (say trigger level = 50mV) and there was simply no 100mV signal present yet--in that case, the VI should loop and wait again for a signal to be present and acquired. The problem is when there will never be a signal, because the user sets the trigger level too high (or too low).

The way my acquisition loop is set up, it shouldn't be a problem: Set the new trigger level to initialize next time around so the Multi Fetch WDT.vi won't timeout. This is where I'm having problems, because I get the following error:

niScope Configure Trigger Edge.vi
Error -1074118647: A previous acquisition is still in progress. If you are attempting to change an attribute, note you can only change fetch attributes while an acquisition is still in progress.

I'm assuming that I can close the entire session and re-initialize everything (horiz, vert, trig) to get back to where I want to be with a new trigger level value. Is there any way to NOT close the entire session and erase all of the vertical and horizontal settings though? Is there a way to simply update with the new trigger level value?--ie, to tell it to quit whatever acquisition is in progress without erasing all of the settings? Normally when a trigger is being received, this error doesn't occur, and a new trigger level can be set on the next loop iteration, but once it times out once, it's all over (without reseting everything).
0 Kudos
Message 1 of 7
(9,343 Views)
I'm using a PXI-5122 btw, which doesn't strike me as relevant to the problem I'm having, but may be.
0 Kudos
Message 2 of 7
(9,336 Views)
The best way around this problem is to use the NI-SCOPE Abort VI to abort the acquisition after a trigger is not received. This should solve your issue without having to close the session or reset the device.
Message 3 of 7
(9,307 Views)
In conjunction with disregarding an error about not receiving a trigger, the method you listed works great and is exactly what I was looking for (exactly what the NI engineer told me on the phone I couldn't do... *sigh*). I think the reason I missed this originally is that those VI's weren't used in any of the NI examples I looked at, and are also buried in the NI-Scope palette hierarchy. The other useful VI available on the same palette was the status VI, which allows for monitoring of my init flags in a paralellel loop which will end if the acquisition completes (which ups efficiency and makes sure I won't miss a trigger). Thanks again for the suggestion.
0 Kudos
Message 4 of 7
(9,296 Views)
I'm trying "niScope EX Multi Record Fetch More Than Available Memory.vi" with my pci-5112. Have I to add "niScope Initiate Acquisition" after aborting in the loop? Or do I need to do something with the "Fetch Record Number" after aborting? Or if I don't want to reset the onboard free runing timing clock after the error, what shall I do? I'm getting very puzzled.

Thanks.
0 Kudos
Message 5 of 7
(8,748 Views)
Always post questions as a new thread, otherwise no one will see it or reply with an answer.
0 Kudos
Message 6 of 7
(8,743 Views)
If you change your acquisition procedure slightly, you won't have to disregard an error and the code will happily wait forever for a trigger.  Do an initiate acquisition, then poll the acquisition status to tell you when the acquisition is complete (you may want to put an abort option in this loop - abort your acquisition when you abort).  When status comes up complete, fetch your data.  The attached VI should make this a bit clearer.

NOTE:  This is the method used by the NI-SCOPE Soft Front Panel
Message 7 of 7
(8,732 Views)