Problem in simulating a Protocol

[Manoj90]

Hi Every1,

I `m using Labview 2009 and `m a newbie and stuck up in a problem.

I `m simulating a protocol whose flow diagram is uploaded.The communication is done serially.

Working of this protocol is like dis:

1) Stage 2 is valid if and only if Stage 1 is successfully communicated otherwise terminated.

2) Stage 3 is valid if and only if Stage 1 and Stage 2 is successfully communicated otherwise terminated

3) So on.

I used a standard state machine with input command as the case condition.

my problem is "Single Input" ie if the serial input is INPUT1 den REPLY1 s coming and going next to stage 2(due to state machine employed) but since INPUT1 IS NOT EQUAL TO INPUT2 state machine is getting terminated 😞 upon entering INPUT2 no reply..... `m stucked up.

Any comments would be appreciated.

Regards,

Manoj

[johnsold]

Manoj,

It is difficult to tell what the problem is without seeing your code. Is your code running on Terminal or Device? How is "successful communications" defined?

Here is a guess based on this statement: "state machine with input command as the case condition"

From the protocol you described it seems that you have two conditions which must be met to proceed to the next Stage: It has received the input command AND it has received the confirmation message that the preceeding Stage completed.  My guess is that you are not lookaing at both conditions.

Lynn

[Manoj90]

Lynn,

Sorry here is my vi

Here terminal means a PC and device is my Labview Simulator & code is run in Labview simulator.

Successful communication means input is received and reply has been sent.

I shud proceed to next state upon getting the appropriate input & also confirming reply of previous input

My Problem is

upto 1st Stage my vi is ok. my vi ll reply for 1st input but..

wen i send 2nd input serially since input is the state machine condition and also 2nd input is not equal to 1st equal my vi s getting is getting terminated in 1st stage only

[johnsold]

Let me see if I understand you correctly.

The LV code you have posted runs at the Device.

Advance to the next Stage should occur when an Input(x) command is received AND a confirmation of the previous Reply message has been received.

Your code does not look for any confirmation of the Reply messages. Do you need this or not?

The code in the INPUT2 and INPUT3 states can go to the next state or to the previous state. Your protocol does not mention going back.

Setting the tunnels on the case structures to "Use Default if Unwired" may make your VI do things you do not expect.

You have termination characters enabled (default configuration) and you are using Bytes at Port. This combination is prone to communications errors.  Does the terminal send a termination character?

You branch the VISA Resource and error wires and close the port twice. Just wire them through the loop and eliminate one of the Close VIs.

You have a Stop state. Just wire a True from that to the termination terminal of the loop.  You do not need the Stop =? test.

Lynn

[Manoj90]

Dear Lynn,

My LV Code runs at the device i.e. LabView Software.

Hope my below explanation of protocol would give better picture

The mechanism of my Protocol is given below:

• In 1^ststate
  • If serial input =INPUT 1 den I`ll reply and direct my state machine to 2<sup>nd</sup> state.
  • If serial input ≠ INPUT1 den I`ll discard and stop

• In 2^ndstate
  • If serial input =INPUT 2 den I`ll reply and direct my state machine to 3<sup>nd</sup> state.
  • If serial input =INPUT 1 den I`ll reply and direct my state machine to 2^nd state (Like RESTART)
  • If serial input ≠ INPUT1 AND INPUT 2 den I`ll discard and stop

• In 3^rdstate
  • If serial input =INPUT 1 den I`ll reply and direct my state machine to 2<sup>nd</sup> state (Like RESTART)
  • If serial input = {INPUT 3 TO INPUT N} I`ll only reply and stay in the same state.
  • If serial input = INPUT N+1 I`ll direct my state machine to 4<sup>th</sup> state.
  • If serial input ≠ any of the above inputs den I`ll discard and stop
  • In 4^thstate
    • I`ll reply and direct my state machine to stop.

Problem `m facing is

• After running the LV Code, 1^st state is activated and upon receiving INPUT1 my code will reply and direct to 2^nd State. Fine!!

• In 2^nd state `m receiving the same INPUT 1 and getting loop back and not able to proceed further as `m expecting INPUT 2 and other successive inputs because I have wired serial input to all states
  

• If send INPUT2 or any other INPUTS serially, since INPUT 2 ≠ INPUT 1 my code is getting terminated/stopped in 1^st state only 😞

• I can`t able to proceed after 1^st stage. 😞

