VISA framing errors for multiline messages

[thoult]

This one's got me scratching my head a little.

I am communicating with a third party laser marker controller via RS232. I have a number of commands that, when sent, will generate replies. On reading them (VISA Property: Bytes at Port to VISA Read), I see two behaviours:

- for short messages, such as a status indicator, the read will complete fine with no errors. For instance, receiving the reply to ST, I'll receive 10\r - three bytes at the port, three bytes returned, no error or status generated.

- for multi-line messages, such as a list of all programs and fonts on the controller, the read will complete with the correct number of bytes requested and returned, but I'll receive an error -1073807253, which as we all know is a framing error. For instance, the following message is a response to the LE command - 193 characters at the port, 193 characters read:

TETE=160\r

SERIE=950922/001\r

COURSEX=110\r

COURSEY=110\r

PASX=25\r

PASY=25\r

VMMAX=50\r

VDMAX=3000\r

MATRIX=1\r

ENTREES=6\r

SORTIES=2\r

DMC=0\r

AXEZ=0\r

HPGL=1\r

UCBAR=1\r

PCBAR=1\r

EV=3\r

INVERSY=-1\r

IDTETE=04\r

FOCALE=160\r

SPE=\r

(I've added in the formatted line breaks, but the \r bytes are as-received)

I've read the KB; there's a flush after connection; the comms settings are correct; the cables are securely plugged in (yawn)... It's not timing between commands, as I'm manually debugging a functional global here: connect, flush, write, read states are executed in that order. and I'm not exactly lightning quick at changing the enum and pressing CTRL-R 😉

The issue seems to be with multi-line messages with CRs, as I can generate the framing error for any multi-line message but not for single line ones. The last byte of each message is always a carriage return, as you can see in a multi-line, there are additional CRs.

I still read the reply fine, and get the data that I want back. I can just clear the error as it occurs and ignore it, but it feels like there might be something I'm missing.

[crossrulz]

Do you have the termination character turned on?  Does the device send a Line Feed (0x0A) at the end of the message?

Assuming the LF is not sent, I think I would set my termination character to be 0xD (CR) and then read inside of a FOR the number of desired recieved lines.  No need for the Bytes At Port that way.  Using the Bytes At Port tends to open you up to weird race conditions.  So if you have a termination character, you should use that.

[thoult]

Theoretically, the termination character from the controller is a CR, which indeed allows me to cycle through the multiline message one line at a time. I explicitly enable this in a property node after connection, although up to now I've had it switched off to read a chunk rather than line per line.

Reading an expected number lines would work (or reading until the buffer's empty; it's a simple system, so I don't have to worry about messages generated from somewhere else) but the behaviour persists: reading the first line returns error -1073807253, subsequent line reads return 1073676293, which is the 'termination code found' warning that I'd expect to see that way round.

I can't see any content in that first line, barring the CR, that would cause an issue. I guess I'll just have to interpret the first line error as a warning. Alternatively, I can split a multiline query into a series of parameterised queries, which is a nice way of burying my head in the sand! 🙂

Regarding the Bytes at Port / race condition comment you made, do you have any further info on this? Sounds like something worth reading more in general.

[crossrulz]

---

thoult wrote:

Regarding the Bytes at Port / race condition comment you made, do you have any further info on this? Sounds like something worth reading more in general.

---

Well, it is simply that you have to wait so long to allow the instrument to respond before actually checking the number of bytes at the port.  If you send the querry command and then instantly check the number of bytes at the port, you will likely read nothing.  So you have to add a wait.  But then how long do you have to wait?  I've seen the needed wait range from 10ms to 500ms.

But if you just use the termination character, you can just go straight into the VISA Read with the number of bytes to read set to something rediculously high and you will get your response up to and including the termination character.