Error 200088 using the DAQmx for I/O test (NI USB 6008)

[goursat1]

I was trying to practice with NI USB 6008 by setting up a simple I/O test.

Here is the reference that I was trying to follow (step-by-step). http://home.hit.no/~finnh/videos/topics/labview_analog_io/

I received Error 200088: "Task specified is invalid or does not exist." when I tried to run this program.

Attachment is the program I worked with.

Thanks!

[GerdW]

Hi goursat,

forget about those DAQAssistent ExpressVIs and use a simple DAQmxCreateVirtualChannel to select a channel for each task!

Did you look at the example VIs coming with LabVIEW? DAQmx installs a lot of them...

[JÞB]

---

@GerdW wrote:

Hi goursat,

forget about those DAQAssistent ExpressVIs and use a simple DAQmxCreateVirtualChannel to select a channel for each task!

Did you look at the example VIs coming with LabVIEW? DAQmx installs a lot of them...

---

Or, better yet.  Tasks need to be created once- preferably during development!  use that DAQ assisant to create and test your tasks- then save them to your project.

Trust me, once you start down this road you'll ask yourself why you ever dropped "Create Task.vi" on a BD

[GerdW]

Hi Jeff,

can you please explain this: "use that DAQ assisant to create and test your tasks- then save them to your project."

How to "save them to the project"?

[JÞB]

Many ways:

1 Project exploer  select a target (or folder) right-click- New>DAQmx Task  (Silly picture importer this am)

 

2 From any BD drop a DAQmx Task constant Right click New NI-DAQmx Task> Project...

3 From MAX Create a task and drag it to LabVIEW Project explorer

This works for scales and chanels too!

Now you'll never find those objects on disk!  they show up in the project nicely though because they are really IN the project.  Open the *.lvproj file with an XML editor to see how they live.

4 Use any xml editor to manually create them but that's pointless if you installed DAQmx

The very nicest thing is since they are in the project deployment is painless and your installer will install them on your target.

[JÞB]

One additional point to consider-

(Cause its NOT as obvious as it should be)

When calling LabVIEW modules from TestStand that use Project Tasks Scales and chanels you MUST call them through the project even though the project file is "Optional."  Calling code without the project context loads the code without the project and the Tasks etc... will not be in memory.  That can burn you if you don't think it all the way through and its a real Beast to figure out yourself the first time.

[GerdW]

Hi Jeff,

thanks, I learned something new today...

I usually create DAQmx tasks in the program as I use external configuration files to define the (virtual) channels. So I very seldomly use fixed tasks defined at edit time.

One more question: I guess the task/scale/whatever definition is also used when creating an executable?

[JÞB]

---

@GerdW wrote:

Hi Jeff,

thanks, I learned something new today...

I usually create DAQmx tasks in the program as I use external configuration files to define the (virtual) channels. So I very seldomly use fixed tasks defined at edit time.

One more question: I guess the task/scale/whatever definition is also used when creating an executable?

---

Yup! deployment nightmares go bye-bye and mutiple projects deploy side-by-side without mucking with each others DAQmx definitions.

The *.lvproj becomes the external config file (in a convieniant xml format located where DAQmx expects it):smileywink:  No need to roll-your own external config file!

Even better- if you also add a source distro you can just run those darn tasks with the DAQ wizard for troubleshooting hardware issues.

[GerdW]

Hi Jeff,

---

No need to roll-your own external config file!

---

No, you got that part wrong.

My program uses an external config file (or better: an Excel workbook) because so the users can easily configure all channels (including names, scaling, some linearization coefficients, ...). That config file also contains a lot more than just DAQmx settings and is needed by my testbench software.

I appreciate the idea of embedding fixed tasks in the project file - but most often I define parameters of tasks at runtime (as users want to be able to change a testbench setup without requiring my intervention).

[JÞB]

---

@GerdW wrote:

Hi Jeff,

---

No need to roll-your own external config file!

---

No, you got that part wrong.

My program uses an external config file (or better: an Excel workbook) because so the users can easily configure all channels (including names, scaling, some linearization coefficients, ...). That config file also contains a lot more than just DAQmx settings and is needed by my testbench software.

I appreciate the idea of embedding fixed tasks in the project file - but most often I define parameters of tasks at runtime (as users want to be able to change a testbench setup without requiring my intervention).

---

Goes to show you that you cannot forget the users-  I admit that I specialize in functional test systems.  If its not "Push the button- Get a banana simple" my clients have to hire workers with some skill.