tcp state machine trigger

[dbrittain]

Hello, I am working on some statemachine architecture, I was wondering what the best method of sending states between vis could be. Essentially I would like to send states to be read over TCP as triggers for the various parts of the statemachine in another VI. Basically it would be like the following:

VI1: Statemachine1: Idle->State A->Send Trigger (Trigger1)->Wait for trigger (Trigger2)-> State A or ->End

VI2: Statemachine2: Idle-> State B-> Wait for trigger (Trigger1) -> Send Trigger (Trigger2) -> State B or ->End

State A and State B are arbitrary, Trigger1 and Trigger2 I am hoping to be merely state cases sent via TCP. 

[Mark_Yedinak]

Are your VIs in the same application? If so you can use notifiers or queues. They will require less effort on your part than using TCP. They are also event driven.

[dbrittain]

No they are not in the same application, I would have used them if this was the case. 

[GregFreeman]

my suggestion would be in each application have a tcp loop and a Queued message handler loop. State machine 1 goes to state A, puts a 'send trigger1' message in a queue to its tcp loop. The TCP loop reads this from teh queue then sends this message to application 2, which reads it, stick the message in a queue to the state machine 2 loop to process.

By doing this you decouple your tcp logic from your state machine logic. From my experience, it is never good to mix network communication logic in the same loop as your data processing. TCP does some weird things if you aren't getting back to the "TCP Read" function on one end as quick as you are writing on the other end. I tried this once a couple years ago in order to simplify my architecture on a relatively simple and quick program, but it actually ended up taking more time troubleshooting the TCP IP. Now I always keep them separate.

[dbrittain]

Interesting, I will give it a try. So to handle it, a simple producer/consumer type structure for the queue/TCP? 

[Mark_Yedinak]

I would agree than that you should have a separate task hanlding you TCP connection. This task would then use a queue/notifier/event to pass the command to the processing code or state machine.

[GregFreeman]

yup, just arbitrarily pick which will be the server and which the client. If you are using RT, I always put the server on the RT platform, because you can wire a timeout of -1 to the listener and it can always be listening. You are able to do this since the program doesn't shut down, so you never have to service an exit command and stop the tcp loop; the user just powers the system on or off.

[dbrittain]

I will try. I am a little confused as to how to send the state to the queue itself before it gets sent to TCP. Since the statemachine is in its own loop, and the queue is in its own loop, how do I send the state from one to the other? 

Right now I have :

Loop1: Statemachine

Loop2: TCP

Loop3: Queue handler

For the obtain queue function I have the enum constant ring set for two states (triggerout and triggerin). My question is how do I send the state I want to the enqueue element block from a seperate loop?

[Mark_Yedinak]

Your state machine should also be the queue handler. This is what some would call a queue driven state machine.

[dbrittain]

So this is not done yet, but am I on the right track? Any suggestions?