How do you abort the Scope Fetch before a trigger occurs.

[CGMENG]

I'm using a NI PCI 5112 scope card.  I've configured the start trigger on PFI 1 input with no timeout.   There does not appear to be any way to abort or reset the hardware once the niScope Fetch Binary 8.vi is waiting for the start trigger.  Does anyone know how to kill the niScope Fentch Binary 8.vi before the trigger is recieved?  (winthout restarting the computer!!!)

I'm programming in LabVIEW 7.1.1

[DFGray]

niScope Abort.vi should do it.  However, you will have to set things up to use it before you start waiting on the trigger.  You will need to have a parallel loop to your main acquisition loop which contains the abort VI, using the same scope reference.  Put it in a case statement triggered by a front panel boolean.  You can avoid the whole issue by polling the 5112 for status (niScope Acquisition Status.vi) and only doing a fetch if you have data.  That way you can abort and leave any time in the same loop.

[CGMENG]

I've already tested the niScope Abort and it does not work!!!.  I have a separate loop with event structure for the abort.  While the niScope Fetch Binary.vi was waiting for a trigger I executed the niScope Abort.vi.  I waited 10min but nothing happend.  When I turned on execution highlighting, both the abort and fetch vi's were running. 

I just tested the niScope Acquisition Status.vi and it does not work either.  The niScope Acquisition Status.vi has 3 output states, 0=acquisition in progress, 1-acquisition complete, and (-1)- unkwon status.  The problem with this vi is it indicates acquisition in progress while waiting for a trigger!!

I also tried the scope reset.vi with the same results as the abort vi.

[psisterhen]

As long as you are in the Fetch call, all other calls to the Scope driver will block until Fetch exits.  That's why the Abort doesn't do anything.  You have two options:

  1) Use a finite timeout.  Obviously, you are running into cases in which the trigger does not arrive, and want to exit cleanly.  This is exactly what the timeout is for.
  2) Determine the acquisition state before calling fetch.  If this is a finite, single-record acquisition, poll on acquisition status and do not call fetch until the status is 1 (acquisition complete).  If you're doing a finite, multi-record acquisition, poll on the Fetch>>Records Done property and only fetch the records that have completed.  If you're doing a continuous acquisition, poll on the Fetch>>Points Done or Fetch>>Fetch Backlog property and only fetch the number of points that have been acquired.

There's no clean way to break the infinite timeout fetch without forcing LabVIEW to close.

[CGMENG]

The application is continuous acquisition and steam to disk at 25MS/s. 

1. The trigger timeout is unacceptable for this application.  Our customer has indicated the trigger could be on the order of hours or second.  The abort feature is necessary in case they decide, for whatever reason, that they do not wish wait for a trigger.

2.  I've tested the poll for Fetch Backlog property and it work!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  Thank you for an excellent suggestion.