Clearing Soft Errors Without Reset

Comments

• Repetier

  October 2023

  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.
  
  
  
  
• vanfidel

  October 2023

  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}
  
  

  
  
• vanfidel

  October 2023

  Is it a problem that it sends a pause? This is also when it isnt printing anything.
  
• Repetier

  October 2023

  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.
• vanfidel

  October 2023

  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?
  

  
  
  
  
• Repetier

  October 2023

  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:-)