Geeetech A10M motion runout sensor & display

I have had my A10M running on Klipper for a while now and in general it is running fine but I have a two of issues for which I have not yet been able to find a solution.

  1. If I enable even one of the two filament motion sensors then as soon as printing is about to start the head drives to x-max, ymax and sits there. It gets though the slicer startup code where I set the temps, do a mesh, prep the extruder but as soon as printing should start it hides the hotend in the far corner. I have a klippy.log if anyone is interested.

  2. Less pressing, in that I can live without this, is that the hd44780 display appears to be configured correctly according to the schematic but just show lines of blocks. It works fine with Marlin.

I have Klipper & Mainsail running on a pi4 and they are current as I apply any update that comes along for them in the hope that it will solve either of this issues.

Thanks for any suggestions.

Sounds to me like your filament sensor is triggering; if so, your log will show something like

Filament Sensor btt_sfs: runout event detected, Time 12778.63

Unless you have runout_gcode set, Klipper will just pause, and you really won’t have any idea what happened. I speak from experience. :grinning:

Here’s what I use, which puts a message on the display, and also sends a message to the console:

runout_gcode:
    RESPOND TYPE=error MSG="filament runout!"
    M117 filament runout!

I’m afraid I can’t help with your display issue.

Ya, I see the runout in the klippy.log right when it goes to print before any attempt to put any material on the bed. It seems to ignore anything in the runout_gcode other than to print the M118 message I put there (M117 doesn’t show :wink: and just drive the head hard to the stops at x-max,y-max (back right corner).

It has been an experience and I appreciate your time to comment but I think for just stable dependability I’m going to blow this all away and go back to Marlin and Octoprint as I don’t see any way to diagnose either problem.

Thanks again.

In case anyone is keen, I have been reluctant to move back to Marlin/Octoprint. I have managed to get this working more reliably by implementing the M412 in a macro. In the Cura start/end gcode for the print and for extruder change I turn off the sensor and turn it back on when starting to print. When I turn the sensor off I turn all of them off (multi-extruder with a smart sensor on each) then only turn on the sensor for the active extruder. This seems to have stopped the spurious events.

It’d be interesting to see the log when this happens…

Hi blalor, when what happens?

When this :point_up: happens.

debug_klippy.log (949.0 KB)
Hi Blalor, found it on the pi.
I’ve changed the config since then and combined with some start gcode I don’t see the issue any longer. Still have not figured out how to get the display working though. Took it back to Marlin and the display works fine, now back with Klipper the display is useless so I am thinking that I need a touch screen for the pi as I want to move the printer a floor away from the computers.

You may have changed this since, but your filament_motion_sensor configs are inconsistent:

[filament_motion_sensor Runout0]
detection_length = 10.0
extruder = extruder
switch_pin = ^PK4
pause_on_runout = Yes

[filament_motion_sensor Runout1]
detection_length = 10.0
extruder = extruder1
switch_pin = PK5
pause_on_runout = Yes

Runout0 is using the internal pullup, Runout1 is not. Without seeing a schematic for your board and where peripherals are attached, it’s hard to say what else might be the issue. If there are no other components on the input pins used for the runout sensors (such as a pull-up or pull-down), you’ll need to configure an appropriate internal one. Otherwise the pin is probably floating and giving spurious readings.

Yes, it is different now. I tried adding the pull-up to see if it was needed (not needed in Marlin BTW) The current config does not use it as the smart sensors actively drive the signal. I am avoiding the issue by turning off the sensors when T0 or T1 is selected and only turning the appropriate one on before the part printing starts after the extruder purge in the gcode.