From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

How to Pause an Unpause two synchronized AO and AI tasks, everyN, using only software DAQmx

I'm using DAQmx with Python on a USB 6363.

I currently have AO an AI tasks synchronized as per the example code, "SynchAI-AO.c".

 

However I'd like to be able to pause the task every N samples so I can go and do some other stuff, then restart again later when that other stuff is done.

 

I started with something like the following function in a PyDAQmx task object:

def setEveryN(self, N):
""" Change how often the callback is called """
self.lenToRead = N
self.AutoRegisterEveryNSamplesEvent(pd.DAQmx_Val_Acquired_Into_Buffer, N, 0)
if N != len(self.data):
print('Configuring pause trigger')
self.SetPauseTrigType(pd.DAQmx_Val_DigLvl)
self.SetDigLvlPauseTrigSrc(....????????)

 

All the discussion about triggering is about physical wires, so I figured I could set the pause trigger to be when the AOTask has done N samples, but then I got very confused about what terminal and signal to connect, and I have no clue how to UNPause (ie restart) the sampling again with software control.

 

Can someone please provide some pseudo code, or actual C or Python code for this?  I don't have LabView, so I'm unable to interpret VI images.

Otherwise, I think I may have to manually re-arm the device every N samples.

 

(In most circumstances, N is actually 1, so I want to do something in between each DAQ sample).

 

It's conceivable I do the extra stuff within the EveryN callback, but this other stuff is slow, so I'd have to set DAQ sample clock to something very slow, which is probably fine, but then it's a matter of trying to find a suitable rate, which means some hand-tuning for overall timing.  I'd rather everything be sequential and serialized/synchronized on the same thread.

 

 

Thanks

 

0 Kudos
Message 1 of 2
(4,144 Views)

I was able to get what I wanted, sort of, by the following:

 

Summary: I needed to set up the DAQ with a particular AO pattern, and after each AO/AI sample, go and do some other stuff.  The other stuff is actually reading a different sensor system over ethernet.  The other stuff happens at a maximum of about 80Hz.

 

1. I set up the AO an AI clocks to 70 Hz.  

2. I set up the AO buffer with my desired pattern of a few hundred points.

3. I set up the callback every N with N=1.  So I get called back each sample.

4. I set up the AO to trigger on the AI StartTrigger, as per the example code for synchronized sampling.

4.  Within the callback I read a single sample, then append it to another independent buffer.

5.  Within the callback I then go and read my other sensor.

6.  When the done callback is called, I reset the other independent buffer.

 

Specifically, what did NOT work was the following:

1. Setting every N=1 callback, then reading the whole buffer within the callback.  This meant the ReadF64 blocked on the first call to the callback until every sample came through.  When that returned, there was apparently some buffering of the callback interrupt/request, so the callback got called repeateadly *after* everything was finished, once each for the remaining samples, which at that point no longer existed because the task was finished.  This also mean I could not call the other sensor functions with each individual sample.

2. Using the main AI buffer as the data holder for the rest of the program.  This is because reading only one sample at a time would always put that sample at the beginning of the buffer.  Since I'm doing this in python, it's not as straigtforward as C to make a pointer within a buffer for the next sample, given that my buffer is 3 float64's wide for each sample.

 

What I would still ideally like is for every 1 sample to be able to pause the task, go do my sensor read (which is blocking), then resume the task when done, and be able to leave the task clock high, like 1000Hz.  So right now I'm running the task at 70Hz so it doesn't clobber my reading of the external sensors; there is no explicit synchronization betwene the DAQ task and my sensors, other than manually/ad-hoc setting the data rates to be compatible.

 

I'm not sure if anyone is reading this, probably not, but I figured I'd write this down to summarize my own thoughts on how I finally got this working.

 

 

 

0 Kudos
Message 2 of 2
(4,119 Views)