LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

On the fly updating pulse generation frequency and duty cycle

Solved!
Go to solution

Hello 

 

I have adapted a Labview Example where the frequency of a pulse train can be updated on the fly, so also the duty cycle can be updated. 

The frequency is updated every time I change the value of the frequency control. 

The duty cycle however is (I believe) only updating after I change the frequency.

 

Can someone advice me how to fix this? 

 

Thanks 

 

Kristof Vos 

 

OnTheFlyFrequencyandDutyCycle.PNG

 

 

 

 

 

 

0 Kudos
Message 1 of 6
(3,049 Views)
Solution
Accepted by topic author foxer0101

Briefly, there's no "solution" per se.  Only a workaround. 

 

When you want the duty cycle to change, you'll need to write the frequency too, even if you only rewrite the same value it had before.  (Note: if writing to a property node, it's safest to have the duty cycle above the frequency.  Values are written from top to bottom, and it's the frequency write that actually makes both duty cycle and freq "take hold" in DAQmx.)

 

More info in this thread and the one it links to..

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 2 of 6
(3,038 Views)

 

That makes sense! I'll write as well the frequency as the duty cycle. 
Thanks for your prompt reply!

 

 

0 Kudos
Message 3 of 6
(2,959 Views)

more question on the same issue. 

in this thread (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Mi2SAE&l=zh-CN&OpenDocument=) using change_duty_cycle_write_VI example, the actual duty is not updated, and if use change_duty_cycle_property_node example, Error -200557 occured.

so both method is not correct, as to our hardware pcie-6320 and daqmx17.1.1, labview 2017 f2 in win7 64bit.

also, we change simulated m series board like pci-6259,  the "write_vi" is still not working but the "property_node" method works.

so why this happeds? 

in all threads related this topic, no one lists the detailed driver version, is this the point?

https://forums.ni.com/t5/Example-Code/Generate-a-Continuous-Digital-Pulse-Train-With-a-Variable/ta-p...

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019O8GSAU&l=zh-CN

0 Kudos
Message 4 of 6
(2,530 Views)

I tried both examples with *simulated* devices and saw the following. 

FWIW, I'm using Win7 64-bit, LabVIEW 16 f6 32-bit, DAQmx 18.6 here.

 

Simulated PCIe-6341: the "Write VI" method ran without error, the "Property Node" method produced error -200557.  The 6341 board is an X-series device like your 6320 and results were similar, except my only indication of whether the duty cycle actually changed in the "Write VI" case was the successful property node query.  There's no hardware here to confirm for sure.

 

Simulated PCI-6259: Both methods ran without error and the property node query showed a successful duty cycle change.

 

The KB article you linked seems to suggest that all 4 attempts to change duty cycle on the fly should have resulted in error -200557 due to the use of simulated devices, but I had 3 of 4 apparent successes.

 

I *do* think I recall being in a thread where a particular hardware device supported only the "Property Node" method and threw an error when trying to use the "Write VI" method.  Can't seem to find it now though.

 

Is your 6320 a real hardware device or is it simulated?  When you say the duty cycle was not modified with the "Write VI" method do you mean the property node query, the actual output signal, or both?

 

With real hardware, at least one of the methods should work.  The ability to change pulse timing on the fly has been supported as far back as I remember wanting to try, which I'm almost certain predates Y2K.

 

 

-Kevin P

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 5 of 6
(2,514 Views)
we try both on real hardware, it's ok without any errors. hmmm, so this may be different on real hardware and simulated hardware.
0 Kudos
Message 6 of 6
(2,462 Views)