Klipper3d / klipper

Klipper is a 3d-printer firmware
GNU General Public License v3.0
9.38k stars 5.29k forks source link

Shutdown due to kill button! (Tevo Flash) #2046

Closed JimKnopfIoT closed 4 years ago

JimKnopfIoT commented 5 years ago

I'm using klipper on my Tevo Flash for 3 weeks now. I often have the error message "Shutdown due to kill button!". I did bed mesh leveling. Z-offset is set and first layers looks perfect. But from time to time, at the beginning of a print job the error occurs and nothing help unless i restart both, the printer and octoprint. From the log i can't find any usable information about the error or a hint what to fix.

klippy-20191006.log

radensb commented 5 years ago

TL;DR: My guess is that you could fix this one of two ways:

  1. Remove the pin definition from your config file - do you need a kill button? If one is not defined, Klipper shouldnt perform that function regardless of what that input is doing.
  2. Defining the pin as active low with an internal pullup: kill_pin = ^!ar64. I think this will match your hardware as it is the most common design using a button.

Given the error and the config you defined in the log file, I am wondering if you didnt defined it properly. You have a pin definition for a kill button: kill_pin = ar64. First, does this button actually exist and wired to a button to ground? If so, is it also wired to an external pullup resistor? Your config is currently defining the pin as an active high input, meaning that the input is TRUE when HIGH. All the hardware I have seen will typically have an active low input with a button going to ground and the signal pulled up (internally or externally) so the input state is always well defined. It looks like that printer uses the MKS GEN controller which is not open source, so I can't pull a schematic. Can you probe the input with a DMM?

What I think may be happening is that you defined the pin in the configuration as the wrong activity level without an internal pullup resistor on hardware that has a button to ground without an external pullup resistor which makes your KILL input floating. If the pin floats and stays below what the input understands as a LOW level, all is well, but if it floats above the transition threshold and is ever detected as a HIGH, it will trigger the KILL function (given your current config). Electrical noise, EMF, etc can cause a floating input to jump around - not a good thing. This condition may also persist - which is why you have to reset everything. I would take a closer look at the hardware configuration of that pin.

Hywelmartin commented 5 years ago

try to add a pullup ^ [display] lcd_type = uc1701 cs_pin = ar25 a0_pin = ar27 encoder_pins = ^!ar31, ^!ar33 click_pin = ^!ar35 kill_pin = ^!ar64

JimKnopfIoT commented 5 years ago

TL;DR: My guess is that you could fix this one of two ways:

1. Remove the pin definition from your config file - do you need a kill button? If one is not defined, Klipper shouldnt perform that function regardless of what that input is doing.

2. Defining the pin as active low with an internal pullup: `kill_pin = ^!ar64`. I think this will match your hardware as it is the most common design using a button.

Given the error and the config you defined in the log file, I am wondering if you didnt defined it properly. You have a pin definition for a kill button: kill_pin = ar64. First, does this button actually exist and wired to a button to ground? If so, is it also wired to an external pullup resistor? Your config is currently defining the pin as an active high input, meaning that the input is TRUE when HIGH. All the hardware I have seen will typically have an active low input with a button going to ground and the signal pulled up (internally or externally) so the input state is always well defined. It looks like that printer uses the MKS GEN controller which is not open source, so I can't pull a schematic. Can you probe the input with a DMM?

What I think may be happening is that you defined the pin in the configuration as the wrong activity level without an internal pullup resistor on hardware that has a button to ground without an external pullup resistor which makes your KILL input floating. If the pin floats and stays below what the input understands as a LOW level, all is well, but if it floats above the transition threshold and is ever detected as a HIGH, it will trigger the KILL function (given your current config). Electrical noise, EMF, etc can cause a floating input to jump around - not a good thing. This condition may also persist - which is why you have to reset everything. I would take a closer look at the hardware configuration of that pin.

I used the default config file for Tevo Flash. Might be the kill_pin ar64 is misconfigured. I removed the kill_pin definition. I will see what happened the next days/prints.

JimKnopfIoT commented 5 years ago

After removing the kill_pin line from the config file i had no error so far. What exactly is the kill_pin? And what does ar64 mean? The Tevo Flash has a MKS Gen L V1.0 Board with MKS MINI12864 V2.0 LCD attached. If ar64 means the Pin Number printed on the PCB, then this is the wrong definition. According to the manual ( https://github.com/makerbase-mks/Datasheet/blob/master/English%20datasheet/MKS%20Gen_L%20DataSheet.pdf ) the Pin D64 on the PCB is in the AUX/Touch Screen Port. The MKS MINI12864 V2.0 LCD has a Reset Button. The Circuit is connected to the EXP2 Port on the MKS Gen L V1.0 PCB. The Reset Button is connected to GND and the RST Pin of the EXP2 Port (between D51/D41).

KevinOConnor commented 4 years ago

The example config files are contributed - if there is a change that should be made to them, feel free to submit a PR with that change, or post the contents of what the config file should look like.

See the FAQ for the definition of ar64 and example-extras.cfg for the definition of the kill_pin.

Thanks, -Kevin

radensb commented 4 years ago

My guess is the kill pin goes to a button which is connected to an input used as an E-stop and the line does not have an external pull-up resistor. Noise is then allowed to influence the signal state and intermittently stimulate the kill pin. Without a schematic for your hardware, one can only guess as to what the proper configuration would look like to have that button properly configured. By removing the pin from the config, you are telling Klipper to ignore that signal.

Looking through the Pins.py file, I do not see any "ar64" pin for any device. Since this marking is on the screen PCB (which is compatible with many, many other boards and devices), you can assume that it is not talking about a specific device pin (unless it was made for a specific board in the case of your printer, but I doubt that...) - since it could map to any pin based on the device on the controller board.

Your board used the MKS Gen L V1.0 which uses a Mega2560. Here is the link to the screen I think you are using (or one compatible with this definition): https://reprap.org/wiki/RepRapDiscount_Smart_Controller#Schematics

The Wiki states: #define KILL_PIN 41 which maps to PG0 on the 2560. Again, this is all difficult without a proper schematic. You could use a DMM to map the signal to the pin to be sure, but if you never use that button, you could leave it undefined without issues.

JimKnopfIoT commented 4 years ago

So far the printer works fine without the kill_pin definition in the config file. Thanks for your help. I will close this issue now.