Leaderboard

By the way, here's an example (LV2009) of similar Harel state machine behavior without using objects. The main differences between this and the object implementation are that there is no state specific data or error handling in this example. The example also doesn't have any execution actions other than monitoring messages from the user. A couple things worth noting: 0. This example makes extensive use of local variables in the state machine loop. I did this for simplicity. Usually I will have a separate display loop and have the state machine send messages to it when fp controls need to be updated. 1. The producer loop does not directly initiate state transitions. It sends a message to the state machine requesting a state transition, which the state machine will do if a valid transition is requested. If an invalid transition is requested the state machine ignores the message, though in the past I have sent debug or status messages to the UI to let the user know what is happening. Allowing producer loops to directly control state transitions is IMO the single biggest flaw in the traditional QSM. You have to break that link if you want to create more robust and scalable code. 2. Using a "real" state machine means all my transition logic *has* to be contained in the state machine loop instead of distributed across several loops. It's way easier to verify that my code correctly implements the state diagram and way harder for other developers to use the state machine loop incorrectly. There is simply no way for a rogue producer to initiate a transition that violates the conditions defined by the state machine. 3. This model provides better separation from the UI. I have often seen devs disable front panel controls to prevent invalid transitions when using a QSM. I usually ran into synchronization issues when tried that--controls wouldn't always be enabled or disabled at the right time. Here I don't have to worry about that--the state machine just ignores the message. If I want to disable a control I'll have the UI display loop do that in response to the state transition messages sent by the state machine. (Not shown in the example.) 4. It's ridiculously easy (and safe) to have multiple producers controlling the same state machine loop. Just give the new producer a reference to the state machine's input queue and start sending it messages. Asynchronicity is not an issue as far as the state machine is concerned. (Try that with a QSM! ) ------------ When I wrap everything in classes the concept seems more complicated that it really is. I hope this example helps people understand the core functionality at work and why I think it's time for the Labview community to move away from the QSM (unless you're taking a certification exam.) If anyone feels like comparing implementations I'm curious what a traditional QSM looks like that has this same behavior. SimpleStateMachine.vi

The underlaying getaddrinfo() at least on Windows, will return all local network adapter addresses and LabVIEW will pick the first one from that list to use. So it binds to the actual default IP address of your machine. When you disconnect the cable this IP address (and adapter) gets invalid and your connection is working through an unconnected socket, which of course gives errors. When the cable is not connected at the time the address is resolved and the socket is bound, the first adapter returned will be a different one, it could be the loopback interface or your WIFI interface. So connecting the cable and disconnecting it does not have any influence on this connection. Using 127.0.0.1 or localhost explicitedly will bind to the loopback adapter and that one is valid for as long as Winsock is working, aka. until you shutdown your computer.