I needed the weekend to look at this fresh: I guess what the problem is all the "first call" nodes in the express vi. It seems they're used so that the vi can be written to do a single pulse but when called in a loop it doesn't release the resources until the loop is done (the 'stop' boolean is read by the vi) allowing repeated calls without sucking up processing time re-initializing the configuration. I believe it is the 'first call' bits that don't allow the express vi to be re-called as if new in a new loop (the outer for loop) as it would in other languages:
for{
create_task()
while(not done){
generate_pulse()
}
if(task){
clear_task()
}
}
but the express vi, using 'first call' stuff is more like:
create_task()
for{
while(not done){
generate_pulse()
}
if(task){
clear_task()
}
}
None of the initialization code gets called, including creating the task, when using the first call stuff.
I've already written something using the daqmx task stuff that works to my liking, but ran into something that might be a bug.
When using the CO Pulse Time create channel vi and implicit timing, it would seem the task considers itself done (via daqmx wait until done vi) as soon as the high time is up, not after the whole high time + low time. This causes anything wired after the wait until done to start as soon as the high part of the pulse is done. Shouldn't it wait until the entire wave period is finished? Wiring 2 into samples per channel on the timing node causes a full period, but shouldn't a 1 be a single full period? I've been using equal high and low times.
