Problem with multirate program using timed loops

[JHale]

Hi,

I'm having problems with my VI crashing after a long period of time. The VI consists of several parallel timed loops. A 10ms loop for reading analog ins and writing their values to global variables, a 1s loop for outputting voltages based on calculations from those global variables, a 1s countdown loop, and a 250ms loop for updating indicators. I'm using a PCI-6229 daq card btw.

The problem is after about an hour of running this VI, one of the loops starts running late. The frequency of its lateness increases until it causes the other loops to be late as well. If I stop the VI, labVIEW becomes unresponsive for about 10mins and then things are back to normal and I can start the VI again.

According to windows task manager, when I start the VI it runs around 15%CPU and 90MB, when it begins to be late it runs around 50% ( P4 3.4GHz, 1GB ram).

Any help would be greatly appreciated.

Jeremy

[Mcdan]

Jeremy,

Without seeing your VI, I can only guess at what may be the problem. But to me, it sounds as if you are creating things and not cleaning them up, with each iteration through one or more of your loops. My guess in this case is that it could be a DAQmx task. If you are calling create task in your loop, but not clearing the task, I would expect to see similar behavior to what you are describing. Another thing to watch out for would be inserting data into arrays in your loops, as those arrays would continue to grow and grow. Those would be my best guesses for now. If you can post your VI, I could take a closer look at it.

Hope this helps,
Dan

[JHale]

Hi Mcdan,

Thanks. The main analog input loop with runs every 10ms or so, had to tasks in it. One measure four voltages and one measured a thermocouple. I had a problem with running them concurrently so I put a stop task after each one. So Labview was stopping and starting the task each time it ran. I took the temperature input out of the loop and now it runs around 3%CPU and half the memory. Although I still have the problem of getting those to tasks to work together, I should be able to figure that out.

Thanks,

Jeremy

[Mcdan]

Jeremy,

You should be able to start/stop the tasks in the loop as necessary. However what you want to avoid is the creation of a task in the loop which you are not also destroying in that same loop. Most often however, if this occurs, the task can be created and configured before the loop, then started/read/stopped in the loop. After the loop these tasks can then be destroyed. So if I am correct, in your case you would have two tasks created (one for voltages and one for thermocouple) before the timed loop. These task handles would be wired into your timed loop, where you could first start one (for instance your voltage task), call read on it, and then stop it. This same procedure can then be repeated for the other task (thermocouple task). This configuration allows you to re-use the same tasks, rather than creating them from scratch each time through your loop. Once the loop is complete, then each task created can be destroyed using DAQmx Clear Task. This sounds to me like the most efficient configuration for the scenario which you are describing. Please let me know if you have any other questions.

Hope this helps,
Dan

[JHale]

Hi,

Thanks a lot for your help. I have a subVI that creates the two tasks (voltage and temp). These are wired into a subVI in the timed loop. This subVI is a two-part sequence with the first part being a read on the voltage and a stop and the second part is a read on the temp and a stop. If I don't have the stop tasks in there I get an error saying that the resource is already in use. If I remove the stop and consequently the second part of the sequence, it runs very well. Of course, I can't tell if the stops or the second part is what is causing the poor performance. Any ideas?

Thanks again,

Jeremy

[Mcdan]

Jeremy,

Depending on how you are starting and committing your tasks, it is possible that with only one task, the hardware never needs to be reprogrammed between your stop call and your start call. This generally happens if you explicitly commit the task outside the loop, then start/read/stop inside the loop. However, if you have multiple tasks in your loop, then the hardware must be re-programmed each time you start either task, as the hardware configuration will differ from task to task. This re-programming would explain why you see a performance difference when you add then 2nd part into your loop. You are essentially doubling the amount of hardware programming that must be done.

To use two different tasks, you need to stop the 1st before starting the 2nd because both tasks are programming the same hardware (all of your AI channels share some common resources). This is why you get a resource reservation error when you try to start the 2nd task, if you haven't stopped the 1st task.

In your original post, you had mentioned that your VI ran OK for an hour, before getting bogged down and crashing. Has that problem been resolved, or are you only seeing problems after some amount of run time? If the original problem has been resolved, and the problem is getting both tasks to run in a 10ms window, then I would see if you could read all of your voltages as part of the same task, and then perhaps programatically scale the thermocouple reading into appropriate units, rather than using an separate task. If this is done, then the task could be committed outside of the loop, and started/read/stopped inside it. However since no change is made to the hardware configuration, you should be able to re-start without the driver re-programming any of the hardware, which should help with your performance. Depending on how each of these task is configured, it may be possible to do something like this.

Hope this helps,
Dan

[JHale]

Thanks Dan, that really helps a lot.

I attached the setup and iteration subVIs. The setup is outside the loop and the iteration is the only thing in the timed loop. When I remove the stop tasks and the temperature function it runs well, but when I have them both in there it gets bogged down. Even though it takes a hour to crash the program, you can tell right away. If you run the program for 30secs and then click on stop VI, it takes a few seconds to stop compared to it normally stopping right away.

I would like to combine the task into one and then apply some formula to get the correct temperature. The only problem with that is: the voltages are being measured in RSE and the thermocouple would have to be differential.

Again, thanks for the help.

Jeremy

[reddog]

You may not be aware of this, but it is possible to place both measurement types into the same task. The following screen shot shows an example of this. The one thing to keep in mind is that all channels in a task must share the same timing and triggering information. This means your thermocouple channel will need to be sampled at the same rate as your voltage channels. This can easily be dealt with by averaging the thermocouple readings to produce one sample or by simply discarding all but one of the points. If this is undesirable, you can still proceed with your current approach of reserving and unreserving each task inside the while loop, but you might find it easier to program by combining everything into one task.

[JHale]

I didn't know that! thanks so much for your help.

[Mcdan]

Jeremy,

I looked at your VI's and had a few questions. First it looks like you are configuring a hardware timed acquisition to take four samples at a rate of 5000 Hz (in setup). However you are only specifying that you read one sample (in iteration). While this works, it seems as though perhaps a non-hardware timed single point operation may be more in order. I have attached some examples based on the VI's you sent earlier. RedoneExample.vi combines the voltage and temperature channels into one task, with the hardware timed scheme you were using. RedoneExampleSinglePoint accomplishes the same thing, but uses a single point task instead of a hardware timed task. I hope these help. Please let me know if you have any questions.

Dan