Pause logging and start trigger

[xl600]

I don't believe there's a solution for this but I'll ask anyway..

I use DAQmx logging (PXI-6281) to offload as much as I can CPU wise, instead of manually logging.  This was the easiest way to approach my needs.

But I also want to acquire data while not logging (So the users can preview the realtime data).

So, I currently use two tasks:

1. A preview acquisition task without logging or an acquisition trigger
2. An acquisition task with logging and a start trigger

I then switch between these tasks when the user wants to start logging.  The start trigger is either externally supplied or internally generated.

Works fine.... extept now I have a need to prevent any disruptions in the preview data stream when switching back and forth between preview and acquisition modes.  This means I need to use a single always running task.

So, can DAQmx logging be enabled and disabled concurrent with a trigger?

The Pause Logging feature doesn't seem to function that way.  In Read and log mode, pause logging can only start logging on the NEXT read.  That wont catch the samples between my trigger signal and the point I try to read samples.  Two thoughts come to mind then:

1. Manually logging so that I can catch the sample stream at the trigger point to start logging.  If so, is manually logging to TDMS less efficent than using the built in TDMS logging?
2. Somehow inserting the missing samples into the start of the first TDMS log file.  Is that even possible?

Thanks,

XL600

[luda.mattski]

Hi xl600,

Is your trigger source from a physical event that happens in hardware or is it just a way to enable logging?  You could try specifying a number of pretrigger samples which are saved in memory previous to the triggering event.  The number of pretrigger samples saved in memory can be configured as a property in the DAQmx Triggering Property Node.  With that said, the Pause Logging functionality is worth looking into further: 

http://forums.ni.com/t5/Example-Program-Drafts/TDMS-Logging-with-Pause-Logging/ta-p/3525697

You could also try switching between both tasks using the architecture presented here:

http://www.ni.com/example/28586/en/

[xl600]

It's either a software trigger or hardware (External trigger) depending on user selection.  So I can't assume anything about it other than 'it will happen sometime'.  This can be microseconds of delay (Self triggered) to minutes of delay (Hardware trigger) and anywhere in between.

The basic issue is that I don't want to suffer any missing samples or gaps in my preview data flow while wanting to ensure logged samples are logged from the trigger edge itself.  My current design does suffer a gap (I am actually using that architecture) in both samples lost during switching the tasks and in the delay to the start logging trigger after switching to the logging task.

For pause logging, will the logged waveforms have a T0 of when pause logging was disabled or a T0 of when the task started and sampling began?  I have a funny feeling it'll be the later situation.

Thanks,

XL600

[luda.mattski]

Hi xl600,

The best way to achieve this functionality (more-or-less) is probably to use conditional logging based on incoming data values or a front-panel button which enables logging.  Since a trigger tells your hardware when to acquire data and you'll be acquiring data throughout the entire program execution - but only logging sometimes - you'll have to use one of the above methods rather than the trigger to enable logging.  

[xl600]

I spent all day yesterday working on this, but I think I figured out a way to handle this.

I already had a method for creating a timestamp notifier based on a PXI trigger (Using the DAQmx Create Timing Source VI and a real time timed loop).  This timestamp is quite accurate (About 10us accuracy even under load).

1. In a while loop, I first read a fixed number of samples as Analog 1D WFM NChan NSamp.  This happens from the moment the task starts.
2. I split off the first WFM of each read and extract its T0
3. I calculate the T0next based on the # samples read and the dt value.  This is the expected T0 of the next read buffer.
4. I check my notifier (zero timeout)
5. If the notifier had been sent and the timestamp is within T0 and T0next, I calculate what the nearest sample is (To the right of the notifier time)
6. Two conditions:
   1. The #samples to retain = 0 (Meaning the first sample of the next read is the nearest).  I ignore the current buffer.
   2. The #samples to retain >= 1 and <= samples read.  I split the current buffer and enqueue (To my own queue) the tail end of the buffer (#samples to retain).  The T0 of the enqueued portion is calculated for the sample position selected.
7. For followon reads, all samples get enqueued in their original WFMs

All the while, I'm using all samples for my previewer function

The queue then gets emptied into my TDMS file.

I've tested this extensively today and I haven't seen a hiccup.  I suspect things won't be so clean at sampling rates > about 10kHz since my trigger detector accuracy isn't all that good.  But I don't collect at higher rates so it doesn't matter.

Performance wise, this does add a few % CPU when I'm manually logging 16 10kHz Ain channels.  I can live with that.