06-16-2011 10:33 AM
I've developed some full custom hardware modules that transmit data packets over TCP. I created a simple LabVIEW program that can read this TCP data from a single module and display it on a waveform graph. I based this some of the included LabVIEW TCP examples. My first program TCPreceiver3.vi works just fine. However when I tried to create new program that reads data from four modules simultaneously TCPreceiver2.vi, I ran into problems. If I try to read from all four modules in parallel, at least one of them always fails to read and this causes a timeout error that stops the VI. If I go back and read each module individually with the first program TCPreceiver3.vi, they all communicate reliably without incident.
I figured I may be approaching this wrong. I see there is an example for a multiple connection TCP data server in the LabVIEW but it doesn't seem to be quite what I'm looking for, and I'm not sure what to do next. Any suggestions would be greatly appreciated.
06-16-2011 11:01 AM
Try changing your read module to be a reentrant VI. As written the code cannot actually run in parallel since you only have one shared copy of the read module.vi. That means only one read can occur and all others must wait for the others to complete. If you change the VI to be reentrant each read can run in parallel.
Now I am not sure if you really want all four reads in the same while loop. I think if you want the data streams to be independent each read should be in its own loop. As written the loop will only run as fast as the slowest data stream.
06-16-2011 12:19 PM - edited 06-16-2011 12:24 PM
Thanks for the reply Mark.
I just did some more digging and it turns out that my real problem was that all of my little custom Ethernet modules were coming up with the same MAC address. Even though they all had different IP's, having the same MAC address was sufficient to booger up all of the communications. I reprogrammed them all with different MAC addresses and the problem disappeared.
I'm keeping the reads all in the same loop mostly for convenience so I can eventually dump all the data into one file for logging. The speed is not really critical for my application and these modules communicate quick enough that I'm not worried about them slowing each other down.
Thanks for the tip about reentrant VI's though. I was unaware of that feature and I've made the change to my sub-VI. It seems you learn something new about LabVIEW everyday!
06-16-2011 12:45 PM
If I were designing this I would probably write a reusable subVI which would contain a single read within a loop. I would have it post the data to be logged to a queue. I would then call the subVI dynamically for as many instances as I need. A separate task would be the logging task and it would process the data from all the reads in parallel and log it as necessary. The nice thing about the dynamic call is that you can easily have you program monitoring 4 devices today but expand that to 6, 8 or more later without requiring a change in your code. Something to think about. If you know for certain you will never need more than your 4 reads you can stick with your current approach. If there is a slight chance you will need to expand it the dynamic call will make that easy.
06-16-2011 02:37 PM
Thanks for the suggestions, Mark. For now, I think we're sticking with 4 devices but when I have some spare time, I think I'll play around with implementing it like you suggest. Just in case they change their minds down the road 😉
Thanks again for your help.