Hi Preitano,
I had not considered that implementation.
Let's walk through the code:
1. Write to the serial port (send command, etc).
2. Wait 200 ms
3. Either wait for timeout or have data at the serial buffer.
4. Read until serial buffer is empty.
I assume there are no delays inside the True case, simply a read serial port and an append to string.
And you use the value from "Bytes at Port" to set how many bytes to read. Seems okay.
Have you ever noticed loss of data? ie: not all messages are received?
It is true that you are reading at 57600. I am used to much slower speeds, such as 9600.
I don't see why you would have noticeable delays as compared with HyperTerminal. The only concern I would have is if some of the messages are lost due to not having a delay.
The thing to consider is that Hyperterminal (or other such sw) will read the port continuously and never stop.
In LV, you read until -- something --... then stop reading to process the data (make decision, etc.). And there is a bit of overhead because of it. It is this overhead that adds up with every iteration of the loop. Maybe someone can correct me, but I seem to remember that it is approx 4ms per action. So every iteration of your loop probably takes approx 20ms. Which is not that much... but it adds up quickly.
In terms of delays, what is the difference? Is it consistent? Does it slow down?
To trap the delay, you may need to be clever. The "Highlight Execution" is not your friend in this case 😉
However, if for some reason or other, the number of bytes reported by the buffer is not accurate, the "timeout" of the VISA Read may kick in and cause excessive delay. The only way to confirm this would be to compare the two values (number from "Bytes at Port" and actual bytes read).
Hope this helps..
Ray