ni daqmx 9.6.1 pulse generation frequency

[Milack]

Hello!

I've been using a NI USB-6211 to control a step motor. I need to generate a finite pulse train with the right frequency in order to make an angular displacement in the desired speed. For that, I wrote an application in C# (.NET 3.5) using the NI DAQmx 8.8 library, and the application worked fine. However, when I updated the driver to the 9.6.1 version, the same application (recompiled with the new DLLs) took exactly half the time to complete the same task. I didn't measure the counter output, but I suppose the generated frequency is twice as configured.

Is there any known bug in this version of the driver or I possibly did something wrong?

Thank you!

[John_P1]

You should probably post your code if you want anybody to be able to answer your question.  I'd be very surprised to see a hardware-timed counter output task change frequency from one driver version to another.

Best Regards,

[Abel_Souza]

Hello Milmack,

You can try test generating the signal with NI-MAX, if it work on MAX the problem is your code, if not the problem is with the driver. If the problem is the driver you van instal the newest one, NI-DAQmx 9.8.

Best regards,

[Milack]

Hi John_P1!

I didn't think the code was relevant in this case, because the same code worked fine using the NI DAQmx 8.8, but didn't make it using version 9.6.1.
Anyway, the code is something similar to this:

--------------------------

Task task = new Task();
task.COChannels.CreatePulseChannelFrequency("Dev1/ctr0", "PulseTrainCounter", COPulseFrequencyUnits.Hertz,

                                                                        COPulseIdleState.Low, 0.0, frequency, 0.5);

task.Timing.ConfigureImplicit(SampleQuantityMode.FiniteSamples, setOfSteps);

task.Start();
task.WaitUntilDone();
task.Stop();

--------------------------

Debugging this application in Visual Studio, the variables frequency and setOfSteps are loaded with the right values, but the method WaitUntilDone seems to take half the time it should take.

Thanks for your answer!

[Milack]

Hello Abel_Souza!

I'll try the newest version first, I hope this bug has been fixed (if it was there). If the problem continues, I'll try NI MAX.
Thank you!

[Milack]

Abel_Souza,

I tried the newest driver, version 9.8, but the problem came back. Besides, NI MAX doesn't allow the user to generate a finite pulse train, only indefinite ones.

[John_P1 · Accepted solution]

Can you scope the output?  Which of the following describes your situation?

1. You get the desired number of pulses at twice the desired frequency.  I still think this seems unlikely.
   
   
2. You get less than the desired number of pulses at the desired frequency.  If this is the case, I'd bet WaitUntilDone is not waiting long enough for some reason (verify this by adding an additional wait time after waiting but before stopping the task).
   
   
3. You get the full number of desired pulses at the desired frequency.  If this is the case, then it seems the software is just executing more quickly than it previously did (which shouldn't be a problem, should it?).

Best Regards,

[Milack]

John,

Measuring the output was very useful, thank you!

The frequency I use is very low, around 0.5 Hz, and the application doesn't generate all the pulses at once, it generates one pulse at a time. Between each pulse, the program verifies if the user wants to stop. If that's the case the function returns, if not it generates the next pulse. Using this approach, the user can halt the operation without having to wait until it finishes, and the program always knows the motor position.

However, while measuring the output I found out that the method WaitUntilDone only waits for the last falling edge. For example, if I generate one pulse of 0.5 Hz with 50% of duty cycle, WaitUntilDone will only wait one second, which is the time while the output is in the high state. Therefore, in the case of my application, a rising edge occurs almost instantly after a falling edge, that's why the generated frequency was twice as programmed.

Because of that, it'll be easier to use the old driver, unfortunately.

Anyway, thank you guys so much for your invaluable help!