Delay of temperature acquisition

[loslegendos]

Hey,

I have this problem for some time now and although it seems to me to be pretty generic I was not able to find anything about it on this or other support pages.

I am trying to build a Temperature Programmed Desorption setup in my lab using a programmable power supply for resistive heating and a NI-9212 device for temperature measurement via thermocouple. To implement the thermocouple read I first create a task, then the channels (I want to use a different polynom for the thermocouples therefore I also need to read the CJC value seperately) and at last I define the sample rate via the timing.vi. The last part is also where problem arises.

When I don't use the timing.vi the temperature is read with a 1.8 Hz rate which is to slow for my needs and I don't know how to change that, but when I use it comes to delays in the temperature acquisition.

As you can see my vi contains a number of while loops which all execute with at least 10Hz but it may take a single longer execution when they are initiated.

If I set the sample rate to a higher value than the execution time of the while loop it executes as fast as possible but the temparetures are taken with the set sample rate anyway and pile up somehow somewhere and are slowly worked off with the execution rate of the while loop. This results in the display and processing of outdated temperature data in my vi.

If I set the sample rate lower than the net loop execution rate the loop executes with the same speed as the set sample rate but if anything takes a bit longer to execute for example when I initiate a new loop I get the same pile up of temperature samples which is then worked off during the following faster loop resulting, for example, in the display of outdated temperature at the beginning of my measurement.

This is a problem because on one hand it decreases the accuracy of my data and on the other hand it results in an unreliable heating control which could in the worst case melt my sample.

I hope someone here had a similiar issue and can show me a way to either tell the program to acquire a single temperature sample everytime the loop executes or to tell it to just overwrite the old data so it doesn't pile up.

Best regards,

Artur

[GerdW]

Hi Artur,

at last I define the sample rate via the timing.vi. The last part is also where problem arises.

When I don't use the timing.vi the temperature is read with a 1.8 Hz rate which is to slow for my needs and I don't know how to change that, but when I use it comes to delays in the temperature acquisition.

So you think by just defining a sample rate your main program loop would run faster?

When you set the sample rate to 9Hz, but still read the samples with just 1.8Hz you surely will read old (delayed) data. And sooner or later you will receive an error from DAQmx!

Solution: clean up your VI! Use a proper design scheme (producer-consumer could help a lot).

Right now the VI is a mess. The BD doesn't fit on a (FULL HD) screen.

You're using 45 boolean indicators where an array of LEDs would be sufficient.

You're using way to much local variables (IMHO).

There are a lot of missing subVIs from a "GENser" device. How does that device and it's driver functions work? It's connected by a serial port with a (slow) baud rate of just 9600. How long does this device need to react on commands? I guess it's the delaying bottleneck in your VI…

[loslegendos]

Hey,

maybe my description was not good enough so I try to be clearer:

---

So you think by just defining a sample rate your main program loop would run faster?

When you set the sample rate to 9Hz, but still read the samples with just 1.8Hz you surely will read old (delayed) data. And sooner or later you will receive an error from DAQmx!

---

No, I don't think my loop gets faster by increasing the sample rate, it just does. I set the sample rate to 9 Hz to be the bottleneck for this loop because if its not the bottleneck I get a pile up on data from the thermocouples as described. Without the temperature acquisition the loop runs with 10 Hz. With it it runs at the set sample rate. When something holds up the loop for longer than 111 ms the loop after that will run faster at 10 Hz until the pile up of data is worked off. Then it will proceed at the set 9 Hz.

Without the timing.vi it runs at 1.8 Hz as if I set the sample rate to 1.8 Hz. The manual says that 1.8 Hz is the rate at which the device measures with the highest voltage resolution so I assume its the default setting to which the device sets itself when there's no other input.

---

Right now the VI is a mess. The BD doesn't fit on a (FULL HD) screen.

You're using 45 boolean indicators where an array of LEDs would be sufficient.

You're using way to much local variables (IMHO).

---

Yes, I know. I'm not done with it because I'm stuck with this functional problem. I will get to the cosmetics as soon as it works properly.

What is the problem with local variables? I am pretty new to all this and try to do learning by doing and therefore have only a quite vague insight into the inner workings of LabView. I use them mostly to reset Boolian Controls back to their default setting or show readings from different sources on the same indicator. Is there something wrong with them that I don't know?

---

There are a lot of missing subVIs from a "GENser" device. How does that device and it's driver functions work? It's connected by a serial port with a (slow) baud rate of just 9600. How long does this device need to react on commands? I guess it's the delaying bottleneck in your VI…

---

This is the power supply for the resistive heating. I cannot tell you how it works just that it initiates a connection to the power supply and that I can switch the output on and off and set both voltage and current limit via individual subvi's to control the heating. If it's run by itself in the loop it needs at most 70 ms. So far as I can see it executes fast enough to outrun the rest of the loop.

---

Solution: clean up your VI! Use a proper design scheme (producer-consumer could help a lot).

---

I tried to clean up and isolate the problem by copying all the relevant elements from my actual program to a new smaller vi without any boolean indicators and local variables and everything else but with a Wait.vi to simulate the missing components. If necessary I can send you files with the time, temperature, heating and loop execution rate which show that as long as the set sample rate is lower than the loop execution rate I have no noticable delay between temperature and heating so that the power supply reacts faster than my desired measurement rate.

Regarding the producer-consumer design:

I didn't knew about this before so I read about it here https://www.ni.com/en/support/documentation/supplemental/21/producer-consumer-architecture-in-labvie...

Maybe I misunderstood it but this is used to pile up produced data and process it slowly in a second loop to prevent data loss. This is exactly what I don't want to have and what is already happening. I have no problem with data loss. I want to get rid of the piled up data and only use the latest data point available. Data loss and overwriting would actually help me.

I hope this helps to understand my problem.

Best regards,

Artur

[Bob_Schor]

Never mind -- I don't have anything to add beyond Gerd's remarks ...

[GerdW]

Hi Artur,

I want to get rid of the piled up data and only use the latest data point available. Data loss and overwriting would actually help me.

If that is your concern you shoul duse a producer-consumer scheme using notifiers to transfer data to the consumer loop…

as long as the set sample rate is lower than the loop execution rate I have no noticable delay between temperature and heating so that the power supply reacts faster than my desired measurement rate.

That's the point: the loop execution rate should has to be faster than sample rate!

When your loops takes more time to execute than it takes to get the next samples you will end up piling up samples in the buffer!

Using seperate loops for DAQ and power supply control helps to maintain sample rates as needed as your power supply will not delay anything in the DAQ loop. When the power supply alone needs 70ms to execute all communication in your loop the loop rate is limited to 14Hz - just by the power supply driver. Anything else will decrease the max loop rate even more…

General suggestion: To add more than one channel (with same settings) to a task you don't need a loop. Just change the channel constant to "ai0:3"…