Optimizing TCP/IP Data Collection from Davis Instruments Weather Station

[Liechsowagan]

Hello,

I am trying to collect weather data from a Davis Instruments Vantage Pro 2 weather station that communicates via TCP/IP over 10 Base T Ethernet.

I am using a collection of subVIs published by Vernier that each use Call Library Function to access members of a DLL.

The weather station updates a Weatherlink page and also publishes to Weather Underground. The station communicates on a single port, so to ensure that Weatherlink and Weather Underground are properly updated, the programming reference states that the port needs to be released for at least five seconds out of every minute. The port also needs to be released for 60 seconds every hour to ensure that the archive file is properly written to Weatherlink.

I have written a barebones VI to test the basic functions before I integrate them into my main project. The test VI uses two nested case statements controlled by the result of two modulous operations to release and re-establish the port as appropriate. As shown below, I am aiming for a ~5 second sampling interval:

As best as I can tell, the VI provides the desired functionality, however, it appears to be resource intensive. When it is running, the controls are slow to respond, and LabVIEW itself seems to bog down. Is there anything obvious that I should be doing differently to reduce overhead?

[GerdW]

Hi,

remove those 5000ms wait functions when you want a more responsive VI...
Apart from this the VI should run fine!

[Liechsowagan]

Hi GerdW,

Even with the wait functions removed, it still acts sluggish. When I drag the front panel window around, it takes about 15 seconds to acknowledge the move. Stopping the VI takes about 10 seconds, regardless of the wait time.

[GerdW]

Hi Liech,

I don't know those light-blue colored icons but I guess they will take their time for execution.

And as DATAFLOW dictates: you cannot stop a loop before all code inside has finished…

Other comments:

- there's a lot of network access involved, be prepared for some delays depending on the network connection you use

- doing a modulo operation on the output of the wait function and checking for a remainder of zero will most likely fail…

[Liechsowagan]

Hi GerdW,

You make a good point. I have no insight into what Davis Instruments coded in their library functions, so I may be observing additional programmed delays.

For the modulo operation, would it be more appropriate to wire to the output of the loop index, rather than the output of the wait function? Depending on the length of the wait, I would have to adjust the divisor to compensate, but might that be more stable?

I am still not certain what is causing the front panel to be slow to respond to being moved around the screen.

Thank you for your patience,

Liechsowagan