Occupied resource error with DAQmx channel generation.

[sburt0n]

Hi guys,

Long story short is I'm trying to modify my labview code so that I can run a stepper motor in both continuous and single stepping mode. I have created a finite state machine to deal with both cases only I get this really irritating error when transitioning from continuous mode to single stepping mode. Here is the continuous mode state. 

Sorry the image is a bit large to fit the whole thing. To the far left before the start task a continuous pulse train is applied to a counter pin on the NI elvis 2 which sends the signal to the step pin of the stepper motor driver IC. The number of samples per channel is then set before the task is started and the loop is executed and the stepper motor steps continuously at the prescribed frequency. When I press the "Halt continuous stepping" button the loop stops and so one would expect the loop to stop the task and clear the channel before the next state "single" gets sent to the shift register. 

The image below is the single state of the FSM:

And so when I go to hit the "step button" I immediately get the following message shown below:

Which is the reason why I put that flat sequence before sending the "single" state to the shift register. I thought it might ensure that the channel was clear before executing the next stage and creating the new channel. I have no idea how to fix this, when I ran it in highlighted execution mode it executed properly when I pressed step so why does it say that the resource is busy when run at normal speed. Also I did have a name for the task so I really don't know why it said the task was unnamed. 

If anyone could offer me an explanation for this error in order to help me debug it I'd greatly appreciate it. 

[Kevin_Price]

This is gonna be a little vague and "hand-wavy", but I think we'll get things working for you.

1. I've learned from experience that a call to "DAQmx Clear" may return control to the app before *all* the resource-freeing jobs are completed.  I've seen immediate attempts to create tasks with the same resources fail, but they succeed if there's a short delay before trying.  I've posted a bit about this before (Caution: long, dense discussion that spans other issues as well)

2. I'm gonna suggest a Stop-Reconfig-Restart sequence rather than Stop-Clear-Create-Config-Start sequence.  Get rid of your DAQmx Clear and the subsequent DAQmx Create Virtual Channel.  To do this you'll need to carry your DAQmx task refnum through from state to state via shift register.

3. I think that oughta be enough to get things running.   That's a start, but only if you always alternate states with continuous stepping first (where the task gets created), and single stepping second (where the task gets cleared).

4. Longer term, you should probably create a state dedicated to creating the task and another one dedicated to clearing it.  Then you can have a more robust state machine where each state can reconfigure, start, and stop the same task ref over and over.  This lets them execute in any order, independently of one another.

5. An alternative is to stick with your original structure where each state both creates and clears the task.  But you'll need to code around the issue where it takes a little time after calling DAQmx Clear before you can be *sure* to have access to the task resources again.  My preferred approach is to iterate over task creation a limited number of times in a For Loop with some delay between iterations.  I terminate the loop on "no error", but otherwise ignore errors within the loop.  I feed the error to the output tunnel in "Last Value" mode.

-Kevin P

[sburt0n · Accepted solution]

Thanks for your help,

I still had some issues trying to reconfigure virtual channels in the different states of the state machine and found in the end it was better to simply generate the pulse train for continuous stepping in one state and in the next simply use a DAQ assistant inside a while loop in digital out mode. A button was wired to this DAQ assistant setting it high for one iteration of the loop if pressed and when it unlatches in the next the port goes low stepping the motor once.