From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Getting error 200488 on DAQmx Start Task

Solved!
Go to solution

Hello all.  We have a strange situation.  We are running a program which works on our Development PC that has Labview 2020.  However, when we make an executable and run it on a different PC that has only the Runtime Engine, we get an error -200488 at Start Task.  We can't understand why the program works on the PC with the Labview software, but doesn't work on the PC with the Runtime Engine.  The NI article on the error speaks about Unicode, which we don't use.

 

One thing we see that appears odd is that the drop-down selector for Watchdog is greyed out.  We don't understand why it would be greyed out, as it should detect the chassis Watchdog is configured for.

 

Why would we get this error on one PC but not on the other?

0 Kudos
Message 1 of 13
(2,052 Views)

@Dhouston wrote:

[...] run it on a different PC that has only the Runtime Engine, we get an error -200488 at Start Task. [...]


As far as I know 'Start Task' is part of DAQmx. Is DAQmx installed on the PC running your executable?

0 Kudos
Message 2 of 13
(2,046 Views)

Did you read the error message?

 

It is a little confusing talking about physical vs. virtual channels, but the gist of it is that a channel doesn't exist.  When it works on one PC and not another, then the likely scenario is that the channel doesn't exist on the other PC or might have a different name then what you are specifying.

Message 3 of 13
(2,039 Views)

Yes, DAQmx is installed on the PC running the executable.  There are other  Executables running on that PC, and they use DAQ functions

0 Kudos
Message 4 of 13
(2,013 Views)

Can you explain how the channel could not exist between PCs?  We have Project Tasks which configure channels for the chassis.  How would a channel not exist when the task configures and calls for it, especially since the program works successfully on the one PC.  With the Executable PC having the DAQmx software and the runtime engine, can something else be missing that is causing the Executable PC to not see a channel?

 

When we build the executable, the builder has what it considers the necessary components.  This is all greyed out, so we can't select anything.  Can something be missing that the builder is not getting?

0 Kudos
Message 5 of 13
(2,005 Views)
Solution
Accepted by topic author Dhouston

Your code calls a task called Bravo-XT.  Also FV 1 and 2 H and C, FV 3 and DV 1 H and C, DV 2 and DV 3 and H and C, and Fryer Temps.

 

Do those tasks exist within MAX on the other PC?

 

Have you tried debugging the executable from another PC?  Or make a version of your executable that scatters around extra indicators to let you see if there are any errors on any of those error wires?

 

You said those tasks are project level tasks.  Are they included in the executable build?  (I've never worked with project level tasks.  Only ones created directly in MAX, or ones I create from scratch in LabVIEW code.)

Message 6 of 13
(1,984 Views)

Those tasks are not in MAX, as they are Project Tasks only.  We shied away from using MAX tasks because we had a lot of problems using them, and an Application Engineer actually steered us away from using MAX tasks because of the issues we were having. We had problems with exporting and importing the MAX Tasks, and sometimes losing the tasks altogether when doing upgrades to Labview.  Yeah, all kinds of crazy stuff.  Project Tasks have prevented those issues from reoccurring.  

 

I do believe the Tasks are in the Executable build, as we have a Virtual Folder named Tasks, which we put Project Tasks into.  Although we can't open the folder see what items are inside when we are making the build, the folder does appear as a selectable item to include.  We always choose to include it, so I am assuming the Tasks are inside it, even though we can't see inside the folder (there is no + beside the folder to open it up and see inside).  Actually, I don't recall ever being able to  see tasks inside such a folder when  making the build.  However, all our other executables are using Project Tasks, and they work fine.  We use the same process when doing projects, so this makes me believe the tasks are being included in the build.

 

Attempting the executable on another PC is another step we are looking at.  I hope to give some results of this.

 

0 Kudos
Message 7 of 13
(1,955 Views)

Ok, here is an update.  Based on your mention of MAX tasks, RavensFan, we decided to give it a go once again.  We changed our Project Tasks to MAX Tasks and did the whole importing process.  Oh goodness, talk about a fire pit.  Through much trial and error we found that chassis have to not be in MAX already for importing to work successfully.  So we already had Bravo (a 9188XT chassis) in MAX on the executable PC.  We kept getting import failures when trying to import the MAX Tasks and other configuration items.  We went through a bunch of reserving and unreserving the chassis between the Development PC (where the program was made and executable built) and Executable PC that runs the executables.  With all of that failing still, we decided to completely remove Bravo from the Executable PC, then try importing again.  This time it worked.

 

In Labview 2017 or 2018 we had to just unreserve chassis between the two PCs to allow for importing to work successfully.  Now we have to delete chassis altogether.  Quite a learning curve that gets thrust onto us sometimes.

 

So right now the program is running successfully on the Executable PC now that we have MAX Tasks.  What we seemed to conclude is that Watchdog is not able to handle Project Tasks.

 

Any thoughts on this?

 

 

0 Kudos
Message 8 of 13
(1,939 Views)

I pretty much always create my tasks from scratch in code.  I've never made a project task and it's been more than a decade since I dabbled with relying on MAX-defined tasks.

 

This doesn't directly address your question, but FWIW, by doing things this way I never run into any of the difficulties you described.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 9 of 13
(1,925 Views)

@Kevin_Price wrote:

I pretty much always create my tasks from scratch in code.  I've never made a project task and it's been more than a decade since I dabbled with relying on MAX-defined tasks.

 

This doesn't directly address your question, but FWIW, by doing things this way I never run into any of the difficulties you described.

 

 

-Kevin P


This is generally my approach as well. I either have a configuration page that allows the user to select the appropriate channels at startup, use a configuration file to store channel information, or both (prepopulating the configuration page with data from the configuration file, and saving the configuration for the next run).

Message 10 of 13
(1,879 Views)