Moving house

Busy day:

• Removal van arrived 8:40, left 11:30
• Call from estate agents saying we could collect keys 12:45
• Arrived at house 13:40
• Picked kids up from schools and got back to new house at 15:40
• Removal van left 16:00
• Kids beds up by 19:30
• Chinese at 20:00
• All kids in bed 21:00

Everybody loves the new house, plenty of space and kids can get to sleep without the older one disturbing the younger ones. Martin went around the house looking at everything saying 'That's perfect!' to everything when he first got here.

BT line installed on Friday by about 11:00, called Orange and they can't do anything about broadband until line has been active for 2 working days so said call back Tues eve. Also could take upto 10 working days to active. So I'm paying for broadband for about two weeks with no service and it's my fault for moving house!

Using mobile broadband on the 3 network with a USB dongle. Seems reasonable but not sure how long 1Gb will last, not going to visit iPlayer for a while.

Multi threaded LabVIEW execution

Using four different RS485 serial ports to communicate with four data acquisition devices, each with four channels it should be possible to sent commands to the each device in turn while waiting for a response from the first. This will greatly reduce the time required to poll all channels. So why is it taking over 40 seconds for all channels on all ports when it takes less than 10 seconds to poll all channels on one device. LabVIEW should be able to run each port in a separate thread.

We created a VI to handle the communication with the serial device. This would construct the command string, flush the receive buffer, write the command string to the serial port and wait for the response from the DAQ device. When the require data had been received the response string is decoded and the measured value is passed to the calling VI. Using four of these VI's wired to run in parallel, each with a different serial port set this VI worked.

Next we wanted to take ten samples from each channel of each device and run some basic statistical filtering to eliminate noise. We have our VI to take a single measurement so just putting this in a FOR loop to iterate ten times should give us the data we need. Now the communications appear to be taking too long. We are only taking ten readings from each channel and as we are running each serial port in parallel we should not be seeing the execution time increase we are. A quick check, ten readings from four channels with the communication specification stating that each channel should return within 250ms should give us around 10 seconds not the 40+ seconds we are getting.

Logging was added to the read from serial port VI using a little VI I use all the time. It allows me to log a string of data to a text file with a time stamp. Analysing this in Excel and plotting the timestamps by serial port showed some interesting results. The parallel execution was only in the layout of the block diagram, not the execution. Each serial port was accessed in turn only after all readings for that port were taken. So how did that happen?

The problem turned out to be that the part of the code that does the communication was not enabled for reentrant execution. Opening the VI Properties dialogue and selecting the Execution category allows us to set Reentrant execution.

Now we are able to take all the required measurements within about 12 seconds. This just leaves the filtering of each channel. A Producer-Consumer loop architecture was chosen for this so the measurements were taken in the Producer loop which were placed on a queue. Filtering was done in the Consumer which waited for data to appear on the queue before processing it. This prevented the filtering affecting the timing of the data acquisition.

Running LabVIEW as a Windows Service

Today I finally got around to using Visual Studio to create a Windows Service that will call a LabVIEW executable every 10 minutes to log temperature to a database.

We have been running a LabVIEW application as a service using a free version of FireDemon but found today that our corporate anti virus software marks the executable as a Trojan. Getting an exception for this will take ages so after referring to google I found an article on MSDN with the title Windows Services: New Base Classes in .NET Make Writing a Windows Service Easy.

In under an hour I had created a service, installed and tested it as described in the above article.

Our application requires an up-to-date temperature to be available to a number of machines. To measure the temperature we are using a USB data acquisition device connected to a thermocouple which is polled by one PC periodically and then updates a database. We have the LabVIEW code to take the measurements and log the temperature as we were using FireDemon to run this as a service.

We have Measurement Studio which allows us to use our data acquisition devices under Visual Studio but as we have LabVIEW code already in place to do the data acquisition and updating the database I will use this for now. Rewriting in Visual Studio is a job for another day.

After a few modifications to the example code in the MSDN article I managed to get our LabVIEW code executing every 10 minutes.

Since implementing this NI have produced a network attached DAQ device which we are currently looking at for future projects.