Strange behavior during probing in 3.3 (solved in 3.4b3)
-
Hi everyone!
So I have a weird issue. I am building a Voron 2.4 and am using a 6hc with 3hc. I've gotten almost everything setup, however, I am in the process of tweaking the settings and getting all the functions working. The issue I have right now is related to probing.
I've uploaded my config and a short video showing the issue.
When I run either a G29 or G32, the printer will move to the probe points. If there is an aspect of any Y movement the Z axis drops during the move. On the other hand if you move only in the X axis the Z axis does not move.
In my other duet machines, the Z axis stays static in all moves until it starts probing.
The problem this causes is that the back left and front right probes (when running a G32) it can cause the probe to trigger early and really throw off the bed level.
I am running the most recent release (3.3) and am running in SBC mode.
Here's the link to the video: https://www.icloud.com/iclouddrive/0hABiLt7oH3CqvWcKUuhXzlHQ#IMG_0258
The current config:
voron.config.g
voron.bed.gAs a side note, I can move with a G1 command and everything works fine. It's only when probing.
Usually the team that scores the most points wins the game.
-
Possibly, in your bed.g, this line
G30 P3 X345 Y25 S4 Z-99999should be
G30 P3 X345 Y25 Z-99999 S4Not too sure how picky RRF is about parameter placement.
P.
RailCore II - Duet Mini + 1LC, Voron V0.1 - Duet Mini
Voron 2.4 disassembled..... Waiting for the RailCore Mini.... -
I've re-posted your files using the </> tag.
; Configuration file for Duet 3 (firmware version 3.3) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool v3.3.1 on Sun Aug 29 2021 21:00:02 GMT-0500 (Central Daylight Time) ; General preferences G90 ; send absolute coordinates... M83 ; ...but relative extruder moves M550 P"Duet 3" ; set printer name M669 K1 ; select CoreXY mode ;M669 K0 ; Drives M569 P1.1 S0 ; A M569 P1.2 S0 ; B M569 P1.0 S1 ; Extruder M569 P0.0 S1 ; Z0 M569 P0.1 S1 ; Z1 M569 P0.2 S0 ; Z2 M569 P0.3 S0 ; Z3 M584 X1.2 Y1.1 Z0.0:0.1:0.2:0.3 E1.0 ; set drive mapping M671 X-60:-60:400:400 Y-60:400:400:-60 S5 ; bed leveling coordinates M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation M92 X160.00 Y160.00 Z800.00 E415.00 ; set steps per mm M566 X900.00 Y900.00 Z120.00 E60.00 ; set maximum instantaneous speed changes (mm/min) M203 X60000.00 Y60000.00 Z2000.00 E180.00 ; set maximum speeds (mm/min) M201 X2800.00 Y2800.00 Z250.00 E20.00 ; set accelerations (mm/s^2) M906 X1800 Y1800 Z1800 E500 I30 ; set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X350 Y350 Z350 S0 ; set axis maxima ; Endstops M574 X2 S1 P"!io8.in" ; configure active-high endstop for high end on X via pin io8.in M574 Y2 S1 P"!io6.in" ; configure active-high endstop for high end on Y via pin io6.in M574 Z1 S2 ; configure Z-probe endstop for low end on Z ; Z-Probe M558 P8 C"io3.in" H30 F1000 T20000 ; set Z probe type to unmodulated and the dive height + speeds G31 P500 X0 Y25 Z0 ; set Z probe trigger value, offset and trigger height M557 X25:345 Y25:345 P4 ; define mesh grid ; Heaters M308 S0 P"1.temp0" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 0 as thermistor on pin temp2 M950 H0 C"1.out0" T0 ; create bed heater output on 1.out0 and map it to sensor 0 M307 H0 B0 S1.00 ; disable bang-bang mode for the bed heater and set PWM limit M140 H0 ; map heated bed to heater 0 M143 H0 S120 ; set temperature limit for heater 0 to 120C M308 S1 P"temp0" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 1 as thermistor on pin temp0 M950 H1 C"out1" T1 ; create nozzle heater output on out1 and map it to sensor 1 M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit M143 H1 S280 ; set temperature limit for heater 1 to 280C ;M308 S2 P"temp1" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 2 as thermistor on pin temp1 M308 S2 P"temp1" Y"thermistor" T10000 B3940 A"Chamber Temp" ;M950 H2 C"!1.out2" T2 ; create chamber heater output on !1.out2 and map it to sensor 2 ;M307 H2 B0 S1.00 ; disable bang-bang mode for the chamber heater and set PWM limit ;M141 H2 ; map chamber to heater 2 ;M143 H2 S280 ; set temperature limit for heater 2 to 280C ; Fans M950 F0 C"out7" Q500 ; create fan 0 on pin out7 and set its frequency M106 P0 S0 H-1 ; set fan 0 value. Thermostatic control is turned off M950 F1 C"out8" Q500 ; create fan 1 on pin out8 and set its frequency M106 P1 S0.5 H1 T45 ; set fan 1 value. Thermostatic control is turned on ; Tools M563 P0 D0 H1 F0 ; define tool 0 G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C ; Custom settings are not defined ; Miscellaneous M501 ; load saved parameters from non-volatile memory T0 ; select first tool; bed.g ; called to perform automatic bed compensation via G32 ; ; generated by RepRapFirmware Configuration Tool v3.3.1 on Sun Aug 29 2021 21:00:02 GMT-0500 (Central Daylight Time) M561 ; clear any bed transform G30 P0 X25 Y25 Z-99999 G30 P1 X25 Y350 Z-99999 G30 P2 X345 Y350 Z-99999 G30 P3 X345 Y25 S4 Z-99999 ;G29 ; probe the bed and enable compensation -
@th0mpy
I'm sure it's an issue between 6HC and 3HC boards. Either, they don't run on the same firmware or there is a timing issue related to CAN-bus. -
@paulhew I tried that and no change, The thing to keep in mind is that it also shows this behavior during a mesh probe too so the bed.g file wouldn't matter.
-
@o_lampe I double and triple checked the firmware on both. It's updated, and I tried forcing the update as well.
How would I determine if there's a timing issue? If there is one, what would I do to correct it?
-
I ran a G32 and ran M122 and M122 B1. It doesn't seem there's a timing issue:
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: 08DJM-956L2-G43S8-6J9FA-3S86N-1B36F Used output buffers: 3 of 40 (13 max) === RTOS === Static ram: 150904 Dynamic ram: 62060 of which 204 recycled Never used RAM 141024, free system stack 150 words Tasks: SBC(ready,7.3%,328) HEAT(delaying,0.0%,325) Move(notifyWait,0.0%,265) CanReceiv(notifyWait,0.0%,799) CanSender(notifyWait,0.0%,362) CanClock(delaying,0.0%,339) TMC(notifyWait,7.8%,59) MAIN(running,84.6%,922) IDLE(ready,0.2%,29), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:09:01 ago, cause: power up Last software reset at 2021-09-01 23:20, reason: MemoryProtectionFault iaccViol, GCodes spinning, available RAM 138212, slot 1 Software reset code 0x4163 HFSR 0x00000000 CFSR 0x00000001 ICSR 0x00400804 BFAR 0x00000000 SP 0x2041b188 Task MAIN Freestk 1665 ok Stack: 2042b348 2042b2f0 00000000 00450e65 00000000 00450e75 fffffffe 210f0000 00000000 0000000a 00000000 2042b7f0 20419728 2042dbe4 00000000 00000001 00000000 0047a1d7 2042dbe4 fffc0000 003fffff 0047a51f 00000000 0047a6f7 20429710 ffffffff 2042b348 Error status: 0x00 Step timer max interval 127 MCU temperature: min 39.9, current 40.2, max 40.4 Supply voltage: min 24.6, current 24.8, max 24.8, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0 Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Driver 0: position 55200, standstill, reads 49529, writes 3 timeouts 0, SG min/max 0/310 Driver 1: position 55200, standstill, reads 49529, writes 3 timeouts 0, SG min/max 0/264 Driver 2: position 24000, standstill, reads 49529, writes 3 timeouts 0, SG min/max 0/253 Driver 3: position 0, standstill, reads 49530, writes 3 timeouts 0, SG min/max 0/301 Driver 4: position 0, standstill, reads 49533, writes 0 timeouts 0, SG min/max not available Driver 5: position 0, standstill, reads 49533, writes 0 timeouts 0, SG min/max not available Date/time: 2021-09-02 07:48:41 Slowest loop: 165.42ms; fastest: 0.04ms === Storage === Free file entries: 10 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, maxWait 516238ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 23, completed moves 23, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 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, chamberHeaters = -1 -1 -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by null HTTP* is doing "M122" 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 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 Code queue is empty. === CAN === Messages queued 535, received 453, lost 0, longest wait 1ms for reply type 6013, peak Tx sync delay 164, free buffers 49 (min 46), ts 280/280/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === State: 4, failed transfers: 1, checksum errors: 0 Last transfer: 2ms ago RX/TX seq numbers: 18472/18472 SPI underruns 0, overruns 0 Disconnects: 0, timeouts: 0, IAP RAM available 0x2c810 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.3.0 Code buffer space: 4096 Configured SPI speed: 8000000Hz Full transfers per second: 36.15, max wait times: 9.9ms/0.0ms Codes per second: 0.84 Maximum length of RX/TX data transfers: 3292/824M122 B1 Diagnostics for board 1: Duet EXP3HC firmware version 3.3 (2021-06-15 16:12:41) Bootloader ID: not available Never used RAM 158872, free system stack 4373 words Tasks: Move(notifyWait,0.0%,125) HEAT(delaying,0.0%,104) CanAsync(notifyWait,0.0%,69) CanRecv(notifyWait,0.0%,80) CanClock(notifyWait,0.0%,71) TMC(notifyWait,7.2%,29) MAIN(running,91.4%,338) IDLE(ready,0.0%,39) AIN(delaying,1.3%,263), total 100.0% Last reset 00:10:08 ago, cause: power up Last software reset data not available Driver 0: position 0, 415.0 steps/mm, standstill, reads 61454, writes 16 timeouts 0, SG min/max 0/0, steps req 0 done 0 Driver 1: position -1600, 160.0 steps/mm, standstill, reads 61452, writes 19 timeouts 0, SG min/max 0/237, steps req 329600 done 216085 Driver 2: position 225600, 160.0 steps/mm, standstill, reads 61453, writes 19 timeouts 0, SG min/max 0/247, steps req 548800 done 323370 Moves scheduled 10, completed 10, in progress 0, hiccups 0, step errors 0, maxPrep 43, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0 Peak sync jitter 0/15, peak Rx sync delay 181, resyncs 0/0, no step interrupt scheduled VIN: 25.0V, V12: 12.2V MCU temperature: min 19.1C, current 28.6C, max 28.6C Ticks since heat task active 173, ADC conversions started 608960, completed 608960, timed out 0, errs 0 Last sensors broadcast 0x00000001 found 1 178 ticks ago, loop time 0 CAN messages queued 4741, send timeouts 0, received 5446, lost 0, free buffers 37, min 37, error reg 110000 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 414, adv 36852/37076 -
That is rather strange. Can you try adding M400 between your G30 commands in bed.g and see if that makes a difference?
-
@phaedrux Unfortunately that made no difference. Still drops Z in the during Y moves.
One interesting thing... If I put an R0.5 in the M558 command it does not move Z until .5 seconds after it started moving. If I up that to R1 it completes the Y move then probes (it takes just about a second to move from point to point). This tells me that when it's traveling along the Y axis it's also trying to probe Z. Not sure why in the X axis it doesn't do this.
-
So, I just changed the axis maximums to 300 and the bed.g to a 300 on the Y axis as well. That fixed it. I don't know why, and I'm attempting to play with it to see what exactly happened. I'll report back if I can determine what is going wrong.
-
Ok so I think it's an issue with the probe offset. The maximum being 350, the probe could not hit that. The maximum should be 375 and the bed.g should be 350. If I'm figuring this correctly. IMHO could the 3hc be throwing an error that we don't see, which could cause the movement to be complete?
-
Would you be able to test this in standalone mode?
https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Running_in_standalone_mode
-
@phaedrux I will see if I can tonight.
-
@phaedrux Using the exact same config file in standalone mode. It behaves the same. Side note I was able to fix it on a G32 but not a G29. It may not be an issue because it does not have as far to go, but I feel it could still give false readings. I'll keep playing.
-
While you're in standalone mode would you be able to test 3.4 beta 3 as well? Simply because it would be easiest to go back and forth while in standalone mode.
https://github.com/Duet3D/RepRapFirmware/releases/tag/3.4.0beta3
-
@phaedrux Ok yeah, that took care of it. All is working! Does that mean you know what the issue is?
UPDATE: I hooked it back up to the Pi and updated to the unstable branch. We're still looking good!
-
Glad that's fixed it. Please keep up with the 3.4 releases as they come on the way to the final release just to confirm that it stays fixed.
