RRF 3.5 beta 4 not respecting axis limits
-
Hi, have a Delta with Duet 3 MB6HC in SBC mode w/Raspberry Pi 4 running RRF 3.5 beta 4 and I noticed today that It's not respecting the machine limits.
This is after it's been homed as well as G30, G32 has not been run
This is my M665 command which sets the radius to 150mm. Doing a pure X or Y move lets me go beyond that 150mm
M665 R179.423 L360.250 B150.000 H368.045
Here's M450, M208 and M564
Also here's M122, it's printing right now.
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.5.0-beta.4 (2023-06-08 23:41:30) running on Duet 3 MB6HC v1.0 or earlier (SBC mode) Board ID: 08DGM-9T66A-G63SJ-6JTDL-3SD6P-TS0HA Used output buffers: 3 of 40 (40 max) === RTOS === Static ram: 155012 Dynamic ram: 80940 of which 2976 recycled Never used RAM 103536, free system stack 136 words Tasks: ACCEL(6,nWait,0.0%,263) SBC(2,rWait:,1.9%,422) HEAT(3,nWait,0.1%,323) Move(4,nWait,0.2%,224) CanReceiv(6,nWait,0.0%,941) CanSender(5,nWait,0.0%,335) CanClock(7,delaying,0.0%,343) TMC(4,nWait,18.6%,61) MAIN(2,running,79.2%,444) IDLE(0,ready,0.1%,30), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 02:53:17 ago, cause: software Last software reset at 2023-08-02 21:05, reason: User, Expansion spinning, available RAM 107088, slot 2 Software reset code 0x6012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x04 Aux0 errors 0,1,0 MCU temperature: min 36.2, current 39.0, max 39.6 Supply voltage: min 23.8, current 23.9, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0 Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/28/4, gc cycles 0 Events: 0 queued, 0 completed Driver 0: ok, SG min 0, mspos 986, reads 10489, writes 101 timeouts 0 Driver 1: ok, SG min 0, mspos 972, reads 10489, writes 101 timeouts 0 Driver 2: ok, SG min 0, mspos 932, reads 10489, writes 101 timeouts 0 Driver 3: ok, SG min 0, mspos 754, reads 10569, writes 21 timeouts 0 Driver 4: standstill, SG min n/a, mspos 8, reads 10579, writes 11 timeouts 0 Driver 5: standstill, SG min n/a, mspos 8, reads 10579, writes 11 timeouts 0 Date/time: 2023-08-02 23:58:43 Slowest loop: 92.65ms; fastest: 0.06ms === Storage === Free file entries: 20 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 125, segments created 28, maxWait 4419377ms, bed compensation in use: none, height map offset 0.000, ebfmin 0.00, ebfmax 1.00 next step interrupt due in 31 ticks, disabled === DDARing 0 === Scheduled moves 8432, completed 8429, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 76], CDDA state 3 === DDARing 1 === 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 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 0 is on, I-accum = 0.0 Heater 1 is on, I-accum = 0.5 === GCodes === Movement locks held by null, null HTTP* is doing "M122" in state(s) 0 Telnet is idle in state(s) 0 File* is doing "G1 X-55.341000 Y-132.442001 E0.010550" 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 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 File2* is idle in state(s) 0 Queue2 is idle in state(s) 0 Q0 segments left 1, axes/extruders owned 0x80000003 Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === Filament sensors === Extruder 0 sensor: ok === CAN === Messages queued 93566, received 0, lost 0, boc 0 Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 51988/0/0 Tx timeouts 0,0,51987,0,0,41577 last cancelled message type 30 dest 127 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 19497/19497 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x25ce8 Buffer RX/TX: 192/1704-0, open files: 0 === Duet Control Server === Duet Control Server version 3.5.0-beta.4 (2023-06-09 10:49:49) File /opt/dsf/sd/gcodes/frieza_base.gcode is selected, processing File: Buffered code: G1 X-55.341 Y-132.442 E.01055 Buffered code: G1 X-15.511 Y143.707 E14.62679 Buffered code: G1 X-15.052 Y143.737 E.02411 Buffered code: G1 X-54.903 Y-132.56 E14.63462 Buffered code: G1 X-54.476 Y-132.754 E.02459 Buffered code: G1 X-14.592 Y143.767 E14.64649 Buffered code: G1 X-14.132 Y143.797 E.02417 Buffered code: G1 X-54.047 Y-132.938 E14.65783 Buffered code: G1 X-53.613 Y-133.088 E.02407 Buffered code: G1 X-13.671 Y143.836 E14.66784 Buffered code: G1 X-13.208 Y143.89 E.02444 Buffered code: G1 X-53.181 Y-133.251 E14.67933 Buffered code: G1 X-52.939 Y-133.352 E.01375 Buffered code: G1 X-52.756 Y-133.46 E.01114 Buffered code: G1 X-12.745 Y143.944 E14.69326 Buffered code: G1 X-12.282 Y143.998 E.02444 Buffered code: G1 X-52.327 Y-133.639 E14.7056 Buffered code: G1 X-52.133 Y-133.707 E.01078 Buffered code: G1 X-51.898 Y-133.827 E.01383 Buffered code: G1 X-11.82 Y144.046 E14.7181 Buffered code: G1 X-11.359 Y144.086 E.02426 Buffered code: G1 X-51.462 Y-133.96 E14.72726 Buffered code: G1 X-51.027 Y-134.101 E.02397 Buffered code: G1 X-10.89 Y144.178 E14.7396 Buffered code: G1 X-10.804 Y144.201 E.00467 Buffered code: G1 X-10.43 Y144.207 E.01961 Buffered code: G1 X-50.599 Y-134.287 E14.751 Buffered code: G1 X-50.417 Y-134.365 E.01038 Buffered code: G1 X-50.164 Y-134.432 E.01372 Buffered code: G1 X-9.974 Y144.215 E14.7591 Buffered code: G1 X-9.517 Y144.223 E.02396 Buffered code: G1 X-49.73 Y-134.576 E14.76715 Buffered codes: 1536 bytes total Code buffer space: 2392 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 46.00, max time between full transfers: 101.6ms, max pin wait times: 58.8ms/18.7ms Codes per second: 37.80 Maximum length of RX/TX data transfers: 7344/2256 Any ideas?
-
@blt3dp if you mean M208 limits are not respected, for Delta kinematics according to the last sentence of https://docs.duet3d.com/User_manual/Reference/Gcodes#m208-set-axis-max-travel only the Z min is followed.
"The M208 minimum Z value applies to deltas. The M208 XY min/max and Z max values don't."M208 XYZ limits are defining a cubic print area, delta has a (roughly) cylindric print area, so it would not make sense. Instead, the arm properties are used for calculation which regions are reachable or not.
(if you're interested in analyzing the firmware source code, those checks are in the LimitPosition function of the kinematics and the check is done before a move is executed).
-
Understood with M208,
But isn't the B value in M665 supposed to be a safe printing limit? From center I would expect either gcode moves or manual moves to not be able to move any farther than that limit. Regardless if the delta radius and arm length physically allow it, if I'm limiting it to less than, it should respect that no?
-
@blt3dp I don't see code beyond 150 in your M122 buffered code.
E.g. X 55, Y 133:
distance is sqrt( x * x + y * y) = 144, so below 150. -
@blt3dp there is something additional: 3D print mode allows partial printing if you want to move outside the limits. It will print to the edge, but should issue a warning. (CNC mode doesn't allow it, cancels the move and issues an error message.) This behaviour may differ between different kinematics, I don't know whether it is true for Delta.
-
True, that particular job took up much of the print bed but not enough to push it past the printable radius. I think my main concern is with manually moving the effector and crashing things hanging off the effector like fans into the belts and towers.
I guess my point would be, say a company wanted to use Duets in their delta printers sold commercially to end users, yet wanted to prevent any scenario like I described above, shouldn’t that be possible?
-
@blt3dp this is IMHO a different question: whether it is possible to block executing "dangerous" commands like G1 H2 or G92, maybe through a user interface which allows only a G-Code subset. This should be answered by someone else than me.
-
@blt3dp said in RRF 3.5 beta 4 not respecting axis limits:
I guess my point would be, say a company wanted to use Duets in their delta printers sold commercially to end users, yet wanted to prevent any scenario like I described above, shouldn’t that be possible?
Normal moves beyond the bed radius (M665 B parameter) will be prevented unless you use M564. G30 probing moves outside the bed radius are permitted because they are sometimes needed for delta calibration.