Repetier with Klipper frequently asking for emergency reset


With the latest versions the support fo Klipper firmware really improved, still there are some issues that make this mix
quite frustrating at times.

Repetier keeps getting into the mode that forces user to run a emergency reset in many occasions where there is no need for it.

Messages like Klipper asking use to home axis first for example make Repetier go into that mode when there is no need.
Ideally it should only happen when there is a severe error from Klipper that asks to do a FIRMWARE_RESTART.

So my question is, is there a way to disable this behavior in Repetier at the moment? Or make it ignore certain messages from Klipper?



  • Most behaviour gets defined by klipper.xml firmware description in installdir/firmware.

    Can you give some examples of communication where that happens?  Then I can fix it also for official release.
  • edited January 2020
    Sure, thanks for checking it.
    One example:
    18:21:14.529: !! Move out of range: 109.000 0.000 250.297 [0.000]  <----------------------
    18:21:14.530: ok
    18:21:26.382: Firmware stopped! You can only send host and shell commands until you hit emergency stop or restart the printer. (9)

    Happens when I'm moving the Z all the way to the top to align it.

  • If you read
    about !! you see it is supposed to happen on earnest errors stopping any further action.

    Now it is a question is does this count as fatal error that should stop a print. Well klipper decided it is - guess because a print outside allowed range will make the print fail. Anyhow, you can disable all fatal errors from being detected be removing this line

    <response type="fatal">^!!</response>

    from klipper.xml in firmware folder of repetier-server. But that means it will also continue if heater fails or anythings else more serious.
    Since it is a regular expression you can modify it to ignore some fatal messages you do not want to stop for. Something like
    ^!!(?! Move)

    to exclude !! followed by Move

    But shouln't you increase z height instead if you need to move there? I mean moving to illegal positions should fail so it makes no sense. But I admit in our firmware they are just ignored. So will add the exception to next release.
  • Sorry for the late reply, never got a notification (or just missed it)

    Klipper sends out the warning but does not halt the printer/control. I could still keep using it.

    In this case is because I use the "prusa method" to level both sides of the Z axis. Moving all the way to the top.
    If I do it twice without homing that happens because max Z height in klipper and repetier differs. (keep forgetting to change it)
    That may be a odd example as I agree it should not exactly happen, the reason I used it is because it was the first case I could recall.

    I give you another that is more simple.
    10:15:02.320: ok
    10:15:07.716: N30 G1 X112.00 F3000
    10:15:07.720: Firmware was halted, trying to reconnect. Eventually running print is stopped.
    10:15:07.720: Firmware stopped! You can only send host and shell commands until you hit emergency stop or restart the printer.
    10:15:07.720: !! Must home axis first: 45.000 0.000 0.045 [0.000]
    10:15:07.720: ok

    I did home to X and Y but not Z and when I tried to move the X it gives that error.
    Again the klipper firmware is not halted or preventing me from doing more commands but Repetier parser decided that was a error.

    I'll try to update the rule to exclude these.
    Thanks again for the superb support!
  • Good example of another warning that should not request a stop of communication. For next update I updated rule to
        <response type="fatal">^!!(?! (Move|Must home axis first))</response>

    to include that case as well. If you find more cases, let me know and I put them in exception list.
Sign In or Register to comment.