›

Clearing Soft Errors Without Reset

vanfidelvanfidel
in Repetier-Server
Thank you for your help with the last issue. I thought it makes sense to open a new thread about this for others.

I recently setup an Enraged Rabbit Carrot Feeder (ERCF) running Happy Hare. It seems to work fine with repetier-server after a few tweaks but it sends some messages as warnings in the log file. It also sends errors when it fails to do something but these errors are not fatal and do not require a restart. These show up on the link icon at the top of repetier-server and if you click 'Try to recover' it resets the printer. Is there a way to clear this without resetting? I think the printer will probably still function even with the message but I have not yet tested a print using it. It does still take commands at the console even without clearing the warnings or errors.

It is a little bit problematic because there are some Happy Hare routines that run at startup that send a warning that it is heating the nozzle to 200, when you 'clear' it by clicking 'Try to recover' it resets the printer and you get in an infinite loop. Can I somehow instruct repetier to ignore these or do a soft clear? I put two examples below. After the examples below Repetier goes into an error state although the connection still exists and I can still control everything from the console.

Example1:

Warning: Automatically heating extruder to minimum temp (200.0)
- - TRACE: Running macro: _MMU_ACTION_CHANGED ACTION='Heating' OLD_ACTION='Loading Ext'
Waiting for extruder to reach target temperature (200.0)

Example2:

- DEBUG: Error loading filament - not enough detected at encoder.
MMU [T0] >.. [En] ....... [Ex] .. [Ts] .. [Nz] UNLOADED (@0.0 mm)
MMU [T0] >.. [En] ....... [Ex] .. [Ts] .. [Nz] UNLOADED (@0.0 mm)
- DEBUG: Setting servo to up (filament released) position at angle: 30
- - TRACE: Running macro: _MMU_ACTION_CHANGED ACTION='Idle' OLD_ACTION='Loading'
- - TRACE: Extruder heater will be disabled in 10 minutes 0 seconds
idle_timeout: Timeout set to 72000.00 s
Warning: MMU cannot save toolhead position because toolhead not homed!
Warning: MMU cannot save toolhead position because toolhead not homed!
Warning: MMU cannot lift toolhead because toolhead not homed!
Warning: MMU cannot lift toolhead because toolhead not homed!
- DEBUG: Job State: PRINTING -> PAUSE_LOCKED (MMU State: Encoder: Disabled, Synced: False, Paused temp: 0.0, Resume to state: printing, Position saved: None (z_hop @5.0mm), pause_resume: False, Idle timeout: 72000.00s)
An issue with the MMU has been detected. Print paused
Reason: Load sequence failed: Error picking up filament at gate - not enough movement detected at encoder.
Occured when changing tool: > T0
After fixing the issue, call 'RESUME' to continue printing (MMU_UNLOCK can restore temperature)
After fixing the issue, call 'RESUME' to continue printing (MMU_UNLOCK can restore temperature)
- - TRACE: Running macro: PAUSE
- - TRACE: MMU PAUSE wrapper called
- - TRACE: Running macro: __PAUSE
action:paused




Comments

  • RepetierRepetier
    What firmware are you using?

    If you check in installDir/firmwares there are all firmware descriptions defining when to show this halted info and what to do on recover. For marlin you have e.g.
       <command type="recoverBadCondition">@kill
    M999</command>
    So this kills running print and sends M999 to reset error in firmware. This is good because it should only appear on real errors. So if there are messages triggering it also it is more a warning like the debug outputs it should better not trigger the error state at all. It is triggered by rules like these:
    <response type="halted">^Error:Printer halted</response>
    <response type="halted">^!!</response>
    <response type="halted">^//\s*action:\s*poweroff</response>
    So if you see a rule triggering it that you do not want to trigger add a rule like this:
    <response type="ignore">enqueu?e?(ing)?.*(.*M999\b.*)</response>
    BEFORE the rule triggering as error. Normally first match is taken, except if last="false" is included in attributes, then multiple hits are possible.

    From the output I see nothing that should trigger the error. But knowing the firmware and message shown in error dialog can help here finding the rule wrongly triggered.



  • vanfidelvanfidel
    This is with klipper. It seems to happen with any MMU error, when the printer is powered on and the MMU very often tries to 'fix' itself based on previous states (still tracking that down to disable it). Here is another example:
    Warning: MMU cannot save toolhead position because toolhead not homed!
    Warning: MMU cannot save toolhead position because toolhead not homed!
    Warning: MMU cannot lift toolhead because toolhead not homed!
    Warning: MMU cannot lift toolhead because toolhead not homed!
    - DEBUG: Job State: PRINTING -> PAUSE_LOCKED (MMU State: Encoder: Disabled, Synced: False, Paused temp: 0.0, Resume to state: printing, Position saved: None (z_hop @5.0mm), pause_resume: False, Idle timeout: 72000.00s)
    An issue with the MMU has been detected. Print paused
    Reason: Unload sequence failed: It may be time to get the pliers out! Filament appears to stuck somewhere.
    Occured when changing tool: T1 > T0
    After fixing the issue, call 'RESUME' to continue printing (MMU_UNLOCK can restore temperature)
    After fixing the issue, call 'RESUME' to continue printing (MMU_UNLOCK can restore temperature)
    - - TRACE: Running macro: PAUSE
    - - TRACE: MMU PAUSE wrapper called
    - - TRACE: Running macro: __PAUSE
    action:paused
    - DEBUG: Enabled encoder sensor, force_in_print=True. Status: {'encoder_pos': 0.7, 'detection_length': 7.1, 'min_headroom': 7.1, 'headroom': 12.1, 'desired_headroom': 5.0, 'detection_mode': 2, 'enabled': False, 'flow_rate': 0}


  • vanfidelvanfidel
    Is it a problem that it sends a pause? This is also when it isnt printing anything.
  • RepetierRepetier
    Are these klipper logs or parts of communication log with server? Server only reacts an communication and there all lines start with recv: 
    I ask because here is nothing why server should pause as far as I can see, but is seems a PAUSE macro is called and I see action:pause but on communication log it should be // action:pause and then server would pause print of course. But that is not an error and you can continue as long as heaters are still on. If they go off you should install dev version (installDev in ssh console) to get rid of that bug. Just working on improving klipper support by also using api socket of klipper if available.
  • vanfidelvanfidel
    I see yes that was the klipper log. It looks like what is tripping it in the communication there:
    example1:
    Recv:9:07:14.055: !! An issue with the MMU has been detected. Print paused
    ex2:
    Recv:9:09:35.316: !! Warning: Automatically heating extruder to minimum temp (200.0)

    Is it this rule that is just a general catchall for a '!!' log? :
    <response type="conditionShutdown">^!!</response>

    So for these examples I can write a specific rule in to ignore based on matching the message string?



  • RepetierRepetier
    Yes that is the rule. Directly above is already an exception list
    <response type="conditionIgnoring" last="true">^!! (Move|Must home axis first|Extrude below|Invalid adxl345)</response>
    these prevent the shutdown from happening. At least anything starting with Warning should be added as exception I think. I will also check if I find a better solution since !! is being misused. documentation on reprap.org says !! means host should shutdown printer connection and stop doing anything. But it is not meant that way klipper uses it. Just needs to find out how it signals then a real stop:-)


Sign In or Register to comment.