From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Error -200088 append
@Kevin_Price wrote:
The following trivial usage of your AE ran without error. Like GerdW, I think the problem is in the application code you have that calls your AE. The AE itself is ok.
-Kevin P
I actually got the same error as willcan in running the AE alone in LabVIEW 2019. It worked when I explicitly created a task prior to creating the channel. I did find that when I called it in an application like you did that it worked without error. I find that to be strange. I first thought that LabVIEW was releasing the task in the AE when it stopped running, but then saw that the task was not being created. This led me to explicitly create the task. The behavior seems odd to me, but I agree that it appears to work when used in its proper context.
@Kevin_Price wrote:
FWIW, in over 15 years of using DAQmx I've almost *never* used DAQmx Create Task. I pretty much always start with Create Virtual Channel with no task refnum wired in on the input side. While not at all harmful, I also don't think it's gonna be a necessary part of the solution.
Way back in the days of traditional NI-DAQ, one could run DAQ-related AE's successfully in stand-alone mode. But DAQmx does auto-cleanup of task resources when execution ends, which is why you can't do stand-alone testing of a DAQmx AE.
This isn't anything new, I was posting about it almost 15 years ago. I suppose that's why I never even considered testing the AE in stand-alone mode and opted to make a trivial app-level usage.
-Kevin P
I don't know that I've ever even considered making a DAQmx Action Engine. I just saw that the OP was running the AE in standalone mode and getting the error - the only reason I tried it that way. I had assumed that it was a clean-up issue, but when I put a probe on the task wire coming out of the Create Channel vi the task was empty, at least in LabVIEW 2019. I expected to see something there, and something coming from the start task, but nothing when I ran it again to write.That's what intrigued me and got me to investigating.
Hi willcan,
@willcan wrote:
The same error you also got ah ? even in AE itself .
That's why i also struck up and weird thing .
Explicitly you created task means , you created a task in NI Max ah ? is it works ?
Use DAQmxCreateTask before DAQmxCreateChannel…
@willcan wrote:
what was the need of ...for loop in this case to run for 10 times ? please advise
Just to demonstrate the usage of that AE - as I have asked from you several times…
@GerdW wrote:
Hi willcan,
@willcan wrote:
The same error you also got ah ? even in AE itself .
That's why i also struck up and weird thing .
Explicitly you created task means , you created a task in NI Max ah ? is it works ?
Use DAQmxCreateTask before DAQmxCreateChannel…
Yes, this is what I meant, but I'm not sure why it worked, and if you're having trouble using the AE as is (in a running program) then perhaps if you would show a minimal example of a program using the AE and not working you could receive some help. As has been stated, your AE does work when called within a program. This issue is with LabVIEW cleanup. My "fix" may only be a band-aid to the problem of the AE not working standalone, and likely will not fix your larger problem.
@Kevin_Price wrote:
However, this thread prodded me to learn something new in DAQmx. I generally never use "DAQmx Create Task.vi" so I'm just now seeing that it has an optional input related to automatic cleanup. By default it's False, which is why johntrich1971 was able to test the AE in stand-alone mode when he added it. When set to True, you'd see the same error when trying to test in stand-alone mode due to the auto-cleanup occurring between runs.
I'm inclined to recommend *against* regular use of "DAQmx Create Task.vi", especially for newer DAQmx programmers. There are only some relatively rare use-cases where keeping a task active and persistent after execution ends is a worthy goal. It's far more likely to be irrelevant at best, and potentially quite troublesome.
2 possible troubles:
1. You start up a continuous output task that operates some equipment. Then you exit your app in a way that never stops or clears the task explicitly on the way through the shutdown process. Your app is now done, but your devcie would continue to generate its continuous output signal and run the equipment.
This could be quite hazardous!
2. Any task that's left to linger persistently after the app exits will probably prevent a new run of the app. When the next run attempts to set up the same set of tasks again, there are going to be resource conflicts because the I/O channels are already tied up in that old persistent task. In general, I'm not sure how you'd get yourself out of this situation short of a call to reset the board. Troublesome, annoying, and should be unnecessary.
<a little time passes> I just did a quick experiment with OP's AE "DO Main.vi". Sure enough, I added "DAQmx Create Task.vi" while leaving "auto cleanup" at its default of False. Then I ran in standalone mode. The first "initialize" run completed without error. An attempt at a second "initialize" run produced error -200587, related to the kind of resource conflict I expected.
Takeaway lesson for me: CONTINUE my habit of not using DAQmx Create Task.
-Kevin P
You know, I had never paid attention to that input on the DAQmx Create Task either. Thanks for the explanation about why it worked after adding that.
This led me to another curiosity. I know that some set up tasks in MAX and then use those tasks in their program. I don't know that I've ever done that as I prefer to have a more dynamic DAQ. I suspected that doing so would also make the AE work standalone. I tested this with creating a task in MAX and using that for the task input for the DAQmx Start Task. The AE did work in standalone mode, as expected.
