While loop with toogle button

[RobertoBozzolo]

---

@mikelmujika  ha scritto:

It's true. I switched to 500 and the delay has reappeared. It seems that if you get the whole answer, it doesn't show it right away. But if you get only a portion of it, as in the previous case, it works well. Why is this happening?

---

It what I said about the termination byte is true, with 50 bytes to read the function terminates upon receiving 50 bytes, while on 500 you are getting a timeout, which is 5 seconds by default. I see that you are not trapping communications errors but you should: it would help you to discriminate those strange behaviours.

[mikelmujika]

I don't think so. The function ReadComPort () doesn't have any relation with the InstallComCallback function. 

[mikelmujika]

And how can I avoid those 5 seconds?

[mikelmujika]

And I have another question. What does the ComReadTerm exactly do? It reads until the termination byte?

If it is like that why I received more than a line? I mean, if I get an answer where each line ends with a 13 why I get more than one line at a time?

I hope you understood me

[RobertoBozzolo · Accepted solution]

The situation may get confused if there is no certitude on the protocol and the functions.

You must be sure about which termination byte does your instrument use, and use it in reading responses. You have posted a function that uses ComRdTerm with 10 as the termination byte, next you have switched to InstallComCallback using 13, and you are comparing the results! Read instrument documentation and use the correct termination byte every time you read from it!

Next, read the help for ComRdTerm, where you can find:

Reads from the input queue until terminationByte occurs in buffer, count is met, or a timeout occurs. Returns integer value that indicates the number of bytes read from the queue.

Conditions are ORed: the function will terminate on the first one it meets.

(Further ahead you'll find a note about SetComTime which answers another question of yours)

Finally, carefully check for errors in reading, analyzing function termination byte and rs232err variable: with this you'll be able to understand how many characters you have read from the queue and if a timeout occurred.

I hate to be pedantic, but unfortunately PC programs are dumb: they do not a fraction more than what they are supposed to. It's your brain that must use them at best... but only if you know exactly what they do!