Sudden temperature reading error

[JAH]

Hi,

I'm using LabWindows/CVI v5.5.1 on Win 98SE with an NI 4351 DAQ and the TBX-68T accessory to continously measure voltages and temperature (range: -15°C to +80°C using a K-type thermocouple). DAQ readings are scanned from 8 channels into a static buffer every second in an asynchronous timer thread with the NI435X_Check_And_Read function. Everything works fine for a few hours or even days until the temperature readings suddenly change to thousands of °C (can be negative or positive). Frustratingly, I cannot reproduce the problem at will - it appears to be random. If I stop the data acquisitions, re-configure the scan list and then restart acquisitions (even without an application restart), everything immediately works fine every time, so I've ruled out a faulty thermocouple. I've tried enabling/disabling auto-zero mode and ground referencing to no avail. Increasing the data buffer size to over 1000 elements makes no difference. Unfortunately, this problem means that I cannot trust the system to perform long-term tests reliably, which was the whole point of the exercise, so I would be grateful for any help/ideas please.

Thanks in advance,
John.

[jr_2005]

Are you using thread-safe techniques for transferring the data from the Asynchronous Timer? This is a common source of unexplainable data behaviour. The CVI sample in toolbox\asyncdem.cws illustrates one approach to solving this problem.

JR

Message Edited by jr_2005 on 08-26-2005 12:05 PM

[JAH]

Thanks for the suggestion JR. I thought I might be able to avoid thread-safe variables since I was only reading the data buffer, but maybe not, so I'll give them a go to see what happens.
John.

[JAH]

Hi,

I converted all variables to thread-safe, but the problem remained. I then upgraded the PC to a Pentium 4 with a freshly installed WinXP OS, upgraded LabWindows 7.0, and a new NI4351 DAQ card & driver, but alas the problem still remains. WinXP now usually reports a 'serious error' condition, citing my application as a 'failing' application. cvirte.dll and others are usually listed in the report. After the OS-activated reboot, another alert is displayed, indicating that XP has recovered from a serious error. I've disabled all hibernation/standby options to no avail. The application could work perfectly for two or three days before this error condition occurs. I ran a different visual basic application (not associated in any way with DAQs) for over a week on the same PC without any problems.

Frustratingly, the problem is still unresolved and it remains a total mystery to me.

[DaveC]

Sounds like it could be a memory allocation error.  Do you dynamically allocate memory anywhere in your code?  Perhaps one of your statically declared buffers is not long enough and data is getting written past it.  Intermittent errors like you are having in C are usually the result of a minor buffer overrun.  A lot of times you will see the memory error occur at random intervals since when the buffer is overrun it's a pot shot as to where the data gets overwritten.   Sometimes it overwrites critical system memory locations, sometimes not.

[genka]

Hi,

Have you find out the solution?

I have exactly the same problem, but I  try using Labview V 7.1, using NI 4351 PCI & TBX-68T ,

The temperature reading error after a few hours.

I try to run it on Pentium 4, 3 Ghz,memory 256 Mbyte. It works fine, I try it for two days,

but when I use Pentium 4, 1.4 Ghz,memory 256 Mbyte, the same problem appears again.

The DAQ version 7,4

Please give suggestions. Thank you

[SachaE]

Hi,

  could you please re-post this question on either the DAQ message group, or the LabVIEW one and then post the link back here.

You say the temperature readings error, but not in what way - do you mean you get an error when reading the temperatures, or do you mean the temperatures read are wrong?

As per the thread originator, if you stop the code, and re-start it, does the problem immediately dissappear?

It sounds as if the data isn't becoming available in time, and then some math is being performed to convert it to temperature, and this is where the error (if it's a temperature error) is coming in, although without seeing the code that's only a guess.

If you could also post your code cut down as much as possible so it still reproduces the error, that would really help too, and then I can investigate further for you, but I think we need to move it over to either the DAQ forum, or the LabVIEW one first.

http://forums.ni.com/ni/board?board.id=250

http://forums.ni.com/ni/board?board.id=170

Thanks

Sacha Emery
National Instruments (UK)

[genka]

Hi Emery,

Ok, I already post the question on the, http://forums.ni.com/ni/board/message?board.id=170&message.id=182306

The program is running continuosly, The problem is The data acquisition temperature only correct for few hours,

and if I  stop the code, and run it again, and everything immediately works fine every time.

Actually I had ever thought to use CVI, but it seems what john's experience just give the same condition.

oh ya, in the link I already attach my code, If some one has suggestion. I really appreciate it

Thank you,

Best regards,

irwan

[JAH]

Hi,

I think I've eventually solved the problem by giving up on the direct temperature measuring capabilities of the NI4351 DAC. Instead, I use a linear 4-20mA temperature transducer calibrated for the temperature range of interest and measure the voltage it drops across a precision resistor with the DAC. It's then a simple mathematical task to convert this reading to degrees celcius in software.  It would seem that the DAC cannot handle a diverse range of voltages across multiple channels. While measuring the miniscule voltages from the thermocouple, I had other channels set to a voltage range of 14V. From my reading of various posts, I gather that the thermocouple channel may also have been set to this range, despite the explicit range setting of each channel in software, although I'm unclear on this. I now use a 5V range for the former thermocouple channel and I've had no problems since (longest continous test session so far was 3 weeks). The temperature readings are also more stable now (less noisy). I suppose the lesson learnt might be not to use the NI4351 to directly measure both voltages and temperatures at once, unless the voltage magnitudes are comparable to those of a thermocouple, or your desired sampling rate is slow enough (several seconds) to allow the DAC to be re-configured with a suitable range before reading each channel (this was not viable in my 1Hz sampling application).

John.