It would be really interesting to support Image serving in the M291 command to better allow setup procedure to be shown that aren't easily described using text.

Use cases would be things like CNC setups, cleaning procedures, bed prep procedures, warnings to clear certain areas, etc.

I( have a couple of procedures where it would be really helpful to allow operators to check visual references against an image.

This could even be a pi exclusive feature if the Duet 3 MB6HC can't handle serving image files.

See this reference from HAAS on what this could look like. Massive Cheese warning....
https://www.youtube.com/watch?time_continue=2&v=_FxHfVKSOcs&feature=emb_logo

You'll want to use the general IO headers for this.
Choose one, I usually start with IO_1.
Connect 5V_ext to V+.
Connect Ground to Ground.
Connect the Signal pin to IO_X.in

It's mostly that I use them for prototyping very often for high value projects. It is a fun problem to have though.

I have a similar situation where this would be very useful in general for heater outputs for multi-heater beds and extruders and other things.

Perfect, thank you!

It would be very useful to expose a rand function in gcode meta commands for purposes of wiping macros for using different areas of brushes and such.

How do I include newline characters in string literals in GCode meta commands?

Seconded. Would be very useful to have for customization.

Hi, I noticed the modulo operator doesn't seem to be supported in RRF. This would be very useful for implementing macros such as every X layers, or every X iterations.

It occurs with 3.1.1 also, DWC is 3.1.1

I have a similar situation where this would be very useful in general for heater outputs for multi-heater beds and extruders and other things.

I'm having trouble getting a 212MB file you upload over the web interface, It keeps getting corrupted and I get errors such as Error: Uploaded file CRC is different (6acd12c1 vs. expected d18ebd88).
I am using the SD card that came with the duet and I am running RRF3.2beta.
Here is the M122 output.

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2-beta running on Duet 3 MB6HC v1.01 or later (standalone mode)
Board ID: 08DJM-956L2-G43S8-6J9FA-3S86J-1B3QF
Used output buffers: 1 of 40 (23 max)
=== RTOS ===
Static ram: 154528
Dynamic ram: 163140 of which 24 recycled
Exception stack ram used: 320
Never used ram: 75204
Tasks: NETWORK(ready,288) ETHERNET(blocked,432) HEAT(blocked,1108) CanReceiv(suspended,3424) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,196) MAIN(running,4536) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 01:19:03 ago, cause: software
Last software reset at 2020-09-10 18:58, reason: User, spinning module GCodes, available RAM 75548 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04437000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 10
MCU temperature: min 30.1, current 32.3, max 32.8
Supply voltage: min 23.9, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0
Driver 0: standstill, reads 39250, writes 15 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 39249, writes 16 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 39251, writes 15 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 39252, writes 15 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 39252, writes 15 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 39257, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2020-09-10 20:17:19
Slowest loop: 1195.04ms; fastest: 0.15ms
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 4.5ms, write time 364.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USBchan is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 1194.75ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- Ethernet -
State: active
Error counts: 0 0 0 0 0
Socket states: 5 2 2 2 2 0 0 0
=== CAN ===
Messages sent 19008, longest wait 1ms for type 6018
=== SBC interface ===
State: 0, failed transfers: 0
Last transfer: 4743972ms ago
RX/TX seq numbers: 0/1
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0

Any ideas? I would really like to be able to upload files without cutting power to the machine to remove the SD and losing state.

I asked this a while back. See (https://forum.duet3d.com/topic/18095/sensorless-homing-on-expansion-board).

TLDR: Scheduled for RRF3.3

Sorry, that's sort of what I meant, being able to start a move with it's own feedrate in the middle of another move without having to do weird feedrate math, or if no C parameter is defined, start immediately on the second DDA ring.