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.
