Jump to content

USB Temp Data Logger


baptie

Recommended Posts

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?

Link to comment

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

post-7183-1170776477.jpg?width=400

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

post-7183-1170775594.jpg?width=400

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!

Link to comment

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

Link to comment

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.

post-7183-1170925286.jpg?width=400

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. icon1.gif

Thanks man, solved a large headache for me.

Stevie

Link to comment
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.

post-7183-1170925286.jpg?width=400

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. icon1.gif

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-

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.