Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Using NI4351 card.Noisy multichannel data.MAX test panel data OK?Please help

Hi,

I'm using Labview 7.1 and a NI-4351 A/D card to log slowly varying voltages. The system works fine under bench test but when placed into the field (slightly noisy environment) the data starts oscillating badly. When using the test panel in NI-MAX on the same PC in the same environment the data is OK. The previous version in the field also worked fine in the same environment which used a PC-516 A/D card and software written in C++. Is there some setting for the NI-4351 card I should be using?

regards
Richard
0 Kudos
Message 1 of 7
(3,383 Views)

Hello Richard. 

Thank you for posting to the NI Discussion Forums. 

My understanding, and correct me if I am wrong, is that you are using a PCI-4351.  If, and only if, you use that card in LabVIEW, you are seeing a very noisy signal.  If you use the same card with MAX, or a different card at the customer site in both MAX and LabVIEW, you see expected behavior. Is this correct?

How wildly is the voltage oscillating?  Providing an expected V and a read V would be helpful in answering this question.  It could be that you are not selecting the correct input range for the 4351.  The 4351 offers 6 bipolar input ranges:  ±625 mV, ±1.25 V, ±2.5 V, ±3.75 V, ±7.5 V, and ±15 V.  If you are measuring a very small voltage and measuring on the 15V input range, the accuracy of the card could certainly degrade. 

Let us know how this goes and we will be happy to help until a resolution is found. 

Brian F
Applications Engineer
National Instruments

0 Kudos
Message 2 of 7
(3,371 Views)
Hi Brian,

Thanks for getting back to me.

Yes, when using the PCI-4351 card and my Labview application in the field I get very noisy data (my application works fine with the PCI-4351 card when bench tested). If I use the PCI-4351 card and the MAX test panel in the same field environment the data is OK. I have also previously used the PC-516 card with NI_DAQ drives in a C++ application and it also worked fine in the field environment. The field environment is noisier than the bench test environment, however, I really dont believe the noise is in the actual voltage signals being measured as the noise doesnt appear when the voltages are measused with the MAX test panel or a volt meter. The voltages being measured are of the order of volts and very slowly varying with max variations over 24 hours of less than 0.5 volt. The noise I refer to are swings of +-15V and only occur when using the PCI-4351 card with my labview application. I have seen previously on the NI support website (cant recall exactly where) a similar situation reported by someone using an E-series DAQ card and labview. Their report was of trying to measure voltages within +-10Volts and getting values of +-80V. They also reported that when using the MAX test panel this didnt occur. The suggestion was that when doing multichannel reads (as opposed to the single channel read occuring in MAX test panel) the solution was to change the base address of the device to something higher. I was going to try this with the PCI-4351 card (although I was really unclear as to why this should work) but the base address does not seem to be configurable with this card when bring up the Hardware device manager (the base address is greyed out and cant be highlighted). Hope this all makes sense and we can find a solution.

regards
Richard
0 Kudos
Message 3 of 7
(3,365 Views)
Hi Richard. 
 
Thank you for the clarifications.  This certainly seems like an odd issue.  In an attempt to get more information, I have a few additional questions for you. 
 
First, are the sampling speeds different inside of MAX and in your LabVIEW program?  This could explain the behavior if LabVIEW is sampling at a much faster rate than MAX is.  Then, it is possible that MAX is simply missing the voltage spikes that are actually present in the system.  However, I tend to agree with your assessment that these voltage spikes seem out of place.
Secondly, when testing the board in MAX, I assume that you are using the Traditional DAQ driver.  Are you using the Traditional DAQ VI's in your LabVIEW program as well, or are you using the 435X driver?  What versions of these drivers are you using?
 
It may also be valuable to post a pared down version of your code here that still replicates the error.  This will allow our community, as well as myself, to find out if it is in fact an error specific to LabVIEW or if there is some other explanation to this. 
 
Brian F
Application Engineer
National Instruments
 
0 Kudos
Message 4 of 7
(3,360 Views)
Hi Brian,

Sorry for the delayed reply. I have been running more tests on the application over low bandwidth comms links to remote field stations to try and help diagnose the problem and it takes time. I'm starting to think that there must be something wrong with the hardware (could have been damaged in transit to the field station) and EMC may not actually be responsible for what is happening. I have identical hardware/software running at other field stations and have also been making tests remotely to those and the applications have been performing correctly. I have also had our station contractor move the PC running the Labview application away from the EMC source and the strange behaviour has not improved. I am going to have the PC returned to head office where I can test it on the bench as the remote testing is too time consuming. In the meantime, I have attached the main part of the Labview application. I realise there are much more elegant ways for the application to be written, but its my first application after completing a combined basic/intermediate course and I didnt use any of the Labview examples for assistance (just course notes). It has very little or no comments, no error handling and should use lots more sub-vi's (I know this is all very poor programming and its on my to-do list) so appologies for its readability. Basically, there are 3 cases, one is the main acquiring and logging of data, another allows the user to edit a configuration file, and the other case is simply to wait for user input. The "record" case is the one attached. Basically, this reads info from the configuration file (sample frequency, number of samples/lines to a file, channels to be sampled etc.) and uses the AI vi's to acquire data in a "producer" loop. The "consumer" loop creates time stamps and reformats data etc for writing to a file and displaying on a graph. I did not use continuous sampling with the "AI Start" vi as the applications are designed to run for long periods (when they actually work) in the field and long term drift of the PCI-4351 card oscillator that determines the sample frequency becomes an issue. If there are any obviously glaring problems that could be causing the noisy data I'm getting please let me know. Any other suggestions would also be apprectiated. Thanks.

regards
Richard
0 Kudos
Message 5 of 7
(3,333 Views)

Hello Richard. 

I have looked at your code and was impressed by the producer/consumer architecture that you are using.  You code is actually quite clean.  There are no glaring problems, and from your summary about the code working perfectly in other locations, I doubt that the code is causing the problem.  It is either the environment or the hardware.  Since you have made efforts to improve the environment by moving it away from the EMC source, and saw no difference in the noise, you could be correct in the hardware being damaged during shipment.  I look forward to your updates about your further testing at the field office. 

Brian F
Applications Engineer
National Instruments

0 Kudos
Message 6 of 7
(3,324 Views)
Thanks Brian. I'm glad I was somewhere near the mark with the code.....whenever you start programming in a new language your always thinking to yourself that there are probably much more efficient ways to do things. I'll hopefully have the hardware back next week and I'll let you know the test outcomes.

regards
Richard
0 Kudos
Message 7 of 7
(3,315 Views)