06-29-2016 04:08 AM
Hi All,
I'm getting this error on a application running on a machine,The machine is running 24/7 and this error is happening 3-4 time a day. Has anyone seen this this error? or possible causes?
Thanks
06-29-2016 05:27 AM
06-29-2016 07:38 AM
29 Jun 2016 07:48:20
Critical Alarm
-200587
DAQmx Start Task.vi:5<append>
<B>Device: </B> PneumaticIO
<B>Task Name: </B>_unnamedTask<2FF44>
06-29-2016 08:11 AM
Hi,
have a look here:
http://digital.ni.com/public.nsf/allkb/5664C009DA244727862571E900046775
It seems like the application might have some architecture issue. If I were you I would identify all places where DAQmx Start Task.vi is used and then analyze the conditions when it is run.
07-06-2016 08:12 AM
Hi, is there anyway of knowing what is the unnamed task code means? I'm getting different codes.
See below,
DAQmx Start Task.vi:1<append>
<B>Device: </B> PneumaticIO
<B>Task Name: </B>_unnamedTask<BC5D7>
AQmx Start Task.vi:5<append>
<B>Device: </B> PneumaticIO
<B>Task Name: </B>_unnamedTask<C18F7>
DAQmx Start Task.vi:1<append>
<B>Device: </B> PneumaticIO
<B>Task Name: </B>_unnamedTask<A3CF5>
Thanks
Martin
07-07-2016 08:02 AM
Hi Martin,
Are you starting multiple tasks? It sounds like the error code may be referencing 3 separate unnamed tasks, and the codes are there to differentiate between them. Would that make sense for your application, or do you suspect that they mean something else?
07-07-2016 08:22 AM
When you configure a task, there's an option to tag it with a string name. If the tasks were given names, DAQmx would be able to identify those tasks by names in the error text. Without names, it uses some other method to report a unique "name" for each task, which ends up looking like a bunch of hex characters. (Internally, DAQmx knows how to tell them apart whether you name them or not.)
I'll definitely second the advice from stockson. This very much sounds like an architectural issue. It may be a design issue where there's a static conflict between what the hardware supports and what the code is asking of it. Or it may be an implementation issue where there's a run-time conflict in timing between multiple tasks that each need sole access to a hardware resource part of the time. The hardware may support this when the "need times" don't overlap, but produce your error when the times *do* overlap.
-Kevin P