Interfacing to serial port - verbose Duet 2 WiFi

[achrn]

I'm adding some external hardware (microcontroller) that I want to synchronise with the print job running on a Duet 2 WiFi (RepRapFirmware for Duet 2 WiFi/Ethernet 3.4.4 (2022-10-20), Duet WiFi Server Version: 1.27 ).

So I've connected it to the Paneldue socket, and I have in my config.sys M575 P1 B57600 S2 and then I can splice into my gcode statements such as M118 P2 S"BX *", and my external hardware understands what it's supposed to do when it receives 'BX *'.

All good so far.

However, the external hardware is occasionally getting upset, and after some digging and head-scratching I discovered that at the end of a print job I have (for example) Finished printing file 0:/gcodes/setbars.g, print time was 0h 0m<LF> in addition to what I want to find on the serial line.

This is particularly troublesome because I'm only sending up to about half-a-dozen bytes at a time, so have no need of a large receive buffer, except that I now find a need to accomodate this loooooong message without said buffer overflowing and bad things happening. (In addition to coding it to ignore the message when received.)

Is there an easy way to dissuade the Duet 2 WiFi from being so verbose? Can I tell it to only put what I explicitly ask for on the serial port, and not anything else it feels like chatting about?

[dc42]

@achrn currently RRF assumes that any enabled aux port can be a GCode input device, and accordingly it gets sent any generic messages such as the one you observed.

Can you prefix your messages with a unique character sequence that doesn't occur in RRF messages? Then your ISR cold look for that sequence and only store some number or characters N after seeing it, before waiting for that sequence again.

I have it in mind for RRF 3.5 to allow a UART to be configured as something other than a GCode input device, and to provide a command similar to M260 to read/write from/to it.

[achrn]

@dc42 Thanks, yes I can code to ignore messages that aren't conforming to a format that I'm expecting, and actually I've now just increased the buffer so it will slurp in the longer message (and then ignore it). I was just hoping there was maybe an easy way to avoid the message in the first place.

Also, I might want to send GCode back the other way in due course (I'm just starting to play with that option), so I probably wouldn't want to preclude that.