Triggered finite acquisition and period measurement

[DrMundoGoesWhereHePleases]

Hello,

My problem is this: I'm not sure on how Labview accesses devices and how setting up multiple tasks affects loop iteration speed.

The vi I have attached uses a rotary encoder to generate a pulse triggering the acquisition. I have noticed that trying to also perform a period measurement on this pulse causes the iteration time to double. For that reason I have included the case structure so the program reads once every 50 iterations.

I am using the PCI 6250 (dev2) and PCI 6220 (dev1) which are connected by an RTSI cable. The 6220 and 6250 are connected to CB-68LP and TBX-68T terminal blocks respectively. The latter of which causes some problems due to incompatibility.

Any help on either te reasons for the slower iteration time and how to solve it would be most appreciated.

Thank you

Ingram 🙂

[Jamie_S.]

Hi Ingram,

Thank you for your forum post and for including your VI. On reviewing your code I am aware of the following:

•  Acquiring 3 Analogue Voltages using a PCI-6220 (Temperature and Torque readings)
•  Acquiring 1 Analogue Voltage on the PCI-6250 which represents "Percentage Metallic Content", this task starts when a Trigger is recieved on PFI9
•  Acquiring 1 Counter Input on the PCI-6220 which represents the RPM of a motor

You are also logging test data to a ASCII text file, this data is only logged when the user presses the stop button on the Front Panel.

As the Counter and Analogue input tasks are seperate from one another it would be worth placing them in their own loops, I think with a bit of rearranging we should also be able to avoid the scenario where you have a while loop embedded inside another while loop. The initialisation of the DAQ tasks should only really be performed once, outside any loops. Another issue dependant on how long the application is executed is the dynamic arrays that are being created, these could become really large slowing down the application the longer it is run for.

An architecture I would recommend for your application is "Producer/Consumer" outlined in the community example available here.

The producer loop will be acquiring data and runs really fast (High Priority), the consumer loop logs data to file (Low Priority), data is shared between the loops using a Queue structure, no other wires should be shared between the 2 loops as these might cause a data dependancy.

Do you require all 3 input tasks to be perfectly syncronized with one another?

Many Thanks

[DrMundoGoesWhereHePleases]

Hi Jamie,

Thanks for the response. I will definitely give the producer/consumer loop architecture a shot - though currently I have the inside while loop stop and restart every 10000 iterations, writing the data to file.

Yes I would like the 3 tasks to be perfectly synchronised, if possible - without slowing the execution speed.

Sorry for not giving a proper description of my program from the outset though you have sussed it with no problem! 🙂

Thank you

Ingram

[DrMundoGoesWhereHePleases]

Hi Jamie,

I have attempted to implement the producer/consumer architecture as you suggested. This has made my code much neater and efficient, though I'm still struggling to find a way to read the period channel each time the producer loop is triggered without doubling my iteration time (hence missing trigger pulses).

I'm not sure on how deals with multiple counter tasks. Originally I was measuring the period of the digital pulse on dev2. But I thought the reason for the loop slowing was accessing the same physical terminal. I then wired the pulse from dev2 to dev1 and measured it on the pci 6220. This does not appear to make a difference. Any direction with regards to how Labview deals with counter tasks would be appreciated.

Thanks!

Ingram

[Jamie_S. · Accepted solution]

Hi Ingram,

Thank you for your post, the code certainly looks more compact and this method allows you to continuously log which is adventageous to the application.

With regards the doubling in loop execution speed you are experiencing when performing the Counter period measurement, out of interest how long (in terms of time) is the period of the digital pulse you are measuring? If the period is large this could account for the long read time.

I would also recommend placing a "DAQmx Start Task VI" on every DAQmx line entering the loop (just after the configuration steps) this will allow the counter task to start running before entering the while loop which might improve the performance.

If the pulse period you are measuring is large it may very well be worth seperating the Counter task into a seperate Producer loop or introduce a Timeout on the counter "DAQmx Read VI" to see if that improved the execution speed.

Many Thanks

[DrMundoGoesWhereHePleases]

Hi Jamie,

Thank you, I have just checked and you're correct - the period measurements I'm taking are causing the programme to run more slowly as I'm triggering and measuring the period off the same edge. I have switched to measuring the frequency off another channel on the encoder and now everything works fine.

Have a nice weekend!

Ingram