Advance to the next state occurs if and only if input for the previous state is received (since `m sure of sending reply to the input). Hence `m not looking for confirmation of reply messages.

My protocol goes back only if get INPUT1 at any point of time and state.

The format of the packet is <LINE FEED><DATA PACKET><CARRIAGE RETURN>. Both the terminal and my LV Code will send packet in the above format only.

Any alternatives for using Bytes at Port or to minimise communication errors?

Regards,

Manoj

[johnsold · Accepted solution]

Manoj,

Part of the confusion may stem from having both the communications strings and states with the same names.  The program does not have a problem with that, but it may be confusing you and me.

Alternatives to Bytes at Port: Yes. Since your messages always end with <CR>, change the termination character at the Configure VI to decimal 13 = 0xD = '\r' = <Carriage Return>. Then the VISA Read will wait until it receives a <CR>. The message returned has the termination character removed so you do not need the String Subset.  You can check the Return Count output to be sure that you got a message and not a timeout.

As for your stage advancement issue, Are you sure of what is being sent by the computer? You say you are in state INPUT2 and receive message "INPUT1" from the computer. According to your protocol the computer should be sending "INPUT2" after you send "REPLY1".  Your code in the INPUT2 state responds to the "INPUT1" message by sending "REPLY1" and returning to the same state (INPUT2).   It looks to me as though your program is doing what you asked it to do, but that the other computer is not following the protocol.

Is it possible that the other computer is repeating the "INPUT1" message several times while waiting to receive the "REPLY1" message?

Here is a cleaned up version of your VI showing the termination character changes.  I also removed the unnecessary sequence structures and made a few other changes.

Lynn

[Mark_Yedinak]

First, choose meaningful names for your states and commands. Your flow diagram does not show how you transition from the State 3 to State 4. What exactly is Input N+1? I would recommend creates states based on actual commands/events rather than on an abitrary Input N name. For example, in your flow document you provide information about your states so, name then the same. Have an Initialization state, an Activation state, a Running State, etc. I woudl also avoid all of teh nested logic you have where your internal processing in the satate also processes other messages. If you added a shift register to store that last message processed all of the logic for a given message (input) can be stored in the state that processes that message. No need to duplicate that code in other states.

Secondly, you don't need all of theose sequence frames in your code. You can set the state and format the command at the same time. There is no reason they need to run in order. Also, sequence frames should be avoided and you should rely on data flow.

[Manoj90]

Lynn,

Thank you for your vi.

Your modified vi is error-free but i found strange thing while running it. As I send input serially “<LF>INPUT1<CR>”, state machine is initialised to 1^st state then input is going to Default  case and eventually stopped and resulting in Timeout error.

Regarding stage advancement issue, in simulating protocol `m considering all the possible input combinations for eg:

• In 1^st state `m expecting INPUT1 but user may send any input. But my vi should act accordingly i.e. I should reply to only INPUT1 and discard other inputs.
• Similarly in 2<sup>nd</sup>state `m expecting INPUT2 but user may send any input.
  • According to protocol user should be sending “INPUT2” but if user sends INPUT1 (RESTART command) my vi should still send REPLY1 and stay in same state & waiting for INPUT2.
  • Apart from INPUT1 and INPUT2 I should discard.

My intention is for any possible input in any state at ant point of timen my vi should act accordingly.

User will repeat the INPUT1 message until he gets reply1 because it is the first command to start protocol as I can`t proceed further.

The problem occurs in INPUT2

• Firstly I send INPUT1 & ill reply & state machine will go to 2^nd state. Done!!!
• When I send INPUT2,  state machine IS AGAIN GETTING STARTED IN 1^ST STATE, SINCE INPUT2 ≠ INPUT1(in 1st state),  input is getting discarded & eventually stopped
• My requirement is before user sends INPUT2 (after getting INPUT1 & REPLY1) state machine should be already in 2^nd state (which is not going in my vi). Similarly for INPUT3 state machine should be in 3^rd state prior before getting INPUT3.

My present is working error-free but not working as per protocol. I`m not sure of Logic of my vi.

Regards,

Manoj

[Manoj90]

Thanks for your valuable suggestions 🙂

In the protocol there are many commands since i cant name them all i generalised them as INPUT 1,2.....N, N+1.

Input N+1 is the deactivation command. Once i encounter this input  while `m in 3rd state i shud jump to 4th state and reply. I know this thing isnt shown properly in Flow chart. Sorry for that.

I used frames just to ensure that reply is sent first then state is changed.

Regards,

Manoj

[Mark_Yedinak]

From a readablility perspective naming your states Input 1, Input 2, and so on is the wrong way to go. The code is very difficult to understand and will be equally difficult to maintain. You also don't have a good understanding of data flow. It really doesn't matter which order you set your next state output or sending the command. Both are inside a case statement and you will not exit that state until EVERYTHING inside it is done. Sequence frames do have their uses but those uses are very rare in well written LabVIEW code that uses good data flow. Not to mention that parallel processing of things can help performance. In order to implement a robust state machine you may need to keep track of the phase you are processing. A single Command processing state to process the command along with a state variable should work fine. You don't ned to have multiple instances of processing for the same input as you currently do. I don't have time at the moment to create an example but I will try to get back to it later if I can.