My LED blink 3 times before entering while loop??

[dytbaat]

Hi Kevin

Yeah sure.. I tried to put on conditional error propes after the write function, also after the create function. But it throws no erros. It just runs right through 😕

\\Peter

[Kevin_Price]

I had a brief chance to try this out myself yesterday with a desktop PCIe-6341 and DAQmx 18.6

Conclusion: I saw much the same thing as you.  With an initial 1 Hz configuration prior to start, then repeated attempts to use DAQmx Write.vi to change it to 100 Hz in a loop as fast as possible, the first 2 loop iterations took about a second each, then the third one started the loop iterating much faster.  Like you, I saw no errors thrown from my (over-) agressive attempts to change the frequency as often as possible.

I experimented with different initial frequencies and noticed that the first couple iterations were directly affected -- i.e., iteration rate seemed to be equal to the initial frequency.

Then I changed the code in the loop to update the frequency with a different method -- by writing to the DAQmx Channel property node for pulse frequency.   Voila!   *THERE* was the behavior I remembered.  An error was thrown on the 1st loop iteration, scolding me for trying to change the freq before the task had a chance to finish making a full pulse with the prior freq.   When I used debug mode to single-step, I was able to avoid the error.  (With limited time, I didn't scheme up a way to determine whether the new freq value was used immediately after writing or whether an additional pulse or two with the old frequency were generated first.)

There's also a deep-down DAQmx property to query whether a counter pulse task is "ready for a new value" yet.

I'm not sure why or when the DAQmx Write vs the DAQmx Channel property method diverged in their behavior.  My take on the DAQmx Write behavior is that it is now more in line with the way DAQmx manages calls to DAQmx Write for buffered analog outputs.  It blocks and waits until there's available space in the buffer to write all the data before returning.  (In older days, you had to manage this timing yourself.  If you tried to write prematurely, you'd create a fatal task error.)

   It seems the behavior is now similar for a continuous pulse train -- the function blocks and waits until it knows the counter is "ready for a new value" before returning.  What remains unclear is why the task generates 1 (or 2?) additional pulses at the prior frequency after that.

So I think the main workaround you can *try* is to change frequency with a DAQmx property node, but *only* after confirming that the task is "ready for a new value".  That *might* enact the new frequency more immediately.  I'm not sure though, I didn't have time to check it out.

-Kevin P

[dytbaat]

Hi Kevin

Okay thank you for trying so hard 🙂 I havent had time my self to work on it lately, but I will post here if I find out anything useful some time. I guess I will try with the property node, but my first thought is that it souldnt be necessary with a workaround. I guess there is something we miss instead.. There must be some kind of explanation on the behavior we dont fully understand. I've been reading alot about the functions, but either its not mentioned, or I mised something. Or its a bug of some kind!

 - Peter

[dytbaat]

Hi Kevin

I noticed a workaround. If I set the create channel to CO Pulse Time instead of Frequenzy it jumps right into PWM. I think its kind of bad though, as its not intuitive to have a Time property in one place, and Frequency in another place. But it works.

- Peter

[Kevin_Price]

I'm a little surprised too.  I'm almost certain I've tried something similar in the past and gotten errors.

As a counter old-timer, I actually *like* being able to mix-and-match the method for defining and redefining pulse timing parameters among Time, Ticks, and Freq/Duty Cycle.  Eventually, all methods just end up mapping to the equivalent of Ticks down in the hardware registers anyway.  But you have to know what you're doing up in the app code to convert *correctly* among them, and I don't fault NI for limiting the options to prevent a support headache.

Having said that, what do you mean that "it jumps right into PWM"?  Did you notice that you never *defined* the Low and High times when you added your counter channel to the task?  The default values are only 10 msec each, so if you're merely watching the code run by eye, the 2 or 3 pre-change cycles would happen too quickly to notice.   See what happens when you define Low and High times as 1 sec each.

-Kevin P

[dytbaat]

Hi

PWM = Pulse Width Modulation. I guess thats whats going on inside the loop. I see you call it pulse timing 🙂

Yes, I actually did notice that when using default values its having a very small "start" impact comparet to default values when I use frequency! But I get that its just two sides of the same story 🙂

 - Peter