@Sean F wrote:
Hi Tech,
Thanks for answering, Dennis. Tech, keeping the task in a shift register will make it accessible to future loop iterations. This is particularly useful when implement a daqmx task in a state machine. For some more info on state machines, check out this tutorial. Also, why do you have to have daqmx tasks inside loops? Perhaps there is a better way to do this.
Best,
I don't see how keeping the task in a shift register will solve the problem of having to keep track of the association between the initialization and the task. They will still be separate objects. It also appears to be unnecessary to use a shift register, since what I do now with the initialization outside the loop is to just connect directly to the task inside the loop, with no shift register involved.
I briefly looked at the description of the State Diagram Tool kit. It appears to be suitable for "large scale application development". What I am doing does not qualify as "large scale application development", and my Basic LabView Development system does not have the State Diagram Tool kit. Even if I had the State Diagram Tool kit, a state machine is far too complex for the simple applications I am developing.
I develop small applications which exercise various components to determine low long they last and how they ultimately fail. This requires simultaneously stimulating the components and collecting data regarding their performance via a multifunction DAQ card until some (usually very large) number of cycles has occurred or some error threshold is reached. The logical way to do this is to put the stimulation and data collection sub-vis inside a loop and run until whatever. However, the initialization can not be put inside the loop because the overhead involved causes the timing relationship between the stimulation task and the data collection task to become unpredictable.
The result of this is (apparently) that LabView code that contains associated DAQmx initializations and tasks can not be encapsulated in a sub-vi and then subsequently be used inside a loop. This seems to break the LabView paradigm of being able to encapsulate any piece of code into a sub-vi. If a sub-vi containing DAQmx initialization is buried several layers down in a program and it must be put inside a loop, it can be very difficult to break out the initialization part and provide a data path for its output back to where the task it creates is supposed to be executed.
