01-27-2016 09:13 AM
Hi,
I have a task that contains a pulse generation counter output channel (Device: NI 9402 module on a NI cDAQ 9188 Chassis). I notice that if I change the frequency and duty cycle while the task is running, simply stopping the task and starting it again resets the duty cycle and frequency. I have modified the Ansi C example titled DigPulseTrain-Cont.c that ships with NI-DAQmx to implement the following workflow:
1) Create a task
2) Set the counter output duty cycle to 0.1
3) Set the counter output frequency to 100
4) Start the task
At this point, we see a square wave being generated at 100Hz with a 0.1 Duty cycle
5) Change the counter output duty cycle to 0.001 without stopping the task
6) Set the counter output frequency to 100 (unchanged) without stopping the task
The Duty cycle of the square wave now changes to 0.001
7) Stop the task
😎 Start the task
The Duty cycle of the square wave now changes back to 0.1.
Similar behavior is observed when one changes the counter output frequency. Is this intended behavior? If this is unexpected behavior, can you provide us a CAR number so that we can track this.
Thanks,
Varun Hariharan
MathWorks
01-28-2016 02:58 PM
Hi vharihar,
We would recommend that the task is stopped before the duty cycle or the frequency is updated. This may be why the value is set to the old duty cycle when the task is stopped and re-started. For more information on changing the frequency while the task is running you can look at the KnowledgeBase article linked below.
Changing the Frequency on the Fly: http://www.ni.com/example/30493/en/
Best Regards,
Andy
Application Engineer
National Instruments
02-03-2016 08:21 AM
Hi Andy,
Thanks for writing back to me. I’m not able to review the page, as the example provided is coded in LabVIEW. However, the following page contains a description that indicates it is possible to update the frequency and duty-cycle without stopping the task:
https://decibel.ni.com/content/docs/DOC-3613
I think the difference is that, in the above example, the task is always reconfigured before start/stop, so you won’t observe the behavior we are seeing (because we start/stop/start again, without reconfiguring). This suggests that there is some state that the task can be in where it is possible to have the configuration of a counter persist.
After reviewing the documentation about states, it seems that this should be the “Committed” state. This same page also suggests that I shouldn’t be able to program the counter in this state.
Is it is possible to change into a state where the frequency/duty-cycle values are malleable, and then change the state back to “Committed”? Please let me know if I have an incorrect understanding of this.
Thanks,
Varun Hariharan
MathWorks
02-04-2016 01:25 PM
Hi Varun,
I think what the community example is referencing is that you will receive an error if the current frequency value is the same as the updated frequency value. I would expect an error to occur when you update your frequency to 100. That is why they have a case that only updates the property node when the value has changed, in the example. One thing that it may be helpful to try is implementing functionality siimilar to the code under LabWindows/CVI in the link below. It may be worthwhile to try to use DAQmxSetChanAttribute.
KnowledgeBase On the Fly Frequency Control: http://digital.ni.com/public.nsf/allkb/7B1B0427C39FE33086256CEE00752133
Best Regards,
Andy
02-11-2016 10:39 AM
Hello Andy,
I tried using DAQmxSetChanAttribute. I am not able to find any documentation on how to use this. I have updated my C program to use that function (based on the example) instead of DAQmxSetCOPulseDutyCyc. This does not change the duty cycle at all. Is there something that I am missing? I have attached my updated C program.
Thanks,
Varun Hariharan
MathWorks
02-12-2016 02:11 PM
It looks like the forum post linked below has some more information on the DAQmxSetChanAttribute.
DAQmxSetChanAttribute Documentation: http://forums.ni.com/t5/Measurement-Studio-for-VC/Documentation-about-DAQmxSetChanAttribute-and/td-p...
Andy
02-12-2016 02:14 PM
Hi Andy,
That is the page that I used while rewriting my C program. Is there a equivalent function that is documented and supported by NI?
Having said that, I still am not able to get my program to work as expected.
Regards,
Varun Hariharan
MathWorks
02-12-2016 02:36 PM
I spoke with some of my colleagues, and it looks like this it will not be possible to update the DAQmx task while the task is running and have the information be stored in the task when the application is stopped and re-opened. This is caused by the Task STate Model of DAQm which is linked below: Task State Model.
Task State Model: http://zone.ni.com/reference/en-XX/help/370466AC-01/mxcncpts/taskstatemodel/
The DAQmx task properties are updated in the Committed state. When you update the properties while the task is running, the properties will update but will not be saved. When the task is stopped the properties revert back to wait was last in the committed state. Also, you cannot set the task into the committed state while the task is running.
The best option is to save those new values, and update the task again once it has been stopped.
Best Regards,
Andy
02-25-2016 05:12 PM
Hi Andy,
I tried setting the DutyCycle and the Frequency after the task has been stopped and before it is started again and noticed that it does not solve my problem.
Here is my workflow:
1) Configure the task with DutyCycle D1 and frequency F1.
2) Start the task
3) Update Duty cycle to D2 on the fly (without stopping the task)
4) Stop the task
5) Since D2 is not maintained. Configure the task with DutyCycle D2.
6) Start the task
7) The generated pulse has frequency F1 and DutyCycle D1.
I have attached my C program. Please let me know your thoughts.
Regards,
Varun Hariharan
MathWorks
02-26-2016 10:35 AM
Hi vharihar,
Can you try to update the Duty Cycle on the fly when the DAQmx Task is started for the second time? This will give us more information on if the DAQmxSetCOPulseDutyCycle is updating the second time. Also, I just want to clarify that the duty cycle of the task is still updating on the fly.
Best Regards,
Andy