PXI 6602 using DAQmx for frequency counting causes freeze

[Dan_55]

Hi all,

I am trying to configure a PXI 6602 counter to measure a low frequency signal across several physical PFI lines. I set up all 8 available counters in a loop and pass the DAQmx reference to 8 while loops so that each while loop can update an FGV when a new sample becomes available (the loops are limited to update no more than 4 times per sec). Since the signal to be measure is potentially very low frequency, I set the timeout on each Daqmx call to be the max time expected between pulses.

Everything seems to work fine and I have verified that I can measure signal frequencies down to my lowest expected. The reported CPU useage while this program is running is nominal but it causes all other VI's to lock up and freeze. For example, if you run the program and then open a new vi, drop a while loop onto it and then put a 'generate random number function' with an indicator, you would expect the loop to execute extremely fast but it is only able to generate a new random number about once a second or so.

Any ideas as to why this program locks up the PC without reporting CPU useage?

One last thing to note is that I have tried this using simulated hardware and it does not have the same problem.

[Chris_Garratt_NIUK]

Hi Dan,

I've had a quick look at your code and it would seem that you have a couple of custom controls in there which you haven't uploaded.

I do have one recommendation though; you should remove the multiple loops and place everything within one loop as they all have the same timing and therefore do not need to be seperated. Give this a go and see if it helps. These sorts of things can have drastic effects on the performance.

Best of luck,

Chris

[Dan_55]

Hi Chris,

The reason that I wanted them in separate loops is so they can all update the FGV as soon as they have data. If they were in the same loop it would only get updated at the rate the slowest DAQmx vi got a sample (potentially 20 sec). This would mean that you could be putting out of date information into the FGV. This problem seems to be related to the way labview handles multiple loops. There is no way that 8 loops that are effectively doing nothing for much of the time should lock up the whole PC (and report close to zero CPU load).

Incidentally, I just tried replacing the while loops with timed loops instead and this seems to fix the problem. I have had problems in the past though when trying to run timed loops alongside while loops so I'll see how it performs as part of the larger program.

[Chris_Garratt_NIUK]

Hi Dan,

I'm glad you've made some progress. I should have read your first post properly, sorry!

I would be careful with the timed loops, I think they will execute at a higher priority than the standard while loops so you may need to use them for all loop cases.

I would also advise against this architecture as it will be very prone to race conditions. If the FGV VI is in use by one of the loops then none of the other loops can use it, which is likely to be causing your locking. I would recommend re-architecting your code. I will have a look into putting together an example when I get a chance.

Best Regards,

Chris

[Chris_Garratt_NIUK]

Hi Dan,

I'm glad you've made some progress. I should have read your first post properly, sorry!

I would be careful with the timed loops, I think they will execute at a higher priority than the standard while loops so you may need to use them for all loop cases.

I would also advise against this architecture as it will be very prone to race conditions. If the FGV VI is in use by one of the loops then none of the other loops can use it, which is likely to be causing your locking. I would recommend re-architecting your code. I will have a look into putting together an example when I get a chance.

Best Regards,

Chris

[Dan_55]

Hi Chris,

I am aware of some of the problems with timed loops, I have been advised in the past that they are only implemented correctly on RT systems. There is definately some strange behaviour when mixing the two types of loops, particularly with DAQmx functions inside them that have wait for next ms or timeouts. The reason that I have used this particular FGV setup is that I want each counter loop to be able to run at different speeds (but no more than 4 times per second). These counters update the FGV which is unloaded in another section of code at a set rate. I didn't think race conditions would be a problem since the FGV is only opened when new data is available and it doesn't matter which particular counter job is being updated. Since the FGV is only opened right after a frequency measurement has been taken, it will generally take some amount of time before the next measurement is available anyway (min of 10ms). I guess it depends on if the FGV is opened (and reserved) when the loop is started or only when there is data available on the wire connected to it. I had assumed it was the latter since otherwise a single very slow loop might tie up all resources inside it.

I'd appreciate any comments on alternative architectures, particularly with regards to removing the timed loops. I'd also love to hear the explanation of why timed loops work over while loops in this case....:)