Maintaining encoder count while switching sample rates

[mdwebster]

So I have a project where 95% of the time, I'm running at 10kHz AI and CTR/TMR acquisition (quadrature encoder).

My traditional way of doing this is to run the AI Sample clock into the 'source' terminal of the DAQmx Timing.vi of the counter task.  That synchronizes everything up nicely.

However, I have a 5% issue where 1 test wants samples to run at 1MHz for just one AI channel and the encoder.  But I don't want to tear down the encoder task because I will lose my tared out position.  I also can't rely on the encoder not moving a slight amount between stopping the encoder task and starting it back up again.

So, thinking about this, I thought that maybe I could stop just the AI task, leaving the encoder task running, modify the AI sample rate and then start it back up again.  My first question is if the counter will not just maintain, but also continue to update its count while the AI task is stopped.  I believe the answer here is yes, but having confirmation never hurt.

The second question is bigger though.  What if I clear the AI task then start up a new one with just the single channel of interest.  Is the AISampleClock connection to the encoder task maintained through that or do I need to reconnect it?  Am I even able to reconnect it while the encoder task remains running?  I believe I can handle the glut of 1MHz data as I should only have 5 or 6 total AI channels, but I would rather just have a single channel running so as not to contend with charge injection at those high rates.

Thanks for any insight,

Mike

[Kevin_Price · Accepted solution]

1. As long as the Ctr task continues to be in run mode, your quad encoder position will continue tracking whether or not there's a sample clock signal present to *sample* it.

2. I'm pretty sure you should also be able to reconfigure the AI task the way you want and the Ctr task will get the sample clock signal once again when you start up the new AI task.  (I would probably first try to just stop the task to reconfigure rather than clearing it though.)

   You can run a simple test to make sure this method works.

-Kevin P

[mdwebster]

Hey Kevin,

I would test it, but I don't have the hardware yet and likely won't for a couple of months, I'm just trying to figure out if this scheme will work or if I need to come up with a different approach.  I've got some cRIO stuff laying around, and could probably get my hands on a cDAQ, but this job is going to use MXI/PXI and we don't tend to have spares of the more expensive stuff.

The cDAQ might be similar enough, though.  I can try it out Monday just to see if DAQmx itself complains about the configuration at a driver level.

Thanks again,

Mike

[mdwebster]

I didn't have a cDAQ with the right modules, but I did have an old USB multi-function DAQ.  Using that, and configuring it in the way I described, I was able to stop the AI task, set a different rate, then restart the AI task and have the encoder task pick back up while maintaining counts I sent it while the AI task was stopped.

I was also able to reconfigure the AI task as well, but I had to clear it and recreate it since there's no way to remove channels.  I'm a little worried about the 'lazy uncommit' issue biting me down the road and breaking the connection to the AI sampleclock from the counter task.  If it's all on the same device, I might not worry so much, but this might wind up being two separate cards in a PXI chassis so there would definitely be a dynamic DAQmx 'route' connection in the background to get the AI sampleclock of card X to the counter on card Y.  I tried with NI support, but I was unable to even explain the problem to the tech I spoke with sufficiently to even begin the conversation.

At any rate, thanks for your help.

Mike

[Kevin_Price]

It may be time to do the sample clock routing *explicitly*, especially if your AI and CTR tasks may get split across different devices.  Your concern about "lazy uncommit" is probably wise.

I like to do task-based routes using DAQmx Export Signal (or its corresponding property node).  You could route your AI task's sample clock out to PXI_Trig6 and then route your CTR task's sample clock in from PXI_Trig6.  Unless some other part of your app might claim control over PXI_Trig6 during the brief times you reconfig your AI task, you should be fine.

(Note: I've made a habit of starting my explicit routes with higher-numbered PXI_Trig lines, based on my admittedly unfounded assumption that when DAQmx claims some of them for automatic routing of timing signals, it probably works its way up from the lowest-numered ones.)

   If you run into trouble, it's probably simplest to do all timing signal routing manually via DAQmx Export Signal, giving you control to prevent conflicts.  Having a mixture of manual and automatic routing is probably the most difficult way to approach things.

-Kevin P