G30 G32 end in watchdog reset when z-probe is triggerd
Hi,
I`m very new in 3d printing but now, after a lot of setting issues i enabled nearly all functions with repetier firmware.
In detail:
using configuration tool for version 1.0.3
- Printertyp: sparkcube xxl with radds and raps
- endstops working fine
- z probe is working fine (unenabled = low, enabled = high)
- all axes working ok
- i was able to perform a first g32 (after a lot of trials an setting corrections) with no errors, but the only last proble seems to be the correction direction - it was to the opposite
--> i enabled the "Invert Direction Signal" for both extra motor drivers
(and in the meanwhile a lot of other changes)
but now, when i perform a g32 or just g30:
after z-probe is triggerd, the watchdog starts to
reset.
21:55:31.689 : N23 G30*43
21:55:47.079 : Printer reset detected - initializing
21:55:47.079 : start
21:55:47.079 : Info:Watchdog Reset
what i did to solve the problem:
- changed
the pin for z-probe from z min to y min - idea here was that the pin is buggy
- deaktivated watchdog
- deaktivated eeprom
But now i have no further idea what to do now.
Thank you guys for your response.
Steve
Comments
Also can you confirm that at the beginning watchdog was not triggered.
eeprom can trigger it when writing over I2C doe snot work, but that does not help so activate it again. Check values in eeprom. Of special interest are values with NaN and 0 if they make sense. Wrong values in config can often break function relying on them.
Last question - at which point does the reset happen? Directly, after lowering probe or reaching the bed or going up again?
While it should not make any difference, I'd suggest using Z-MIN to avoid confusion.
Also, these settings do not look right: This page shows where are P1, P2 and P3 points. Try to meet the following conditions:
Z_PROBE_X1 < Z_PROBE_X2
Z_PROBE_X3 = Z_PROBE_X1
Z_PROBE_Y2 = Z_PROBE_Y1
Z_PROBE_Y3 > Z_PROBE_Y1
Thanks
M114 makes no sense, we report position anyway for every probe and that is the only more complicated command before it would move up.
If that does not help you need to find out where exactly the hang happens. To do so go to file BedLeveling.cpp function Printer::runZProbe and add inside and around the for loop commands to write debug messages:
with different names.
Then run after upload and connection
M111 S7
to enable the messages. Host log will show these as each output also has a delay to wait for output. That way you see where it passed and which point never gets reached (ok some if conds are never true so these are also omitted). That allows you to find the line causing the hang and then we can see further.
I do not think it is a hardware defect. More a endless loop that makes it hang due to some conditions you have.
M114 makes no sense, we report position anyway for every probe and that is the only more complicated command before it would move up.
I had time to check that additional "M114" command. With removing of "M114" everything works as exspected!!
So I'm very happy now and can go on with further adjustments.
thank you very much for your support!!
just to now it for future: in which way i can add commands?
M114 maybe is not that sencefull but is also no wrong command!?