Error -200459 at DAQmx Write.vi for finite pulsetrain task

[Kevin_Price]

There may be a lingering DAQmx bug similar to the behavior observed in this discussion?  I find that trying to set counter pulsetrain frequency with DAQmx Write produces a -200459 error, but if I use a DAQmx Channel property node instead there's no error and I get proper output signals.  A key difference in my case is that my task is *stopped* when I set the frequency.

Environment: LabVIEW 8.20, DAQmx 8.3.0, PXI-6602 board.

Code: I've set up an Action Engine for a motor controller including a finite pulsetrain counter output task to specify distance and a couple of DO bits for direction and enable.  I create the finite pulsetrain task once and save the task in an unitialized shift register.  I can't post the actual code for this project, but here's a screenshot:

The idea is that the application code can request a "Move" for Distance d1 at a speed of s1.  After completing the motion, the task is stopped (not cleared).  Later the app code can request a different "Move" for distance d2 at a speed of s2.

The specific code for this is to bring the finite pulsetrain task out of its left-hand shift register and first set the new freq/duty cycle info, then call DAQmx Timing to set the new '# samples' value according to the desired distance.  Thus far, I have only configured DAQmx Timing for "Finite Samples". 

However, I found that trying to use DAQmx Write to set freq / duty cycle produced the error -200459.  When I instead wrote the same values to the DAQmx Channel properties for freq / duty cycle, all was well.

FYI...

-Kevin P.

Message Edited by Kevin Price on 04-19-2007 07:13 PM

[Kenn_N]

Hey Kevin,

    Thanks for contacting National Instruments support.  According to the DAQmx help you can call the property node you reference during task run-time for TIO devices which the 6602 is part of.  This would be the preffered method of changing the frequency of your pulsetrain.  I would be interested to know if the Write works without stopping.  But I would be willing to report that as feedback to R&D if it doesn't work.  I'll work on recreating it, and any more information you find would be helpful. 

Regards,

[Kevin_Price]

Neither method works with the task running -- because it's configured as a *Finite* pulsetrain.  My understanding of that is that the adjacent counter's single "gating" pulse is timed based on the pre-start values for freq & # samples, which is why DAQmx doesn't allow freq change on-the-fly for Finite pulsetrains.

Since I've got a workaround, my main question is whether I can count on it for the future.  In other words, is it a bug that DAQmx Write fails or is it a bug that the DAQmx Channel property "frequency" succeeds?  

My worst-case workaround would be to fully Clear the DAQmx task and then re-Create with a different frequency.  I know this carries a lot more overhead which is why I prefer to Stop and re-Start. 

Is there a different preferred method or sequence to accomplish the needs of my app?  Restating, the main app will need to generate a variety of different Finite pulsetrain bursts at different times.  Both the freq and the # pulses will vary from one burst to the next.  I'd like to perform the re-config in the most efficient manner possible, which I've assumed is something other than Clearing and re-Creating the task.

Thanks!

-Kevin P.

[Kenn_N]

Hey Kevin,

Thanks for the reply,  I also see the same results you do.  In fact you can't call the write vi anywhere in a Finite Pulse generation task.  And yes I did miss that in your original post.  So the error is basically saying that you can't call write on a finite generation at all.  Albeit, in a cryptic manner. 

So the preferred method in either situation, continuous or finite is to use the property node.  I have spoken with R&D about whehter we should change the error messaging, or just change the write to make it work in a finite situation.  But it's kind of an odd case since, the "write" vi is usually associated with writing data and not a property like frequency, but in a counter output task, that is the data you are writing.  It's a subtle distinction. 

In closing, to answer the question, it is not a bug that the property node succeeds, and at the moment, it is not a bug that the write fails, but it could be messaged better. So if you can use the property node in your app then that is the most effective method.

Regards,

[Keno]

Hello all,

Old topic but I'm getting the same error message, in the same conditions.

The weird thing about that is that I get the error in one vi but not in a different vi...

Is someone understand this ?

Thans in advance

Best regards from France

[Chris-G]

Hey Keno,

I tried duplicating your code based on your screen shots and didn't get an error in either case. What else are you doing in the second case structure in the BD that might be throwing an error? Likewise where exactly is the error coming from? Also, notice that the previous posts were generating a finite pulse train, whereas you are generating a continuous pulse train. This may be why using the DAQmx Write subVI is working, because this allows the user to change the duty cycle/frequency while the VI is running without using a property node.

Chris G

[Keno]

Hello Chris,

Thanks for your answer...Actually I solved the problem : it was due to the fact that I have connected the element "Echantillons continus" at the wrong place...Now everything works just fine! Thanks anyway for your answer

Regards