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

[tst]

I have a system with an Ethernet cDAQ chassis which has 3 tasks (DO, DI, AI), which goes something like this:

Basically, stop and clear the tasks and then start them. If all tasks started successfully, run the actual code with DAQmx write/read in a loop until there are errors, then repeat.

I want to handle comm. errors and the problem I'm facing is that when I tried to simulate this situation (by simply disconnecting the cable either before the connection or during), I see that the both the DAQmx read and write VI and the Start Task VI take a long time to recognize this error, which means it takes a long time for me to recognize that I have the problem.

For the read and write VIs, they have a timeout input, which seems to help somewhat (although the comment I wrote when testing this seems to indicate that the timeout doesn't always work). For the start task VI, I couldn't find a way to make it faster.

My understanding is that I could try reserving/committing the task, but I expect that wouldn't help if there is no comm (I don't have the hardware to test at the moment). Looking at some older code we have for networked cDAQs, I see that we reserved the chassis, but there are no comments there and I don't currently have access to the commit logs or to the person who worked on it to check if this was because of similar issues.

Does anyone have any concrete suggestions for how to handle this? The only idea I have at the moment is to have an external loop which will wait for notifications from the IO loops. If that times out, it can assume that there is a comm. error.

[mcduff]

For the Read DAQmx VIs I use something similar to a timeout to show a communication error. I use the DAQmx Event "Every N Samples Acquired into Buffer". This event should fire every ~100ms. Before starting the task, I change the timeout of my Event Loop to a value greater than 100ms. (This value depends on the task; high sample rate tasks can skip quite a few events.) If my timeout case executes in the event loop, then I assume a communication error. It works, but not sure if it has the latency you need. It would be nice if there was a Event for plugging/unplugging an instrument.

[JÞB]

Surprisingly that is not possible!

Now we need a work around to detect what you are really trying to accomplish.  I'm going to assume you want to fail gracefully and with error when the network connection is bad.

Any state change to a Ethernet cDAQ device is going to fail (including Abort!) with the default TCP/IP timeout (60000mS) and throw some error.  so we need to find some other means to attempt a connection to the device

Try This 

STRANGE Edit >>Select All missed a wire segment! 

Obviously you want to wire the control to timeout ms of TCP/IP Open Connection.  Choose a reasonably low value and close the connection afterward.  If all devices are in the same chassis you should only need to verify one connection.

You might observe the DAQmx Device Property Node has NO INPUT to select the device.  Device selection is done with a filter selection from a right-click as seen below.  You'll want the bottom option to show properties for only the device you wish to test.

I have ZERO hardware available so let me know what you learn.

[tst]

---

@JÞB wrote:

so we need to find some other means to attempt a connection to the device

Try This 

---

Well, that presumably won't work, since you need a port the unit listens at (although maybe it does have a web server at port 80 for the config UI), but that reminded me that one of the other ideas I had was to ping the unit, so if no one else comes up with a solution, I expect I will do something like:

1. Ping with a short timeout.
2. Once I get the ping, reserve/start/whatever.
3. Once all of those succeeded, run the read/write code.
4. Have a separate loop to monitor the progress of the other loops, to catch the timeout quickly.

[tst]

---

@mcduff wrote:
For the Read DAQmx VIs I use something similar to a timeout to show a communication error. I use the DAQmx Event "Every N Samples Acquired into Buffer". This event should fire every ~100ms.

I haven't worked with DAQmx events in the past. I assume you mean that if the event fires you then call the DAQmx read VI. This could possibly work, but it probably has the theoretical problem for the read that the event fires and when I go to read, the read still takes a long time for some reason. Hopefully that's not the case if the buffer is already on the computer side, but I don't know how that works.

Also, it won't work for the write VI, where I could get a similar error.

[Kevin_Price]

I'm no help on the Ethernet cDAQ aspect of this, but a couple things look kinda funky to me about the DAQmx task handling.

---

---

1. Despite the online help declaring otherwise, DAQmx Stop and DAQmx Clear do NOT follow standard "error in" behavior.  They execute unconditionally, regardless of any incoming error.  So you don't have to avoid wiring the error input or clearing errors before calling them.

2. Once you call DAQmx Clear, all the resources associated with the task in question get unreserved.   I wouldn't expect you'd be able to simply call DAQmx Start with the same task refnum after that.   It'd be like using a ref to a queue that was already released.

    Or maybe you're using pre-defined tasks from MAX or your project?  I never do that -- I build up tasks from physical channels on the diagram and I know I can't use a task refnum after clearing it.

3. I'd venture that you probably don't need to call DAQmx Clear though.  Since there's no change to the task config before you start it again, it's sufficient to simply call DAQmx Stop and then DAQmx Start.

