Serial Handshake issue...

[MogaRaghu]

I am trying to send a command string from LV to a Logging utility client ( MCU based ) that has a loop interval of 1 sec. Since its an unsynchronized activity the command string reaches the client at random and there are occasions where the command string gets send twixce... rest of the requirement is explained in the VI.. Any suggestions to handle this situation elegantly is welcome. 

[Bob_Schor]

It seems to me your logic is slightly wrong.  Here's what I think you said you wanted to do:

1. Send <S> to request data.
2. Get data.
3. If "OK", then we're done.  Otherwise, go do Step 2 again.
4. Disable View File Button.

What I think you want to do is the following:

1. When View File Button is turned on, disable it right away.
2. Send <S> to request data.
3. In a While Loop,
   1. Get a line of data.
   2. If OK, exit the While Loop.  Otherwise, add the Data to the Logger.

If the above sequence needs to be done repeatedly (I'm not sure how you are using the View File Button, seems a bit strange to me), then you could put the above routine into another While loop to do multiple Reads, each consisting of "Send <S>, Loop until OK".

Bob Schor

[MogaRaghu]

OK the problem is solved by using a small VI that sends the required data ONLY ONCE even though it is inside a while loop. Once the required response is received from the connected client, the only once VI is reset. Works good.  Refer the attached VI which is in LV2017.

@Bob SChor... thanks for suggesting a solution. But i could not figure out - 

1. When View File Button is turned on, disable it right away.

I tried that with a shift register but could never get it do what i want..

[RTSLVU]

Wow that is some bad programming there...

If you only need to send the <S> once then it should NOT be inside the loop! 

Why is the View File control outside the loop and then you have a local for it inside the loop?

Once the OK is received the  VIEW FILE button is to be disabled to avoid any further Serial Write and Read.. 

Why not just exit the loop and stop the program if no more serial read or writes are allowed? 

[MogaRaghu]

---

@RTSLVU wrote:

Wow that is some bad programming there...

If you only need to send the <S> once then it should NOT be inside the loop! 

Why is the View File control outside the loop and then you have a local for it inside the loop?

Once the OK is received the  VIEW FILE button is to be disabled to avoid any further Serial Write and Read.. 

Why not just exit the loop and stop the program if no more serial read or writes are allowed? 

---

I understand that you are trying to help. For sure this is a public forum and it helps a lot to be polite. And most important when an expert goes this way, the OP gets defensive and in that process the valuable technical point takes a back seat.

Also the posts for help are mostly contextual in that only the part of a much larger code is snipped out for brevity and ease the life of people who genuinely want to help.  For instance the part I posted is part of a much large code that runs  24 x 7 and so I cannot do things like stopping while loops. 

The USP of this forum is the cordial atmosphere that exists and the support that even novices get from stalwarts in an atmosphere of sharing. 

[RTSLVU]

Yeah, sorry I was in a hurry and just did not have the time to write an example or explain better.

But even simple programs like this can benefit from a proper programing architecture. One big loop (OBL) is rarely a good choice of architecture.

If you have read any of my previous posts you will know I say this a lot, but a simple state machine would make your program more robust and the little problems you are getting stuck on like sending the <S> only once and disabling the button would be trivial to implement.

[MogaRaghu]

No issues mate ... yes big or small it pays to keep the coding style simple and elegant. 

And thanks for pointing about the SM ... will go that way and eliminate the circus to make a button T or F