Few problems with acquiring and generating data from 3 modules (cDAQ 9178 Chassis)

[Tom_W_[DE]]

Hey Nick-

To be honest, I'm stumped on the synchronization issue you're seeing because at a glance your synchronization code seems correct.  I assume your graph is generated from the files logged in the 'Acquire' case of your state machine.  Is this correct?  One thing you might be interested to know- it looks like you are using bursts of sampling for both the encoder input and the pressure/AI inputs.  You might consider using Finite mode instead of Continuous mode, as the task will automatically stop itself and you can be sure the hardware won't generate more clock ticks than you actually need.  You can strip the DAQmx Stop operations in that case, and you *should* be assured that the operations will be synchronized.

Could you clarify what you mean when you say the output operations are not affected?  It looks like they are synchronized to some external signal via PFI.  Is that an encoder signal that is shared with the encoder input task, or is it some other signal?  And if it is from the encoder signal itself, do you meant to say that the pulse trains and triggers that are derived from that PFI input are successfully synchronized to the encoder movement?

[ngio]

Hi Tom,

Thanks for the quick response.  And sorry for the long reply... but here it goes.

On the first topic:

 I wondered if it may be the case that the encoder ticks are producing the sampling for the encoder while a timebase sample clock is sampling at every tick, therefore producing a longer duration of sampling for the encoder compared to the analog inputs.  You are correct in assuming the graphs are generated from the data in the "acquire" state.  I will switch the sample clocks to finite sampling mode and see what happens.  If I do this can I trigger another session for "acuire" simply by selecting that state in the statemachine or does this mean that I have to stop and start the vi again for more sampling and data recording?

On the second topic:

In the vi there are two output pulse generators that provide a pulse-width and timing control.  They are triggered off the encoder z-phase signal and they count ticks from the encoder a-phase signal.  These outputs are well synchronized with the encoder movement which assurese me that the encoder is fully functional and the sampling of the encoder is accurate.  Although they do not have any dipendicie on the analog inputs therefore I can't determine if they're sampled at the same rate as the AI.  Either way, I don't think this portion is very relevant to the discussion of synchronization since I am confident that the encoder is fully functional.

 The way I see things, is that I have two options for setting up the sampling for the encoder input and the analog inputs.  

Scenario 1: 

AI:            0,0,0,0.1,0.1,0.2,0.3,.0.2,0.4,.5,.6,.7,.8,.9,1,1.1,1.2,1.3,1.4....etc. (20 samples at 100khz)

Encoder:   0,0,1,2,2,2,3,3,4,5,6,6,6,7,7,8,9,10,10,11....etc.  (20 samples at 100khz, independent of whether a tick was encountered or not)

This represents where the encoder is sampled not at every tick but the corresponding degree is retrieved at every sample.

Scenario 2:

AI:           5samples,5samples,5samples,5samples,5samples,5samples,5samples,5samples,5samples,...etc

Encoder:  1,2,3,4,5,6,7,8,9...etc

Where at every degree or "tick" from the encoder triggers 5 samples from the analog inputs.  This would result (when plotted) of the following for the encoder data...

Encoder:   1,1,1,1,1,2,2,2,2,2,3,3,3,3,3,4,4,4,4,4,5,5,5,5,5,6,6,6,6,6,7,7,7,7,7,8,8,8,8,8,9,9,9,9,9,9....etc.

What I don't want (and is what I think I currently have) is the following:

AI:   20 samples at 100khz timebase

Encoder: 1,2,3,4,5,6,7,8...,20. sampling based on encoder ticks.

Does this sound about right?  Do I currently have the third scenario or is it something entirely different that I'm missing?  Also, which method of sampling would you recommend and why (if possible)?

Thanks again for the help it's greatly appreciated,

Nick

[ngio]

Success!!!  I am able to record synchronized data.  It seems the setup i have now records the data similar to that in scenario 1 of my last post.  Although I was wondering since now I have to setup the buffer sizes by specifying the number of finite samples, should I be doing this at the sample clock.vi or the read task.vi?  what is the difference and does choosing one over another effect the ability to change the buffer size on the fly?  I have tried both scenarios where the buffer is specified at the Sample clock and the read task although neither gave me the ability to change the buffer size while the program is running. Perhaps I have to reistablish all the channels and sampleclock settings before each recording iterations?  This would take too long if its the case, so if you have a work around, i'd be very interested to here.

Thanks again for the great help.

Nick

P.S.  I posted a .png for those who come across this thread wondering what I did, one thing to remember when using finite sampling in a while loop is that you have to start and stop the tasks inside every loop.

[Tom_W_[DE]]

Hey Nick-

I was about to type another reply when I saw your post.  I'm glad to hear you're seeing better results now.

Specifying the 'samples per channel' on the DAQmx Timing VI for finite tasks sets the sample buffer size directly.  For Continuous tasks the buffer size is determined based on logic that accounts for both the 'samples per channel' and 'rate' parameters to DAQmx Timing.  Check out this recent discussion I had with another user, if you're interested in more details on this.  His is for the .NET API, but the considerations are the same as the LabVIEW API.

The 'samples to read' parameter on DAQmx Read indicates how many samples to fetch from the buffer for *this* read operation.  It doesn't affect the buffer size at all.  That parameter allows you to call DAQmx Read with a frequency and sample set size of your choosing, perhaps to tune for responsiveness in a UI as a tradeoff for overall performance (since you need to be able to "keep up" with emptying the buffer using DAQmx Read at a rate equal to or faster than the hardware is pushing samples into the buffer, else you will eventually overflow).

You already realized it, but you will need to start and stop (via DAQmx Start and DAQmx Stop Task, respectively) in order to repeatedly use finite tasks.  There is some processing cost to doing things this way, but it can make synchronization more intuitive at the end of the day so that cost may not be a big deal as long as it doesn't affect your performance in an unacceptable way.

Anyway, I'm glad to hear you're up and running now.  Good luck with the rest of your application.