Pulse Generation Duty cycle and frequency reset on stopping and starting the task

[vharihar]

Hi Andy,

I am able to update the duty cycle on the fly the second time as well. I am calling both DAQmxSetCOPulseDutyCyc and DAQmxSetCOPulseFreq everytime I need to make updates. 

Calling only DAQmxSetCOPulseDutyCyc does not do the job. This was always the case. 

I have attached my C code. 

Thanks,

Varun Hariharan

MathWorks

[tic.not.tock]

Hi Varun,

Is there a reason you need to stop and start the same task everytime? Based on the task state model, you will set the propertites when it is verified and when you stop the task you only return to the comitted state. Starting the task again will cause the initial variables to be restarted.

Would it be possible to save the new inputs you have changed on the fly as variables? Then you can clear the task and create a new task with the variables.

Best Regards,

Andy

[Kevin_Price]

Varun,

I'm a LabVIEW guy so I can't comment on specific syntax for the text-based daqmx function library.  Here are some nuggets from a long time working with DAQmx and NI hardware.  

1. For some reason, when changing pulse specs on the fly, one of the two specs gets preferential treatment.  In the case of frequency and duty cycle, frequency gets the preferential treatment.  What I mean by that is that the actual specs only "take hold" when the preferred attribute is updated.  You referred to this observation when noting that attempts to change only the duty cycle didn't seem to have any effect.

    In apps that want to vary only the frequency, only the frequency needs to be written.  In apps that want to vary only the duty cycle, both duty cycle *and* frequency need to be written.   The same idea holds true for pulse specs defined in terms of high and low time (or ticks), though I don't recall whether the high or low part is dominant.

2. The task state model *can* be helpful here to speed up the time it takes to stop and then restart a pulse train.  If you commit the task before starting it, then the subsequent stop will unwind only back to the commit state.

3. You *can* change pulse specs while the task is in the commit state. 

4. Observations from simple testing in LabVIEW:

• Configure pulse train with d1, f1 duty cycle & freq
• commit task
• start task
• change to d2, f2 on the fly
• optionally stop task, change to d3, f3 while task is reverted to commit state, restart task
• stop and restart task without further changes to d & f
• query d & f
• stop and clear task

When the optional step is skipped, the query shows me that I'm producing d1, f1.

When the optional step is performed, the query shows me that I'm producing d3, f3.

It appears that updating the pulse specs while the task is in the commit state causes these new values to be persistent for subsequent stop/restarts.  I would echo the following suggestion Andy made: store your on-the-fly pulse specs in a variable, rewrite *both* of them while the task is stopped but still in the commit state.  They will be used on the subsequent restart *and* it appears they will persist as your new default for subsequent stop/restarts.

-Kevin P

[vharihar]

Hi Andy,

Clearing and recreating the task every time is not a feasible solution because this involves the resetting of properties of the task which can be time consuming. Is there a solution that does not involve clearing and recreating the task? Would NI consider adding such a feature in the future?

Thanks,

Varun Hariharan

MathWorks

[tic.not.tock]

Hi Varun,

Unfortunately, it does not look like there is a different feasible solution. This is not functionality that is possible with NI-DAQmx because it conflicts with the task state model at the core of DAQmx.

If this is functionality that you would think be helpful to have in the driver, in future the best course of action would be to post on the NI Idea Exchange, linked below. This page is actively monitored by Research and Development and is the best location for functionality requests.

National Instruments Idea Exchange: http://forums.ni.com/t5/NI-Idea-Exchange/ct-p/ideas

Best Regards,

Andy M

Applications Engineer

National Instruments

[Kevin_Price]

Varun,

Have you been able to try the method I outlined previously where you *commit* the task before starting it for the first time, then subsequently use only Stop and Start rather than Clear and re-config?

I had success being able to write new pulse specs while the task was stopped, and they appeared to remain persistent as default values.

-Kevin P

[vharihar]

Hello Kevin and Andy,

Thanks for helping out. The problem here is that I am forced to set my frequency to a new value when I update my duty cycle. There are specific cases where I do not want to change my frequency. So if I re-set my frequency to the same value as what is currently present on the task, this does not work.

Consider this workflow: 

1) Configure with d1, f1

2) Commit task

3) Start task

4) Update to d2, f1 on the fly (Calls are made to both DAQmxSetCOPulseDutyCyc and DAQmxSetCOPulseFreq)

5) Stop task

6) Update to d2, f1 (Calls are made to both DAQmxSetCOPulseDutyCyc and DAQmxSetCOPulseFreq)

7) Start task (This shows d1,f1)

This does not work. It looks like there is some optimization internally that makes this look like the frequency is not set along with the duty cycle. As a result, my values are not stored. If in step 4, I update to d2,f2 instead, I see d2,f1 in step 7. I think this optimization is a bug since it prevents me from configuring my task with the duty cycle, frequency pair that I would like. 

Regards,

Varun Hariharan

MathWorks

[tic.not.tock]

Hi Varun,

It looks like this is intended functionality for DAQmx. NI-DAQmx requires that when you update the duty cycle of a pulse train, you must also supply an update to the frequency. Take a look at the KnowledgeBase Article linked below.

How can I change the duty cycle of my Continuous pulse train?: http://digital.ni.com/public.nsf/allkb/82C9F3C15F62974E86256EBA0058CAF5

Best Regars,

Andy M.

[Kevin_Price]

Followup question:  the KB article suggests to re-write the same freq value with a different duty cycle when you wish to change only the duty cycle.  So far, so good.  I've done this to run PWM control on things and know that it works.

Varun's latest message says that things don't act the same way if freq & duty cycle are written while a task is stopped but committed.  That isn't the behavior *I* would expect.

Varun: have you tried the workaround where at step 6 you first update to d2,f2 then right back to d2,f1?   Does that fool the apparent "optimization"?  I'm not near hw where I can fiddle around now.

-Kevin P

[Krid]

I ran into the same problem. When the task is stopped it's not possible to update the duty-cycle by writing a new duty-cycle-value along with the old frequeny value. So if you want to keep the frequency value as it is, you first have to set some random (different) frequency value and then set the frequency+dutycycle pair you really want. This is so ridiculous it can't be intended behaviour.