USB buffer size

benecito · 6 Dec 2023, 14:58

Since I could not find anything just a quick question:
We're printing from RepetierServer on multiple machines running either 3mini's, 6hc's or 2wifi's using USB.
What is
a) the maximum buffer size we can use for the usb communication
and
b) the recommended buffer size should it be different from the above

Should it be different for the different boards, please let us know for each.

@CR3D FYI

dc42 · 6 Dec 2023, 15:40

@benecito Duets have always used true USB ports, unlike the old 8-bit boards that Repetier was originally designed to work with. Because of this there is flow control over the communication channel. So there is no maximum buffer size, because when the Duet is unable to receive more data this will be signalled to the PC, which will stop sending data until the Duet can accept more. Depending on how Repetier is written, the task in Repetier that is trying to send more data may block until the data can be sent.

If you use a very large buffer size then the time it takes to respond to a pause or other interruption commanded by Repetier will increase. This is because there is no mechanism in the serial GCode protocol for the pause message to jump commands that have already been sent (unlike when printing from the Duet's SD card).

The USB receive buffer sizes in various builds of RRF are as follows:

Duet 3 Mini: 512 characters
Duet 3 6HC and 6XD: 640 characters
Duet 2: 640 characters

So I suggest you use a buffer size no larger than 512 characters to avoid transmissions blocking, and smaller than that if faster response to pause commands is required.

HTH David

benecito · 7 Dec 2023, 07:53

@dc42 thanks for the quick reply! The reason we're asking is a spurious phenomena we have on two printers right now (duet2 and 3.4.1). It appears one command does not get an ok which in return blocks around half the buffer butting the printer into a kind of ping pong mode with roughly one command per second.
Sometimes this appears to happen again which results in a timeout and the print continuing fine afterwards.

You can see it happening in the below screenshot quite nicely in the highlighted part.

Hers an M122 while it was stuttering.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.1 (2022-06-01 21:05:28) running on Duet WiFi 1.02 or later + DueX5v0.11
Board ID: 0JD0M-9P6B2-NJ4S8-6J1D8-3SJ6R-TB4QK
Used output buffers: 3 of 26 (20 max)
=== RTOS ===
Static ram: 23860
Dynamic ram: 77504 of which 12 recycled
Never used RAM 9840, free system stack 88 words
Tasks: NETWORK(ready,1822.3%,242) HEAT(notifyWait,38.9%,308) Move(notifyWait,663.8%,282) DUEX(notifyWait,0.0%,24) MAIN(running,1279.0%,440) IDLE(ready,9.0%,30), total 3813.0%
Owned mutexes:
=== Platform ===
Last reset 44:36:32 ago, cause: software
Last software reset at 2023-12-05 11:48, reason: User, GCodes spinning, available RAM 10232, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 0
MCU temperature: min 25.3, current 33.1, max 34.5
Supply voltage: min 23.3, current 23.5, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min n/a
Driver 5: standstill, SG min 0
Driver 6: standstill, SG min 0
Driver 7: standstill, SG min n/a
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10: 
Driver 11: 
Date/time: 2023-12-07 08:24:36
Cache data hit count 4294967295
Slowest loop: 6.92ms; fastest: 0.12ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 4.1ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 36, maxWait 54387006ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 1165291, completed 1165291, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 1, 38901], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters 3 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.6
=== 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
USB 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== DueX ===
Read count 12, 0.00 reads/min
=== Network ===
Slowest loop: 19.20ms; fastest: 0.00ms
Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.26
WiFi MAC address 48:3f:da:a6:c0:61
WiFi Vcc 3.38, reset reason Power up
WiFi flash size 2097152, free heap 25272
WiFi IP address 192.168.186.225
WiFi signal strength -50dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

Maybe you have an idea and ideally a suggestion / a fix as well.

dc42 · 15 Dec 2023, 09:45

@benecito we recently found a bug in the handling of large amounts of USB input. This affects all Duets except the Mini5+. This may account for the issue you are seeing on your Duet 2. We've fixed it in release 3.5.0-rc.2 which we hope to publish today. So please try that release.