DAQ-MX data corrupt after moving hardware to new computer

[AzimJ]

My compiiled LABVIEW code is no longer working after moving the hardware to a new computer. I installed the LABVIEW Runtime Engine  and DAQMX drivers.

My simple LABVIEW code reads 3 channels from my DAQ (PCI-6115) and displays the data in a Chart-control. On the new computer, I can open the DAQ's test panel and data which shows the channel data as coming in normal (I can connect a signal generator to each channel and monitor the signal in the test panel). However, in the compiled EXE, the signal is showing up in all three channels (kind of looks like cross-talk).

Any ideas on what might be happening?

[Bob_Schor]

When you connect to a device, it often identifies itself as "Dev1" or "cam3".  If you plug in another device, it can be "Dev2".  At the time the EXE was built, the DAQ device was probably "locked in", while on the new PC, it may be at a different "Dev" place.  I've had this happen with USB devices, and have had to interrogate the Device to make sure I was connecting to the right one.

I hope it's as simple as that!  Do you have the code that built the EXE?  Can you try running in Development Mode, where you can better track what is happening?

Bob Schor

[AzimJ]

Thank you for your reply.

The device is still "Dev1". To make sure the issue wasn't my EXE files, I created a simple, VI using DAQ-Assistant. I compiled it made sure the device id was correct (ie \dev1 - since I only have the 1 DAQ card). This simplified program still has the weird cross-talk behaviour.

I'm not sure what you mean by running in Development Mode. Would this require installing LabVIEW on the actual computer with the hardware? Currently, my developement machine is setup with a virtualized -DAQ. I then compile the code and run it on the expermental computer for testing. Mostly because I have limited access to the hardware.

[Bob_Schor]

Yes, I meant have LabVIEW on the machine with the hardware and actually run LabVIEW with the "real device".

Did I understand you correctly that if you run the Real Device in MAX and ask it to do what you think your EXE is asking it to do, you get clean signals, bur if you then run the EXE on the same machine/same Device, you see lots of crosstalk?   Is it also true that you never ran the "real" hardware on the machine you used to develop the software (the "LabVIEW computer"), but only tested it with a Simulated DAQ?

If both are true, it sounds like you have Serious Crosstalk!  Check the way the Device is set up in your code and in MAX.  Look especially at whether you are recording Differentially, Single Ended Referenced, or Single Ended Non-Referenced.  Be sure that the other settings are the same between MAX and DAQmx (including which channels, of course).

Got a pal who's really good with electronics, and has a portable oscilloscope?

Bob Schor

[AzimJ]

Hello Bob,

Thank you for your advise. In the end we put in a new hard-drive. The clean install of windows and DAQ-MX drivers cleared up our signals. We also moved the DAQ card into a different PCI slot.

So, I am thinking there must have been something corrupt or conflicting in software. Unfortunately, did both at the same time so I don't know if the fix was moving the hardware or the clean install of the system.

Regards,

Azim

[JÞB]

I'm going to ask.

How did you deploy the Task?  via MAX in a *.nce file imported as part of the installer for the exe?  via a project Task included in the exe under the NI DAQ folder? or just programatically created on-the-fly from some other text file?

[AzimJ]

I'm not sure how to answer your question. Here is the Block Diagram and Front Panel of my simple test application. Does that answer your question? If so, what was the reason for your question?

[Blokk]

This VI makes little sense.

1. Use error wires so you can see if error happens.
2. Do not put the Chart and the Wait function inside the While loop. Remove the Wait function! Your DAQmx functions will time the While loop iteration.
3. Use a proper Producer-consumer structure to acquire data, and send it to a consumer loop for display and data logging using Queue.

https://decibel.ni.com/content/docs/DOC-2431

[AzimJ]

Hi Blokk

Thanks for the tips. Let me explain myself because I'm feeling a bit defensive.

My little sample VI was meant to do was read the channel and display. For this purpose it works.  Yes for a larger application I do split things out. It was meant to be as simple as possible.As for the wait function. Besides this is based on the VI you get when you generate code from a DAQmx-Asisstant block. I suppose the "wait" function was unnecessary but doesn't harm anythign does it?

Yes I agree that I should wire up the error to a control so that I can monitor errors but I figured if I can read the channel in Measuremen & Automation Explorer (MAX). Then LabVIEW should be able to read the channel as well without errors. Maybe that is a wrong assumption.

[Blokk]

---

@AzimJ wrote:

Hi Blokk

Thanks for the tips. Let me explain myself because I'm feeling a bit defensive.

My little sample VI was meant to do was read the channel and display. For this purpose it works.  Yes for a larger application I do split things out. It was meant to be as simple as possible.As for the wait function. Besides this is based on the VI you get when you generate code from a DAQmx-Asisstant block. I suppose the "wait" function was unnecessary but doesn't harm anythign does it?

It does. It harms your DAQ timing. You create 3 mseconds gaps between every iteration when you get 5000 data values. So you simply lose data.

Yes I agree that I should wire up the error to a control so that I can monitor errors but I figured if I can read the channel in Measuremen & Automation Explorer (MAX). Then LabVIEW should be able to read the channel as well without errors. Maybe that is a wrong assumption.

Use the error wires. That is it. One thing is to practice proper coding style. The other thing is, if an error happens during a measurement, your While loop might not stop. Stop the while loop if error happens, and report the error to the user. 

---