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

[mattkoch]

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

[Ben]

Hi Matt,

I had a similar but different problem with the 4351 about a year ago.

I was not using the "special VI's" for the 4351 but was controlling it using the standard DAQ functions and standard virtual channels in MAX.

In this same app I was runnig three acquisition loops similar to what you have mentioned.

In my app, I would some lose all of the scaling ascociated with the thermocouples.

After lots of troubleshooting I found that if the I/O for the 4351 was config'd and started AFTER the other loops, everything was OK.

If either of the other two loops started after the 4351, it would goof-up the scaling for the 4351.

Eventually, I was able to work around the problem by wiring a unique value into the "group" input. The documentaion indicated that
this was not required! Testing indicated otherwise.

You can test if this is what is happening to you by simply forcing the other two loops to start before the 4351. If this clears up the problem, you have a direction.

The only thing that I am unclear on with this idea is why you loose your scaling WHILE it is running. Is your loop configuring and starting I/O regularly?

Trying to help,

Ben

[mattkoch]

Ben:

Thank you very much for your response. I think I came across something you posted earlier to this group. At least your comment about wiring the group input makes me think that. It is good to find someone out there with a similar problem.

Anyway, I would love not to have to use the "special" VIs that come with the NI4351 and to be able to use the MAX channels. You seem to have found a way to do that. It seems like you are putting the NI4351 acquisition in a separate VI and kick it off seperately, using NI-DAQ. At least I think you do, because that is the only one that allows you to wire groups. The "special" VIs don't.

What I would like to know then is how you prevented this separate loop from dragging down the speed of the overall system. I w
ould think you need a DAQ Occurence in NI-DAQ or something to that effect, to only scan the NI4351 when the acquisition is complete. That way you don't have to wait, which is what slows down everything. But from my limited experience, it seems that the NI4351 does not support the DAQ Occurence. So how did you do it?

Also, I will put my loop kick-offs in a sequence frame to force the NI4351 to come on last. Let's see if that makes a difference.

You also seem to say that you lost scaling either at the beginning or the end of your run, not DURING the run. I DO loose scaling during the run, but I DO NOT repeat configuration. At present I am using the "special" VIs, and they have a "Check" VI, which allows to check the progress of the acquisition without time penalty (The DAQ Occurence equivalent, I suppose). Only when the acquisition is complete do I call the "Read" VI to update the queue, which reports to the overall master VI.

Any further thoughts? Pending an attempt to start th
e NI4351 last, I am still clueless.

Thanks and Regards,

Matt Koch

[Ben]

Hi Matt,

In that app I had 4 loops running in parallel.

Main
DAQ1
DAQ2
DAQ3

All of the DAQ loops where the same except they where configured to collect data from different devices.

They use the standard continuous double buffered technique that first reads "0" samples from the device, and if the backlog justifies reading more, then the baklog count is used to read only those samples that are waiting in the buffer.

Ben

[mattkoch]

Ben:

Thanks again for your assistance. I believe I understand what you are referring to, but, at the risk of sounding imbecilic, I don't believe I have ever really used the (double?)-buffered or even (single?)-buffered approach. I always specify 0 for the buffer size, which I believe means continuous scan. I read what's there.

It may be that a giant light-bulb just came on in my head, but I cannot tell for sure. Are you saying that in the double-buffered approach one can use a sort of "check backlog" VI (which one is that?) and if that returns existing scans, one can take action on them, if not, one can do other things? Is that the equivalent of what I wanted to accomplish with the DAQ Occurrence, i.e. checking whether the acquisit
ion finished, and what the Check VI from the 4351 driver VIs does?

I think to minimize further discussion load on you, would it be possible to send me your VIs, so that I can learn from "copying" the parts relevant to me?

Thank you so very much for your kindness and help. I much appreciate it.

Matt Koch

[Ben]

Hi Matt,

I would love to send you the code but, I am certain that my boss would want $$$ for that module. I do not own the rights to my code. I am only allowed to participate in this forum with his permission.

From what I can tell that light you talked is coming on.

Use an AI Read with a zero wired to the "number of scans to read" input. This will take just milliseconds to complete. When it does, it will return the number of samples that are still waiting in the recieve buffer and are available for immediate access in "scan backlog".

I will generally compare this value with whatever I would expect to get in 0.5 to 1 second. If the backlog values is larger, I will then do a second AI Read routing the previous backlog value into the "number of scans..." input. This will complete in the amount of time it takes the AI Read to move the data from its internal buffer to my VI.

There are many variations on this theme, mostly invloving deciding when to read the backlog.

Ben

Warning! Shameless plug follows;

Data Science Automation is one of NI Select Integrators. Our president and owner was the first LabVIEW Certified Instructor outside of NI. At one time 1 in 8 LabVIEW Certified Developers worked for us. At one time one of our devlopers held the record for the highest score ever recorded for the written portion of the the Certified LabVIEW Developer exam while another held the record for the highest combined score.

The module I mentioned above has been successfully integrated into a number of applications and has been adapted for use with serial, Field point, and third party DAQ devices.

It is stand-alone module that will wait for configuration information that it will use to set-up the I/O as required. Once this information is recieved, it will allocate a double ported round robbin buffer that will allow other tasks to access all of the acquired data. The double ported round robbin buffer will allow a fast update thread (like the GUI) to get updates frequently while allowing a second thread to access the same data at a different rate.

The module will also watch for commands that indicate it should shut-down or return to the idle state and wait for a new set of configuration parameters.

This module is fully documented and suitable for LV I & II graduates.

If anyone is interested in purcahsing this module they can reach us on the web at

DSAutomation.com


End of shameless plug.

[mattkoch]

Ben:

OK, this will do! I understand all about proprietary software, which is one of the reasons I switched from Windoze to Linux, even though I have to use LabVIEW under Windoze for now. (By the way, there is a nascent program suite called Comedi, which allows usage of most NI cards under Linux without LabVIEW! Of course, you have to take care of your own GUI, etc.).

Anyway, I think I know what is going on now. Our discussion illuminated the problem from a different side, so now I can try a fresh approach using the NI-DAQ drivers and assigning a unique group number to the NI4351 acquisition. That is basically what I was looking to find out about, and I did.

Thank you so very much! I didn't mind the "shameless pl
ug" - it was quite interesting information! I am always amazed at how it is possible to make money from writing LabVIEW code. From my experience, LabVIEW purchasing decisions are made at a fairly low level, where people are still intelligent enough to actually program and use the software on their own. In fact, at the places I have worked so far, LabVIEW would not have been purchased, if it hadn't been for that stellar engineer or scientist who wanted to code something up to his or her own liking under his or her sole control.

Regards and Best Wishes,

Matt Koch

[Ben]

re: Writing LV for a living.

It's great!

I do between 6 and 12 projects a year plus a handful of consulting jobs. Seldom get my hands dirty.

"Scope creep" is easy to control when there is a dollar sign associated.

Ben

[mattkoch]

Ben:

I would like to chat with you just a little more, but outside this discussion forum. Would you mind contacting me at mattkoch@alum.mit.edu?

Thanks.

Matt Koch

[bjla]

Hi Matt,

I have the same problem with the NI-4351 as you descibed above, I was wandering if you got it to work after rewriting the code with NI-DAQ driver and wiring a unique number as group id?

Best regards,

Björn Larsson