Is there a way to control the timeout of the DAQmx Start Task VI?

[tst]

So I tried playing around with various options (Reserve chassis, stop task, clear task, start task), but whenever I removed one or more of them, I kept running into various errors after network or power reconnects. I tried writing down which errors happened with which setup, but it got to be too much, as the errors kept changing.

I ended up with the following setup, which seemed fairly robust during my testing:

1. Ping the unit (the address is a parameter, since I couldn't seem to extract it from DAQmx). You can find various VIs which implement pinging online.
2. If no error, Reserve the chassis using DAQmx Reserve Network Device.vi with override reservation? set to true.
3. If no error, For each task, call:
   
   1. DAQmx Stop Task.vi
   2. DAQmx Clear Task.vi
   3. DAQmx Start Task.vi
4. If no error, run the tasks. Once there is an error, stop all of the loops and repeat.

If there is an error during the task (at least the DI task, which is set to read one sample on demand), it looks like the timeout input isn't respected and it takes 10 seconds before the DAQmx read finishes, so it's a good thing I have my separate watchdog. This allows the rest of the program to know of a timeout error within a second, which is good enough for this. As long as the response there is reasonably quick and the reconnecting mechanism is reasonably robust, I'm OK with it being slower, even if it's not the most elegant behavior.

[Kevin_Price]

 That's a very curious sequence of DAQmx calls you've arrived at, especially on the very first call.  Stopping and Clearing a task that hasn't yet been started seems odd.  (I'm also pretty sure that Stopping an unstarted task *used* to be an error, or at least a warning.  But a quick test now using DAQmx 20.1 said otherwise.)

   I'd be inclined to followup chassis reservation with:

A. Start all tasks

B. if no error, proceed to "run" them all (I assume you mean service the task data by looping over Reads and/or Writes)

C. If either step A or step B produce an error, stop all tasks (and maybe you'll find you still also need to clear them), and *then* loop back on the whole setup process including pings and reservations.

  I'd also be cautious due to Jay's warnings in msg #8 about calling Clear on a persisted task.  Do you have any notes on what error(s) happen when you merely Stop and Start without a Clear in between?   

   Some of the resource clearing that happens on a call to DAQmx Clear is asynchronous.  I've been in another thread or two where attempts to reconfig a task too soon after clearing would produce occasional "resource reservation" errors.  A small time delay between clear and reconfig prevented them.   I've never seen any analogous problems from using just Stop and then Start.

-Kevin P

[ThomasHenkel]

---

@tst wrote:

1. Ping the unit (the address is a parameter, since I couldn't seem to extract it from DAQmx).

---

Maybe this works for you.

[tst]

---

@ThomasHenkel wrote:

---

@tst wrote:

1. Ping the unit (the address is a parameter, since I couldn't seem to extract it from DAQmx).

---

Maybe this works for you.

---

Interesting idea, but the first node returns a -201003 error (Device cannot be accessed) when the device is offline, so no go. I also gave it a quick try with the system config API and got an error -2147220623 from it (NI System Configuration: The property does not exist for this resource.)

Having it as a separate parameter is actually OK in this case, as this will be a static IP address and won't change. It would have been nice if this was something which could be extracted from the DAQmx device data, but I'm not actually sure that the data is there. It's possible this is stored only in the device and is only acquired dynamically from it. MAX does seem to remember the last IP address in the main Settings tab, but when I try to open the Network Settings tab, it does try to load it from the device.

[tst]

---

@Kevin_Price wrote:

 That's a very curious sequence of DAQmx calls you've arrived at, especially on the very first call.  Stopping and Clearing a task that hasn't yet been started seems odd.  (I'm also pretty sure that Stopping an unstarted task *used* to be an error, or at least a warning.  But a quick test now using DAQmx 20.1 said otherwise.)

Fair enough. While it's not uncommon for me to do this (make sure you release/clear the resource before starting), you're right that it does make more sense to move it to the end, so I modified the code now. I ignore the errors from the clearing anyway.

If I don't have the clear VI, then I get error -50405 when calling start task (No transfer is in progress because the transfer was aborted by the client. The operation could not be completed as specified) and this persists through a device reboot.

When I do call the clear VI this doesn't happen. In this case, the code did seem to be robust even with the reservation, but I'll leave it on, because I see it doesn't happen automatically (for instance, if I explicitly unreserve the device in MAX). It does take a bit more time, but at least I only try it if I can actually ping the device.

I haven't seen now the other various errors I saw in the testing before, and I'm not sure what the difference is, other than that I'm not stopping/clearing before starting. Maybe DAQmx really doesn't like that.

So right now this is the apparently stable setup:

1. Ping until no error
2. Reserve until no error
3. Start
4. Read/write until error
5. Stop and clear

An error in the start or R/W states sends the code to the stop state, which then goes back to the ping.