Reference triggering (pre- post-trigger recording) problems in Signal Express

[BrianK]

Hi, I'm working with a PXIe-6358 DAQ card, and am experimenting using Signal Express to perform pre- and post trigger recordings.  It is apparently very easy to set this type of recording up in Signal Express.  Simply by adding a single instance of a DAQmx Acquire in the left side Project panel is about all it apparently takes.  Working in the configuration window in the center of the Signal express program, I set the program to acquire a fixed number of points (1000) at a fixed rate (1kHz).  In the Triggering panel, I set the program to start using a software trigger (A), and assign a rising edge digital reference trigger to be input at PFI0, and ask for 500 pre-trigger samples. I configure the Run button to run once, click on the Run button, click on the Record button so the data is saved, then the Trigger A button to start the program digitizing.  At this point the program indicates that it is waiting for the reference trigger.  I supply the externally generated reference trigger, and a second or two later, the waveform appears in the data view window.  So far so good.  After two or three of these iterations, the run button doesn't change from Stop to Run after displaying the recorded data, it changes to Abort, and stays that way for some time, minutes, and sometimes does not save data in the log file.  Even though I'm acquiring a very limited number of data points at a relatively low sample rate, on just one channel, it seems that I'm over taxing this program, and/or, the PC can't handle the way Signal Express configures the FIFO data array in memory to accomplish pre- and post-trigger data recording.

I'm using Signal Express 2009 v 3.5.0, NIDAQmx 9.0.2 (which should support the PXIe-6358) on a 32-bit WinXP SP3 PC with 4 GB RAM.  The PXIe-6358 is in a PXIe-1082 chassis, and connected to the PC via an 8370 PCIe-PXIe MXI bridge, so there really should not be any data bandwidth issues, and certainly not with the miniscule data transfer rate associated with experiment described above.

Is there a better way to configure Signal Express to handle pre- and post-trigger sampling to avoid these sort of problems?

[David-A]

Hello Brian,

If you are using a trigger and you click stop button, a trigger is still expected.  If a trigger is not detected then Signal Express will continue to hang indefintly until it either times out, receives that trigger, or abort is clicked.  Aborting, as you've noted, may cause data to not be appropriately stored.  

David A.

[BrianK]

Hi David,

Thanks for your reply, I appreciate it.  It seems odd that SE will wait for a trigger after the stop button is clicked, but if that's how it's supposed to work, I'll keep that in mind.  Yes, waiting for abort to run its course produces an unsatisfactory result.

Regards,

Brian

[DFGray]

SignalExpresss was originally conceived as an application to make using National Instruments hardware fairly simple without requiring programming.  Due to the hardware-centric nature of the design, there are two ways to stop it if running:

• STOP - a normal stop which completes the current iteration and shuts down hardware session handles in an orderly fashion.  If you are waiting on a trigger, the current iteration never finishes, so stop never happens.  Note that you can cleanly stop and "abort" one device waiting on a trigger by hitting the stop button, then changing the trigger type of the device in question to "none," "continuous," or similar selection.
• ABORT - an emergency stop which sends an abort message to all hardware and forces everything closed, regardless of state.  This will attempt to cleanly close things, but final state is not necessarily guaranteed.

As with most things SignalExpress, the actual behavior of any particular step is dependent upon the step designer (although we do have guidelines which are generally followed).