LabVIEW
Serial communication
As always, we cannot debug images because a lot of important information is missing (eg. what's in the other cases of the case and event structures, why is there a timeout event AND a loop wait? Why is there no event for the stop button? Where do the partially hidden wires connect? Is the string control multiline or limited to single line? Should the user entry be terminated with special characters? etc. etc.). Attaching the actual VI is most helpful.
The use of "Bytes at port" is typically suspect. A good place to start is Tim's presentation here.
@ms6 wrote:
Microcontroller coding has been done properly.
There are many ways to do it "properly". What is the expected format of the commands and response? Number of bytes? Termination characters, etc. etc. Can you give the full specifications?
@ms6 wrote:
Microcontroller's flow: If i input a word or a letter, it will respond back with the first letter.
That's a suboptimal protocol! When does your uC know that it received the entire word? The "ok" you send could theoretically send like this: "o", 10 seconds of waiting, "k". Never ever will happen?? No! It's unlikely indeed but not impossible. Nothing about RS-232 guarantees that the individual bytes are always sent immediately after each other. Windows may start moving the first byte to the serial device driver, then a super important DMA interrupt occurs, grabbing control exclusively to itself and your serial port is idling waiting for the next byte.
Your uC sees the o, waits some short time, decides: Ohh that apparently was it, lets return the "o" and then the "k" arrives later and it decides, ohh another message, lets return the "k".
And your LabVIEW return waiting for the initial "o" is out of sync with your controller as it sent an extra "k" that your LabVIEW program never expected. Instead you send "goodbey" read the response back and read "k".
If you define a protocol you have to choose between these three choices:
1) use a termination character (sequence) such as <carriage return> (\r) that indicates that the command and response is finished. Here you can use the default termination character handling that VISA provides.
2) Make the messages fixed size, that way your controller knows to always wait for n characters before trying to interpret the command, and your communication program knows that your controller always will send m characters.
3) use a fixed size header that indicates the number of variable sized bytes that will follow.