4.  With PCI / PXI DAQ devices, doing a "commit" before the first start will make subsequent stop / restart cycles more efficient.  It's probably true to some extent for USB and Ethernet bus devices as well, but it may be a negligible effect compared to the other latencies involved with external devices.

    (I realize your intended purpose for "reserve / commit" was just to test device connection integrity, but I figured I'd pass along the extra tidbit about efficiency in case you didn't previously know.  More info here.  Also, JÞB  knows some finer details about where those docs are incomplete or wrong.)

-Kevin P

[tst]

So here's what I came up with so far with limited testing:

1. Having my own watchdog works very well for detecting the error quickly. It's just a parallel loop which waits on notifiers with history with a short timeout. If a notifier was true or there was a timeout, there's an error. Otherwise, everything is OK.
2. The ping definitely helps as a first check, as it can timeout quickly. I will have to see how I know the IP address to ping, but that should be easy enough, as it will probably be static and can just be a param. Using the method J suggested doesn't seem to work, as even when the device is online and I select it in the filter, calling the property returns an error "(arg 1) <B>Device Specified: </B>empty string".
3. Kevin is correct that I probably don't need at least the first clear error, but that's just defensive. I do it automatically if I release a resource and then acquire it. The second one, at least is needed.
4. As for just calling the start VI, my tasks are indeed configured in MAX, so I just call them by name. The tasks are simple enough and I haven't seen a good reason to write more complex code, but my experience with DAQmx is limited.
5. It's still unclear to me how much I actually need to reserve or clear. The behavior I've seen is inconsistent, as at first the code managed to run properly with reserving the chassis (which is probably not actually needed). Then, when I removed the stop and clear calls, I got error -50405 (No transfer is in progress because the transfer was aborted by the client) at the start VI. And after putting just the clear back I got error -201003 (Device cannot be accessed) which has now persisted through a device reboot, through stopping and restarting the VI and through reenabling the original code (reserve, stop, clear). I'll probably have to close the project and restart, but that will wait for another day. I'll try to update once I've stabilized the system.

[JÞB]

OK, since Kevin called me a DAQmxpert I re-reviewed some old notes and pulled up a simulated 9189.  I'll address some points you might consider and give you a bit of my hard earned knowledge. That seems only fair considering how tolerant the forums were when I was a newbe.

• That "Clear Task" is a very DANGEROUS choice.  I strongly recommend you remove it. Lets take a look at the DAQmx State model (Go ahead and expand it) I want to speak a bit on the "Unverified" Pseudo State.  It does not truly exist!   By that I mean that MOST attributes and properties of a TASK are verified when they are initially set.  There are a few co-dependant settings that cannot be verified individually but, whenever you use the DAQmx Wizard to create a Task the Task is fully verified when created.  So, when using a MAX or Project Task the Task is verified whenever it is loaded.  Clearing a Task that is persistent in memory loads a very big gun!  SOMEONE ELSE is going to say "Oh that JÞB guy is full of  bull, and since Kevin, Tim, and everyone else says don't use persisted Tasks!" Then they are going to find the Task constant and select "Generate Code >> Configuration" from the Right-click menu and "Poof" your VI that calls "Clear Task" actually DOES clear the Task! Zap! the Task is wiped from memory and all those Dup Tasks are dead dead dead.  One simple upstream change cost you half of your remaining hair.
• The DAQmx Device Class Property node.  This appears to be a topic someone at NI should chime in on.  For now I'm sorry I even mentioned it! Don't use it! It doesn't do what I thought it might do. Or it does it so wrongly that NI should probably create a half dozen internal memos and assign responsibility to a largish group of developers to rethink that.
• ALTERNATE POSSIBLE test for connection.  Use the System Configuration API to read the Device "Is Present?" property
• When do you NEED to control a Task State Explicitly? The simple answer- whenever you want to avoid multiple implicit state transitions.  There are a few caveats that are mentioned by the help file in passing. Control Task does not force a state transition in some cases.  e.g. if a Task is in the Reserved state and a timing property is changed we know that the timing property has not been verified yet!   That property will not be verified until the next forward State Transition. "Commiting" the task will verify and reserve any new timing resources then spin up hardware. (Commit is the first state that actually has any effect on the device hardware.)  From the same condition "Reserving" the Task has NO EFFECT because no Transition has been asked for.  The HARDWARE is the choice on when to transition between reserve and commit.  The RESOURCE exclusive lock is when to Reserve or Unreserve.  There is a difference between backward transitioning from "Commit" to "Unreserve" and "Verify." Verify only happens on the next forward transition so "Commit" - "Verify" does not release software locks nor does it spin down hardware "Commit"-"Unreserve" Does.

Now, I like persisted Tasks and think they should almost always be used.  For "For purpose" systems I persist them to MAX for troubleshooting and integration.  For "Mixed use" I prefer them in the lvproj so I can control the scope and have "ProjA" be completely seperate from "ProjB" Thankfully, you CAN now copy and paste DAQmx stuff from lvproj to lvproj without a text editor. (yes, I had to resort to that on more than 1 occasion)  I WISH I could persist them to lvlibs!  and scope them even tighter while packing them into ppls but.....NI hasn't got around to meeting that need yet.  My reasons are legion. some listed:

• The DAQmx Wizard pre-verifies the Task during creation- so any novice developer can configure the Task, Channels and Scales while EVEN Naming the I/O by signal name to the Documentation in the lvproj plus Named Channels are picked up as attributes that become channel names when logging is enabled and plot names when displayed.
• Your Configuration files are embedded in the lvproj in xml and automatically recreated by the app builder for the exe as.ini
• I can create an "Action Engine" for each Task holding the Task on a USR/FBN forcing other developer to only do WHAT I WANT with the Task exactly the same way every time without duplicating any code (Now you know why I want to Scope DAQmx Stuff to a lvlib)  This would be esspecially useful for you tst!  with the code you'vre shown and you need a "Check Conx" method.  Those AEs are also great for integration and maintenance! not to mention AUX exe's for "Cal / Engineering aid" that you might co-deliver with Main.exe.
• Now that I have Action Engines for each DAQmx Task, I can write nice Soft Front Panels for each one and any other I/O resources launch them all and PLACE my entire SYSTEM in any state I want!  whereas MAX only allows you to run only one single Task at a time!
  
  

That's my thoughts for now.  Feel free to ignore me.

[Kevin_Price]

Thanks, Jay!   FWIW, I'm not exactly *opposed* to persistent tasks, but I have been leery of using global tasks and channels defined in MAX.  When they were being introduced for DAQmx, I was working in a place with very tight configuration controls so they weren't a realistic option for me.   Since then, I've seen plenty of MAX database corruptions that required full resets (though thankfully, many fewer in recent years) where I was glad I *didn't* have crucial elements of my test setup residing in MAX.

Also, I was often doing special sync setups among multiple tasks that shared clocks (sometimes self-generated with a counter task), and I didn't see a way to define those interdependencies in MAX.

The project-based persistent tasks sound kind of interesting, but I'm not sure they offer me enough advantage that it's worth the learning curve and hard knocks.  For example:  your warning here about the danger of clearing a persisted task.  I wouldn't have anticipated that, and I imagine that would have bit me good and hard sooner or later b/c I habitually *always* clear my tasks.

I can see where project-based tasks could be a nice feature for users that don't often get down-n-dirty in DAQmx.  But I don't presently see where they'd be a bit help to me.  You've been at this DAQ stuff a good long time too -- what are some of the specific things you prefer about project-based tasks vs. building them in code?   

    Suppose I wanted to set up a multi-task stim-response app (clock generated by a counter output with programmable pulse width, AO driven by rising edge of clock, AI driven by falling edge).  I know exactly how to do that when I build tasks on the diagram.  Could I get all that stuff configured in a set of persistent project-defined tasks?  Would there be any particular advantages to doing so?

-Kevin P,

with apologies for hijacking the thread, but honestly, not very sincere ones

[JÞB]

---

@Kevin_Price wrote:

Thanks, Jay!   FWIW, I'm not exactly *opposed* to persistent tasks, but I have been leery of using global tasks and channels defined in MAX.  When they were being introduced for DAQmx, I was working in a place with very tight configuration controls so they weren't a realistic option for me.   Since then, I've seen plenty of MAX database corruptions that required full resets (though thankfully, many fewer in recent years) where I was glad I *didn't* have crucial elements of my test setup residing in MAX.

    Suppose I wanted to set up a multi-task stim-response app (clock generated by a counter output with programmable pulse width, AO driven by rising edge of clock, AI driven by falling edge).  I know exactly how to do that when I build tasks on the diagram.  Could I get all that stuff configured in a set of persistent project-defined tasks?  Would there be any particular advantages to doing so?

-Kevin P,

with apologies for hijacking the thread, but honestly, not very sincere ones

---

I said "Almost Always"  You just hit the top example of when not to.  Although "In Theory" all of those timing parameters can also be configured with the DAQmx Wizard and added to the three Tasks.  MAX is not a very secure location for persisted Tasks but a lvproj is.  If you open a lvproj with a text editor you'll see EXACTLY how LabVIEW and MAX hold DAQmx configurations in xml.  They just use different file locations and LabVIEW can see either location  Persisting them in a project provides namespacing to the projects scope so no project can see into MyMroject's context and the main app instance cannot see into any project context.  Currently I'd wish for having them also able to persist to a lvlib (not possible) so I could re-use the same library of a DAQmx Resource AE wrapped up to private or friendly scope on multiple projects (say 10 of 15 tests on 1 universal test station)

Again project Tasks are a complete "Value Add" for the application you build because, all Project DAQmx configurations are exported to <Resource>\NI-DAQ\DAQmx.ini and not only are they human readable but {cough, ahemmm...} can be edited to change things without rebuilding (Oh Damn! we need to toss a 3rd temp probe in there and log it with a channel name of ArmpitLeft And place it between ArmpitRight and Askrack.) easy to do.