Hi there:You are my last resort before I take that card and throw it in the trash. It has been bugging me for almost six months now. Here is a rather lengthy introduction. Please bear with me!I am using LabVIEW 6.1 and the VI library that comes with the NI4351 card. I wrote up a "control" VI that uses the VIs from this library to do some configuration and then enter a while loop in which it checks for completion of acquisition, and if so, scans the channels of interest once and writes the results into a queue. If the acquisition is not complete, it simply cycles the while loop. Also, the while loop can be terminated via a notifier. In my view, this effectively establishes an asynchronous acquisition, which does not slow down other things.This "control" VI is called once from a "master" VI above it, which provides it with the queue and gets the NI4351 running "in the background". This "master" VI then goes into a while loop of its own, where it simply reads the queue filled by the "control" VI (with a 5 ms timeout) and also provides the "control" VI with the necessary notification to keep it alive or to terminate it. The "master" VI loop cycle time is about 15 to 20 ms, even though the NI4351 takes about 1 s to generate a scan.The fast loop cycle time allows other things to happen without having to wait for the NI4351 to complete a scan. In fact, the "master" VI handles similar "control" VIs for other, much faster, cards (NI6052E and NI6713). This actaully works quite well.While the NI4351 "control" VI uses the provided library, the NI6052E and NI6713 "control" VIs use NI-DAQ. Thus, for these cards, I can assign different DAQ groups, but I cannot do that for the NI4351.Now, after this long introduction, the problem is that initially the thermocouple readings that come in through the NI4351 are just fine, but randomly and after varying amounts of time, they produce very large negative numbers, almost as if the thermocouples were open. We know for a fact that there is nothing wrong with the thermocouples, though, because the readings come back just fine after restarting the "master" VI - only to get messed up again after while.I am using a TBX-68T to do the connections, all unused channels are physically grounded (both + and -), and the "control" VI only scans the channels that are actually used.I have absolutely no clue what goes on here! What in this setup would make the readings initially behave, but then, after a random while, misbehave? I thought maybe the VI library for the NI4351 was messed up and tried to write a "control" VI for the NI4351 based on NI-DAQ. However, I believe to implement the "asynchronous" feature, I need to use the DAQ Occurence VI, which does not seem to be supported by the NI4351. So, while I can (and will tonight) use this version of the "control" VI, it does substantially slow down the "master" VI and thus, in the long run, will be of no use.Please! Any and all advice would be VERY much appreciated! I am looking forward to your response.Regards,Matt Koch

Digital Multimeters (DMMs) and Precision DC Sources

... spurious TC (asynchronous) readings on NI4351 ...

Bjorn,

Thank you for posting to the NI Forums. I am not sure if Matt is monitoring the forums, the post was several years ago but hopefully we can help you out. Could you explain how you are getting the same issue? Are you running several DAQ devices at the same time as in Matt's application? Could you provide a quick rundown of your hardware and software setup? Are you programming the 4351 with the DAQ VIs or are you programming it with the 4351 software calls?

Regards,

Neil S.
Applications Engineer
National Instruments

Message Edited by Neil S. on 08-24-2006 04:04 PM