Leaderboard

Pretty interesting, which is why I told you about it. You posting it kinda feels like you are stealing my internet points. I'll just have to make some posts around here that don't add anything to the conversation to get my post count up.

I think you've misunderstood something slightly. Accepting multiple connections on a single port is the same regardless of whether the connections originate from a single IP address or different addresses. Outgoing connections are assigned ports (usually automatically), and so long as the port/IP address combination is unique, there should be no problem. To accept multiple connections you need to understand the difference between a listener and a connection. In newer versions of LabVIEW (2011, haven't checked 2010), TCP Listen has a listener output. In older versions (LabVIEW 2009, maybe 2010) you need to use TCP Create Listener and Wait on Listener yourself. When Wait on Listener returns a new connection, you need to handle that new connection and continue listening on the listener for more connections. There are a couple of ways to handle this; the common ones I know of are 1) dynamically launch a VI to handle the new connection, or 2) add the new connection to an array of connections in a separate loop, and iterate through the connections continuously, sending or receiving data as appropriate on each one. You may find this thread about listeners and connections helpful. It also explains why you should not open and close the listener for every connection, in case you're doing that. http://forums.ni.com/t5/LabVIEW/TCP-IP-feature-or-bug/td-p/832692

Just took a look at your code. Some comments (though they may not relate to the strange behaviour you are experiencing): 1 There is no VISA Close Session. If you run this code a number of times, I am not sure it will behave stably. Add VISA close at the end. This will also allow you to access that serial port with something like HyperTerminal if desired. 2 Usually Serial reads are accomplished by polling "Bytes at Serial Port" in a reasonably slow loop and then reading the required number of bytes with the VISA Read. See attached. 3 I am not sure why you have a VISA Asynchronous Write.. just right-click on it and make it Synchronous (that was the old default behaviour).

Does anyon know if Norm's state machine has been born yet? I sure hope we don't have to wait 9 months after NI Week... Rebirth of the LabVIEW state machine 8/6/12 (Monday 6th),4:30 PM – 5:15 PM,17 B Norman Kirchner, Senior RF Systems Engineer, National Instruments

The risk with a system like this is that it is very easy to end up with the queue communications embedded within your code modules. This can reduce the reusability and scalability of your application so I prefer wiring the reference, especially as 3 of your functions just wrap queue primitives anyway.

The optimization is *already* in LV 2013. I saw the changelist go through about two weeks ago. This should not be taken as a promise that it will still be in 2013 when all is said and done -- features have been backed out before -- but I think this one is a fairly safe bet.