Bad Acquisition with external Clock (C# program)

[IspAdri]

Hi, I currently have an acquisition problem with an external clock reference.

Equipment used : 

•  Acquisition Card : NI USB-6210.
• External Clock is motor step (see attachment picture for the signal) (approximately 800 Hz)
• Programming Language : C# (Visual Studio) (see attachment picture code)

I want to acquire a voltage mesurement for each motor step. The motors makes a movement of 26 665 step.

I start my acquisition with a trigger on the same signal of the external clock.

Problem : 

• If i acquire with continuous sample and on rising edge of the clock, I acquire approximately 48 000 points and on falling edge i acquire approximately 27 300 points.
• If i acquire with finite sample (26 665), I dont have the totaly of the movement.
• I have to put a timeout to -1 otherwise I get errors during acquisition.

I think it's probably a signal clock problem but the signal looks good. 

If you have an idea, i'll take it. 

I'm sorry for my bad english.

Thanks

Exemple configuration Code : 

//Create a new task
    myTaskAcquisitionVoie4 = new NationalInstruments.DAQmx.Task();

//Create a virtual channel
   myTaskAcquisitionVoie4.AIChannels.CreateVoltageChannel(channel, "",(AITerminalConfiguration)(-1), Convert.ToDouble(0),Convert.ToDouble(10), AIVoltageUnits.Volts);

   myTaskAcquisitionVoie4.Triggers.StartTrigger.ConfigureDigitalEdgeTrigger("/Voie4/PFI" + PFI, DigitalEdgeStartTriggerEdge.Rising);

//EXTERNAL CLOCK SOURCE
   myTaskAcquisitionVoie4.Timing.ConfigureSampleClock("/Voie4/PFI" + PFI, 810,SampleClockActiveEdge.Rising, SampleQuantityMode.FiniteSamples,26665);

   myTaskAcquisitionVoie4.Stream.Timeout = -1;

// Verify the Task
   myTaskAcquisitionVoie4.Control(TaskAction.Verify);

//Instanciation des objets NI
   analogInReaderAcquisitionVoie4 = new AnalogMultiChannelReader(myTaskAcquisitionVoie4.Stream);
   analogCallbackAcquisitionVoie4 = new AsyncCallback(AnalogInCallback_AcquisitionVoie4);

// Use SynchronizeCallbacks to specify that the object
// marshals callbacks across threads appropriately.
   analogInReaderAcquisitionVoie4.SynchronizeCallbacks = true;

//On lance l'acquisition
   analogInReaderAcquisitionVoie4.BeginReadWaveform(26665, analogCallbackAcquisitionVoie4, myTaskAcquisitionVoie4);

[Kevin_Price]

I would agree that it seems to be an issue with the clock signal, despite the fact that your scope trace looks clean.  I've been in similar situations where behavior implied a glitchy signal but scope traces showed nothing unusual.  I'm not an EE myself, and this is where I'd try to find one to help with the diagnosis.

That said, I would also try tinkering with setting up a digital filter on the clock signal.   M-series devices have *some* support for digital filtering on PFI lines, but I don't know for sure if you can set it up on your specific device under your specific usage (PFI used as sample clock for AI task).

There's another way to accomplish something fairly similar though using one of your device's counters.  Here's an outline:

• Configure a counter to generate a single pulse with minimal low*and* initial delay times.  Maybe 1 microsecond or so.
• Configure the task to use the step pulse as a Start Trigger and further configure it to be retriggerable
• Set the high time long enough to help "filter out" the apparent glitches.  With an ~800 Hz expected signal coming in, it should be plenty safe to set it in the 100's of microseconds, maybe even a millisec
• Configure your AI task to use this counter's output pulse as its sample clock

Here's how/why it works.  Once triggered by a real step pulse, the counter needs to get all the way through its pulse generation before re-arming to be ready for the next trigger.  Thus, any glitches that occur before the pulse is complete will be effectively ignored.  The counter's output will only be delayed by ~1 microsec from the step pulse, which will likely be negligible for your purposes.

    Even *if* there's a glitch just before a legit step pulse that your counter triggers off of, you'll just generate your output pulse slightly early, ignore the legitimate step pulse this time, but be ready to catch the next real one.  So instead of getting lots of extra AI samples, you only have a small risk of an occasional slight difference in the interval times between samples.

-Kevin P

[IspAdri]

Hello Kevin_Price, thank you for your reply. 

I did'nt find an option to activate a digital filter intergrated into the NI card and I didn't do it myself.

I analysed the signal more closely and it is really correct (as good as from GBF and the GBF signal don't work too).

I don't understand what more it needs.

Having a free input on my analog inputs, I decided to simultaneously acquire this clock signal (motor impulsion) and other signals with the internal clock of the card with an higher frequency.

I do signal processing after acquisition (schmitt trigger type) in order to detect each rising edge ans associate my data with it. I think this is the simplest method at the moment.

Thanks again. 

Adrien

I did not find an option to activate a digital filter integrated into the NI card. I didn't bother to do it myself either.

Having a free input on my analog inputs, I decided to simultaneously acquire this clock signal (not motor) and my other signals with the internal clock of the card with a much higher frequency. I then carry out signal processing (Schmitt trigger type) in order to detect each rising edge and associate my data with it. I think this is the simplest method at the moment.

Thanks again.

Adrien