Strange behavior during probing in 3.3 (solved in 3.4b3)
-
@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.
