why is the synced data out of phase

[griff32]

I am trying to sync my timing using a NI-9237 and an NI-9244 in a 9178 C-daq chassis. When I don't synce the timing using BD1 (block Diagram) it produces this XY Graph1 (The in-phase data I am looking for). However Change the data to sync the acqusition BD2 (Block Diagram) it produces this XY Graph2 ( Not the same data as XY graph 1).

Any information to correct this errror would be appriciated.

[griff32]

Here is XY graph 2

[SunainaK]

Hi Griff32,

The digital filters on both the analog input and output of DSA cards always impart delay. This is why you are seeing the out of sync graph.

The following document goes into more detail on this matter:

http://digital.ni.com/public.nsf/allkb/F989B25FF6CA55C386256CD20056E27D?OpenDocument

[griff32]

Sorry for the late Response Sunaina,

Thank you for the link to the document. I understand the delay, and it is very helpful. I am wondering if you (or someone else) can then please explain to me why this code https://decibel.ni.com/content/docs/DOC-8231 is considered Synchronized.

Thanks

[griff32]

So Base on the current information That I have found. Here http://digital.ni.com/public.nsf/allkb/5CF106A8F61CCC3886257909005C5373 and Here http://digital.ni.com/public.nsf/allkb/593CC07F76B1405A862570DE005F6836?OpenDocument

I have created a VI to pre-sample my data on my input NI-9237 channel to eliminate the Delay. Is this correct?

[griff32]

Just for information for anyone following this thread. I have figured out the issue between my 2 Block diagrams. In the attached BD you can see where I circled the Offset nulling VI. This is is the same sequence as the Start task for the encoder. Placing the offset Null VI at this point seems to "Start" the task and Trigger the Encoder to start before the Strain channel.

I don't know if my explanation makes any sense, and if someone can confirm my understanding that would be great.

[Kevin_Price · Accepted solution]

Just responding to the most recent post -- no time now to carefully dissect all the prior info.

First, and this is entirely a non-functional nitpick, but wouldn't it be less confusing to put the

initial AI config calls *below* the Encoder config calls so you wouldn't have to cross the streams?

Second, it looks like youv'e configured your encoder task to do its sampling based on the

AI Sample Clock.  Good so far.

The call to perform Nulling will have to engage the AI subsystem.  I'm supposing it uses your

other task config parameters (such as sample rate) in the process, thus you start generating

AI Sample Clocks implicitly which will in turn generate Encoder samples.

Odds are the Nulling operation will then stop the sample clock when it's done -- that's the

normal behavior for DAQmx auto-start operations.  So here's what *I* would try:

Perform nulling *before* starting the Encoder task so that the Encoder task won't collect

samples while you null your bridge.  As a precaution, call DAQmx Stop for your AI task

right after the nulling.  *Then* start your Encoder task, and then finally (re)start your AI

task.

-Kevin P

[griff32]

Thanks Kevin,

As To your First point, I did have the Ai config calls below the Encoder calls, then hit clean up Diagram, and it for some reason reversed them. I will be cleaning it up myself.

I appreciate you taking the time to confirm my understanding of the issue. I need to complete my nulling before I start the Encoder task. Even though the VI does run as it is suppose to now, I am going to call DAQmx Stop for my AI task right after the nulling.

Thanks again for your help