can,
On the receiving end, I would suggest that you not bother with the INPUT$(ch) function. The documentation leaves out a bit of its behavior:
To return a string obtained from communication port # ch.
ch must be a numeric constant between 1 and 8. The actual target hardware determines the valid port #. This function returns an empty string if there is no valid string waiting at serial port in order not to hold up the CPU.
These are some of the things not documented:
The maximum number of characters returned is limited by the string variable. Most of TRI's PLC’s strings are limited to 70 characters. EEP$ strings are usually 40 characters max. If the message is 80 characters in length, you will have to make multiple calls to read the message.
The actual function does not return the end of line character. So if your protocol uses an end of line character you will not see it. If your protocol uses a pair of characters to mark end of line, CR and LF, it will discard one of the pair of characters and the other will be returned in the string. I don’t remember what the function considers end of line.
If you receive a 0 length message, then the receive buffer is empty. This does not always indicate that you have reached the end of message. If you wait a few milliseconds you may find that more characters have arrived.
Because of the string variable length issue, the loss of the end of line character and the detection that the receive buffer is empty, I find that INPUT$() is not worth the effort.
I use the function INCOMM(ch) as it has fewer limitations. And, since you see all characters it is easy to detect the end of message. It is an easier function to determine if the receive buffer is empty as it returns the value -1 on this condition.
Gary d