read a serial buffer the correct and secure way

[Labuser16383]

I have a questing about reading anwsers which will be send aver the serial port by a motor control.

Of course this task seems at first trivial as one would think:

1.) test for number of bytes at serial port

2.) read bytes from serial port

3.) test if all bytes have been read

4.) if not, return to 2

However this does not work with that fxxxx stepper motor control because the serial buffer is not filled instantly at the moment you expect it,

for example if you send a command like motor select or travel distance to the device and then want to get a feedback.

a) There seems to be between 10ms and 60ms delay between the command from the host and the answer from the motor control.

b) The serial buffer is not filled at once. if you check every 10ms for number of bytes at serial port, the value rises until it receives a maximum value and the stays constant

c) The desired answer from the motor control is sometimes interrupted by other answers. for example, if coded motor state is requested during the motor runs you receive probably an b which stand for motor travelling down, then READY which is the standard answer and then a which stands for motor stopped.

My question is not about parsing all the answer strings from the motor control but about how i securely read the bytes from the serial port without

1.) loosing chars

2.) get garbled strings which will be received partly on one buffer read and partly on the next one

Therefore i attached my readSerialBuffer.vi (LV2013) which tries already to handle the problematic cases but still fails in the more insistant ones.

The motor control i am talking about is the ORIEL Encoder Mike Controller 18011 (which is very historic, but as everybody scientiest knows you cannot always do something about it. The manual still contains a section about how to attach it to an apple II computer)

[deceased]

Can you give some more info about the messages and responses?

Is there is a standard terminator at the end of each message (such as CR/LF)?

Deceased

[Labuser16383]

Ohh fxxx, i just switched the control programmatically to local mode during drive.

That garbled the serial response.

If i had not started writing down the serial messages to answer my deceased ancestors i would have found it out more lately and wasted more time.

However i do not need to post them here anymore.

[RTSLVU]

---

@Labuser16383 wrote:

I have a questing about reading anwsers which will be send aver the serial port by a motor control.

Of course this task seems at first trivial as one would think:

1.) test for number of bytes at serial port

2.) read bytes from serial port

3.) test if all bytes have been read

4.) if not, return to 2

---

You are doing it wrong.

1. Look at the serial data format and determine if it is sending a termination character (Carriage return, Line feed, both?)
2. Use the VISA Serial setup VI to set the termination character and enable it
3. Set VISA read to read an arbitrarily high number of bytes.
4. Read until you receve the termination character or timeout (read will automatically stop on one of the two conditions if Termination Character is True)
5. Clear timeout errors

[Labuser16383]

Thank you for your feedback. However, the initialization of the serial port is done at another place where i also set the termchar to

cr(13) and enabled it. Baud rate is 19200, data bits is 8, parity is none and stop bits is 2.

I tested these settings with a terminal (Hterm) and they should definitely be correct.

As i said, my readSerialBuffer.vi works now after i found out that i accidently switched the device to local mode (it does not respond to serial commands and breaks filling of serial buffer, then) between reads.

I think your way is more simple but maybe a little bit too simple as the serial buffer maybe continuing to be filled during read.

I'll try to incorporate it anyway into my code.

[RTSLVU]

In general using "Bytes at port" is never a good idea.

If you are getting buffer overruns using the Termination Character method then you need to decouple your serial read from the rest of your program using a Producer-Consumer architecture.