UART 'PanelDue' vs 'Raw' modes

[achrn]

What is 'PanelDue mode' vs 'raw mode' on the UART serial port?

I've been doing some playing with M575 and with respect to what is sent to the Duet, I don't find any difference at all - I haven't found a difference between modes 0 and 2 or between 1 and 3 or between 4 and 6.

with respect to responses from the Duet, the only difference I've observed is that the 'raw' modes terminate every response with '<lf><lf>ok<lf>' while the 'PanelDue' ones just terminate with '<lf>'. Is that the only difference between the two modes? I feel there ought to be more to it than that and wonder what I'm missing.

(My testing is all talking to a Duet 2 WiFi with RepRapFirmware for Duet 2 WiFi/Ethernet 3.4.4 (2022-10-20).)

[dc42]

@achrn in PanelDue mode:

• Responses to commands are not sent automatically but are queued up until PanelDue polls for them
• Messages that are not responses to commands are JSON-formatted

Duet 3 boards have two serial ports and PanelDue mode is currently only supported on the first one.

[achrn]

@dc42 Thanks. That leads me to spot the flaw in what I was doing - I was testing with M409s, which always respond in mostly JSON. Yes, if I use e.g. M450s it's very obviously different:

In raw mode:
send: N4 M575 P1*22173<lf>
recv: Channel 1: baud rate 57600, requires checksum, raw mode<lf>ok<lf>
send: N5 M450*02321<lf>
recv: PrinterMode:FFF<lf>ok<lf>
send: N6 M409 K"move.axes[].userPosition"*07536<lf>
recv: {"key":"move.axes[].userPosition","flags":"","result":[0,0,0],"next":0}<lf><lf>ok<lf>

In PanelDue mode:
send: N7 M575 P1*31705<lf>
recv: {"seq":13,"resp":"Channel 1: baud rate 57600, requires checksum\nok\n"}<lf>
send: N8 M450*18258<lf>
recv: {"seq":14,"resp":"PrinterMode:FFF\nok\n"}<lf>
send: N9 M409 K"move.axes[].userPosition"*22596<lf>
recv: {"key":"move.axes[].userPosition","flags":"","result":[0,0,0],"next":0}<lf>

(In all cases where '<lf>' is a single linefeed byte - 0x0A - but '\n' is two ascii character bytes.)

And, yes in Raw mode
send: N19 G1 X100 Y45*42999<lf>
recv: ok<lf> (and does the move - not sure of the timing),
but in PanelDue it does the move but doesn't respond on the UART. How does PanelDue poll for responses?

[dc42]

@achrn said in UART 'PanelDue' vs 'Raw' modes:

How does PanelDue poll for responses?

I was wrong, it no longer polls. Responses are sent to PanelDue in JSON messages with fields "seq" and "resp". You can see some of these in the trace you posted. RRF does not send "ok" after responses addressed to PanelDue, so if the command didn't need a response then there isn't one.

[achrn]

@dc42 Thanks for clarifying.

On a related matter, I think there's an improvement that could be made in the code with respect to processing an M575 status reply.

In src/GCodes/GCodes2.cpp, the 'case 575' has (currently at line 3557 on GitHub)

reply.printf("Channel %d: baud rate %" PRIu32 ", %s checksum", chan, platform.GetBaudRate(chan), (cp & 1) ? "requires" : "does not require");

Which means that the 'CRC only' modes are reported simply as 'does not require checksum'.

I think it could be better as

reply.printf("Channel %d: baud rate %" PRIu32 ", %s CRC%s", chan, platform.GetBaudRate(chan), (cp & 5) ? "requires" : "does not require", (cp & 4) ? "" : " or checksum");

Which should give a more accurate message. (But untested - I'm assuming cp contains the M575 'S' parameter value - it uses Platform::GetCommsProperties, which is in src/Platform/Platform.cpp, where that and Platform::SetCommsProperties don't seem to do anything but store/retrieve the 'S' value in/from uint8_t commsParams, but something else might tamper elsewhere. I've not actually tried building firmware with my change so it might also e.g. overflow 'reply' or do something else bad elsewhere.)

[dc42]

@achrn thanks, I've corrected that message in the RRF 3.5 source code.