USB Temp Data Logger

[baptie]

We have been working on a user interface that is coming along nicely, We are starting to pole connected devices to get relivant feedback to supply onto the front panel.

This is all going really good but we hit a stumbling block:-

We have purchased a Temp data logger from Pico technologies that communicates over USB, the device allows you to connect up 8 K type themocouples.

For test purposes I have connected up 4off thermocouples and have got the relivant readings onto the front panel, the problem we have is that when the device takes a batch of 4 readings, this process takes just over 500ms, this 500ms is causing a delay in the movement of the front panel controls making slides and buttons not react fast enough as there is a delay every 0.5 sec.

At present we have the UI within a while loop and the data logger within a seperate while loop external to the main UI. Using property nodes to enable/disable the device.

I have tried the event handler method and at the min I am working on a state machine, all works well but when I activate the data logger I get this delay every 0.5s.

I have placed in wait for next 600ms, delays & attempted to slimline the supplied VI's supplied with the device.

The question I am asking is, is there a way to run this device on a totally different thread to the user interface to take away the noticable delay & still have the data logger run away happily?

[Donald]

How do you connect to the device? Do you use a DLL or the USB communication functions of LabVIEW?

I suggest you add a screenshot of your code.

[martin@aerodynamics]

....is there a way to run this device on a totally different thread to the user interface to take away the noticable delay & still have the data logger run away happily?

In LabVIEW you can make as many parallel loops as you like...

[baptie]

The Device uses .dll's supplied by the manufacturer of the data logger.

This is our User Interface, All the property nodes are used to set up the relevant graphs, colours & scales of the graghs.

The problem is the bottom loop, We have set the default on the usb data logger to be 4 sensors.

We Init usb, open device id = 1, set up number of samples = 4, take readings/format array, output 4off reading, repeat from take reading stage.

While the data logger is retrieving data, the user interface controls bog down every second, for around 1/5 a second.

We tried added a delay of a second,to make sure that the logger only gets readings once every second.

We have tried the 'wait until next' 600ms in the attemt to let the temp logger work away when the time is there.

Temp Reading.VI

this VI takes the handle (id) of 1, sets up an array of 9 elements(8 for the max number of sensors, 1 for cold temp reference), overflow & units are default value's.

Time taken for 1 reading 200ms

Time taken for 4 reading 500ms

Time taken for 8 reading 900ms

No matter what we try, the data logger clogs up controls, is there no way to call .dll's within labview BUT not have the device operating WITHIN labview & still enable us to get reading back?

Hope makes it a little clearer!

[Donald]

Hello,

The DLL is causing the problem by blocking the user interface thread. If the DLL is threadsafe you can run it in another loop (subvi) which is configured to run in another thread e.g. I/O.

Is the DLL threadsafe???.... if LabVIEW crashes it isn't :-) If it doesn't crash, you're still not 100% sure...try asking the supplier of the DLL..

A possible solution is to build 2 apps. One GUI and one data capture process. Communicate by Data Sockets, Inter process shared mem (cfr pipes) or tcp/ip sockets. (NOT queues).

Good luck,

Donald

[Neville D]

Moral of the story:

Stick to NI Hardware; the few bucks you save using "other" hardware isn't worth it in the long run.

Cheers,

Neville.

[baptie]

Thanks Donald,

Had a look at the bottom level .dll that was being called in the 'Get Reading.VI'.

Had a look at the properties and I noticed the make reentrant check box.

Works a treat, the data logger runs away happily, still taking 500ms for a full read but the read operation does not interfere with the UI.

Thanks man, solved a large headache for me.

Stevie

[Rolf Kalbermatter]

Thanks Donald,

Had a look at the bottom level .dll that was being called in the 'Get Reading.VI'.

Had a look at the properties and I noticed the make reentrant check box.

Works a treat, the data logger runs away happily, still taking 500ms for a full read but the read operation does not interfere with the UI.

Thanks man, solved a large headache for me.

Stevie

Yes but!!!!! As long as this call is the only one to this DLL in your entire application you are fine. But if you ever decide to add this VI or another one calling into that DLL somewhere else in your LabVIEW program you are creating something I call "peut-

[baptie]

QUOTE(rolfk @ Feb 9 2007, 02:51 PM)

Yes but!!!!! As long as this call is the only one to this DLL in your entire application you are fine. But if you ever decide to add this VI or another one calling into that DLL somewhere else in your LabVIEW program you are creating something I call "peut-être". It may work fine one day, crash or produce bad results the other and in between do more or less both at the same time. So it is not a save all headaches solution but may be ok for you.

Rolf Kalbermatter

Yes you are correct Rolf, But this .dll will only be called in this user interface but I can understand what you are saying, one day it may work the other it may not.

I am happy that it is working and not clogging up the User Interface plus not effecting the outputted results.

Thank you very much for assistance.