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.
