LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx tasks won't compile.

 

 

This is a screen shot showing the VI on computer B5. NI-Max 5.0. LabVIEW 7.1. Everything looks normal and the VI runs correctly.

 

 

B3 Task Problem.jpg

Attempting to create the same VI on computer B3 LabVIEW 7.1 and NI-Max 4.0.3:

  • Placing the task on the diagram shows black color for text that would normally be magenta.
  • Connecting a NI-Max defined task using Create Constant to the terminal changes the icon.

There are no errors in the NI-Max task definitions.

 

 

B3 Task Problem 2.jpg

 

This VI was made on a computer with the same NCE file as computer B3, where it complies and runs with no errors. That computer has NI-Max 4.3. When loaded on computer B3, all the DAQmx task icons change and show errors.

 

B3 Task Problem 4.jpg

The B3 compiler complains about connecting different terminal types.

 

The question:

Has anyone seen this type of behavior and is there a solution?  The B3 and B5 computers are PXI systems.  The "other" computer is a desktop with simulated DAQ hardware.  Both B5 and B3 computers run other software that uses traditional drivers.  Resetting the traditional drivers makes no difference.

 

0 Kudos
Message 1 of 12
(3,868 Views)

Open MAX and look at the software installed.  You appear to be missing an NI DAQ component on the "B3" machine.


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 12
(3,859 Views)
The version of MAX is hardly the most important. What versions of DAQmx do you have installed?
0 Kudos
Message 3 of 12
(3,844 Views)

Jeff:

You may be correct.  The NI-Max screen on B3 looks like this:

 

B3 NI Max SW.jpg

 

The screen on the desktop shows entries for LabVIEW 7.0, LabVIEW 7.1, LabVIEW 8.2.1, and LabVIEW 8.5.  I have to support all those versions with it.  Computer B5 also shows LabVIEW 7.1.  So it appears computer B3 is unique.  So the next question becomes: How do I fix computer B3, preferably without disturbing the program it's running, which is critical to keep production happening?

0 Kudos
Message 4 of 12
(3,841 Views)

So the next question becomes: How do I fix computer B3, preferably without disturbing the program it's running, which is critical to keep production happening?


 

 

That is not going to happen.  Installing the correct version of NI Device drivers will require a reboot.


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 12
(3,822 Views)

@djs_at_eaton wrote:
So the next question becomes: How do I fix computer B3, preferably without disturbing the program it's running, which is critical to keep production happening?

That is kind of an odd question.

 

1.  When you are finally in a position to switch over the production machine from your old code to the new code, of course you are going to disturb production.  You have to stop one program and start another.  Of course you will plan your switch over during some downtime, and try to minimize the amount of down time you need to make the switch by thoroughly testing and preparing for it beforehand.

 

2.  You are working on a non-production machine right now aren't you?  I don't know how you can be testing the new code on a production machine without risking disturbing production.  So once you solve this issue on your test machine by installing the right drivers, then you'll have confidence that you can solve the problem on the production machine once you switch it over during planned downtime.

0 Kudos
Message 6 of 12
(3,808 Views)

RavensFan and Jeff

This is an aerospace facility.  We have a different definition of  "disturbing" a program.  A change to underlying drivers (NI-Max) can be considered a problem in this environment.  Even if I don't change the LabVIEW code I may need to revise documentation and possibly do a MSA.  The reluctance to change anything is part of the reason we're still using LabVIEW 7.1.  We don't run 24/7, so I can test code in the existing environment provided I cooperate with production.

 

Re-installing or upgrading NI-Max so it can operate with both the existing and new code is possible, but I will at least have to revise documentation.

 

Just to be clear, you're both in agreement that reinstalling or upgrading NI-Max will fix this.  I also have to check the right boxes when I do that.

0 Kudos
Message 7 of 12
(3,791 Views)
As I said, the version of MAX is irrelevant. It is DAQmx that is the actual driver for the DAQ card and that version is what you need to be concerned about. if necessary, the utility program called MAX will be updated when you install the necessary DRIVER. I'm sure one of the programmers at your company can explain the difference in more detail.
0 Kudos
Message 8 of 12
(3,786 Views)

@djs_at_eaton wrote:

RavensFan and Jeff

This is an aerospace facility.  We have a different definition of  "disturbing" a program.  A change to underlying drivers (NI-Max) can be considered a problem in this environment.  Even if I don't change the LabVIEW code I may need to revise documentation and possibly do a MSA.  The reluctance to change anything is part of the reason we're still using LabVIEW 7.1.  We don't run 24/7, so I can test code in the existing environment provided I cooperate with production.

 

Re-installing or upgrading NI-Max so it can operate with both the existing and new code is possible, but I will at least have to revise documentation.

 

Just to be clear, you're both in agreement that reinstalling or upgrading NI-Max will fix this.  I also have to check the right boxes when I do that.


WHOA,  Not only do you need to update your documentaion but your Installation Qualification process is broken (to wit: Machine B3 has uninstalled required software components)  In some regulatory worlds that would halt production or necessitate an audit.

 

Go back through your IQ/OQ processes and find the gap.


"Should be" isn't "Is" -Jay
Message 9 of 12
(3,780 Views)

Dennis

Is this the latest DAQmx driver compatible with LabVIEW 7.1?   http://www.ni.com/download/ni-daqmx-8.3/301/en/

0 Kudos
Message 10 of 12
(3,763 Views)