[BUG] Printer halted while printing

[phantom-333]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

The printer stopped while printing at a random time with the message "Error:Printer halted. kill() called!". Sometimes the print ends up being fine. The problem is relevant when printing from a TFT screen and when printing from a PC using the Pronterface program. In Debug communications mode, when the command "M111 S247" is sent, the last output before the error:

_SENT: N28001 G1 X119.730 Y126.466 E4.3275*82
RECV: ok
SENT: N28002 G1 X119.802 Y126.227 E4.3336*90
RECV: ok
SENT: N28003 G1 X119.985 Y125.731 E4.3464*84
RECV:  T:220.00 /0.00 B:60.00 /0.00 @:0 B@:0
RECV: echo:busy: processing
RECV: Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!
RECV: //action:poweroff_

Width activated UBL:

_SENT: N8284 G92 E0.0000*95
RECV: echo:N8284 G92 E0.0000*95
RECV: X:133.82 Y:143.06 Z:12.80 E:0.00 Count A:21781 B:-681 Z:20567
RECV: ok
SENT: N8285 G1 E-2.5000 F2400*46
RECV:  T:220.00 /220.00 B:60.00 /60.00 @:60 B@:19
RECV: echo:N8285 G1 E-2.5000 F2400*46
RECV: ok
SENT: N8286 M900 K0*69
RECV: echo:N8286 M900 K0*69
RECV:  raw get_z_correction(133.31,146.11) = 0.058378 >>>---> 0.058378
RECV:   current_position= X133.31 Y146.11 Z12.80 : sync_plan_position
RECV:  raw get_z_correction(133.31,146.11) = 0.058378 >>>---> 0.058378
RECV: echo:busy: processing
RECV: Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!
RECV: //action:poweroff_

I tried to check in the config to disable THERMAL_PROTECTION_HOTENDS and THERMAL_PROTECTION_BED - the problem also appears. Maybe the problem started when I activated UBL. But at the last print, I tried not to use this functionality (I disabled it via "G29 D") - the error still occurred.

Bug Timeline

This a new bug

Expected behavior

Normal printing without stopping

Actual behavior

Error:Printer halted. kill() called!

Steps to Reproduce

1. start printing width any G-code
2. wait
3. if the print was successful, then run it again with the same G-code
4. printing stops with an error "Printer halted. kill() called!"

Version of Marlin Firmware

Marlin bugfix-2.0.x (Apr 27 2021 23:21:36)

Printer model

B&R

Electronics

Bigtreetech GTR v1.0

Add-ons

BTT TFT35 V3.0, BTT SmartFilamentSensor, BLTouch

Your Slicer

Simplify3D

Host Software

Pronterface

Additional information & file uploads

Files: Configuration.zip

[billyd60]

I thought I fixed this problem on my printer but it still happens at random in the same way as yours. Mine is a different mainboard (archim2) and I am using a BTT TFT70 v3. It is definitely related to the serial port based on your experience and mine. I am printing in marlin mode without issue. Hopefully someone with big brains will chase this down soon. Since it happens in pronterface as well that rules out problems with the screen fw imo,

[rhapsodyv]

Can you try Marlin 2.0.7.2?

[thinkyhead]

…Or you can also try Marlin bugfix-2.0.x from some point in time just before #20783 — which was merged on January 28.

[billyd60]

…Or you can also try Marlin bugfix-2.0.x from some point in time just before #20783 — which was merged on January 28.

I will but it will be a few days because mine is a custom build so I have to go line by line to set it up. Kind of tedious. Can't get to it right now. Maybe the OP can do it quicker.

ps My custom printer is new from second week in April so I've never been on anything earlier (bugfix branch) than that with this printer. Right now I am on bugfix from 4/24/21. Works better than a few week earlier but still has the issue described here.

[thinkyhead]

There was a missing "ok" in the "Resend:" output, which is now patched. Please download bugfix-2.0.x and give it another shot with a challenging print — maybe in "dry run" mode to save on filament.

[phantom-333]

There was a missing "ok" in the "Resend:" output, which is now patched. Please download bugfix-2.0.x and give it another shot with a challenging print — maybe in "dry run" mode to save on filament.

I am currently setting up the latest up-to-date bugfix-2.0. x, as soon as I switch to the new firmware, I will try a test print and write the result here.

[billyd60]

There was a missing "ok" in the "Resend:" output, which is now patched. Please download bugfix-2.0.x and give it another shot with a challenging print — maybe in "dry run" mode to save on filament.

Thank you for your efforts!

[phantom-333]

I updated the software, but the problem remained current, printing halted with the last message:

_SENT: N33760 G1 X117.908 Y138.436 F6000*69
RECV: echo:N33760 G1 X117.908 Y138.436 F6000*69
RECV: ok
SENT: N33761 G1 Z11.200 F420*30
RECV: echo:N33761 G1 Z11.200 F420*30
RECV: ok
SENT: N33762 G1 E0.0000 F1800*63
RECV:  T:225.59 /0.00 B:70.00 /0.00 @:0 B@:0
RECV:   current_position= X133.59 Y154.77 Z11.20 : sync_plan_position
RECV: Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!
RECV: //action:poweroff_

[rhapsodyv]

Can you share this gcode? (Zip and attach)

[phantom-333]

Yes, of course, it was a 3DBenchy. 3DBenchy.zip

[phantom-333]

I tried to do an experiment now - I disabled #define AUTO_BED_LEVELING_UBL and started printing the 3DBenchy, the first time printing was completely successful, but the second time I ran the same gcode, this problem occurred again:

_SENT: N39535 G92 E0.0000*96
RECV: X:115.90 Y:147.72 Z:12.80 E:0.00 Count A:19580 B:-2396 Z:20480
RECV: ok
SENT: N39536 G1 X115.900 Y138.282 E0.3766 F3360*50
RECV: ok
SENT: N39537 G1 X107.457 Y138.282 E0.7136*88
RECV:  T:225.23 /0.00 B:69.97 /0.00 @:0 B@:0
RECV: echo:busy: processing
RECV: Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!
RECV: //action:poweroff_

[billyd60]

I see there is another recent issue listed here that has exposed some more problems with serial in the latest versions (since 2.0.7.2). So instead of upgrading or even downgrading (which again I have to do manually line by line) I am going to hold tight on the version I'm on and continue to print via marlin mode (non serial comms printing which works great) until you guys sort it out. I don't have enough knowledge in regards to debugging to be of much help anyway. About all I can do is say "hey it's not working" lol. Again I really appreciate the hard work you programmers do on Marlin.

[thinkyhead]

Another recent issue here turned out to be a grounding problem.

@billyd60 — If you continue to experience problems you should fill out a full Bug Report. It will ask you to provide all the relevant information including your Configurations, and then we would follow up with additional testing to isolate your specific issue in a dedicated thread. If your issue happens to be the same as someone else's issue, we would make that determination based on further testing. We have seen too many occasions where users piggyback completely unrelated issues onto others because of similar symptoms, and then it turns out to just be bad wiring.

[billyd60]

Another recent issue here turned out to be a grounding problem.

@billyd60 — If you continue to experience problems you should fill out a full Bug Report. It will ask you to provide all the relevant information including your Configurations, and then we would follow up with additional testing to isolate your specific issue in a dedicated thread. If your issue happens to be the same as someone else's issue, we would make that determination based on further testing. We have seen too many occasions where users piggyback completely unrelated issues onto others because of similar symptoms, and then it turns out to just be bad wiring.

Will do. I don't think my wiring is the issue, I'm fairly knowledgeable in that regard. I have just about the best shielded cable you can get for my serial connection and the shield is well grounded on one end. Also I have tested the serial connection with the ribbon cables disconnected, as well as testing the setup with the power on the serial line disconnected, instead powering the touchscreen from an external regulator powered by battery. So emi is very unlikely to be the cause. I've even tried three different serial cables.

It is quite difficult to get detailed information on a custom marlin build. You can't ask setup questions here, and the reprap forums are essentially deserted of people that can give good answers to difficult questions. Not to mention if you are building something custom, then no one but the programmers will likely know the answer anyway. So I really have no source for info outside of random youtube vids that may or may not have the info I need sprinkled in within the other 45 minutes of shilling and blather. So all of the minutia of settings in the serial section (and other settings elsewhere in the config files) are not fully explained (and even possibly ever changing version to version) and of course I can make educated guesses about them, but how would I know if my assumptions are correct or not? The other problem is the issue I am having is random, and so that makes it even tougher to trace. Heck I could have a hardware issue for all I know. It's a bottomless sea of details and no map. So I walk around bumping into sharp objects in the dark, and perhaps eventually I will find the exit. The good news is the printer is flawless in marlin 12864 emulation from my touchscreen so that is my workaround. The touchscreen is cool, but I can print without it, although it makes me a little sad that I can't get it working well. But I am proud I have a working custom build marlin printer, for me, no small feat. I am a mechanical engineer but don't code and have enough electronics knowledge to be at least not dangerous.

I will end with a suggestion. Provide a means for users to ask about settings questions of the programmers right here. I know it's a giant pain in the butt, but so is building a custom marlin printer without up to date information (and I understand why that's not possible). So we're even in that regard.

[phantom-333]

I figured out the reasons for my problem. It really turned out to be a small bug that causes halted printing at random times. The problem is not related to auto-leveling UBL or serial port. To find the problem, I placed additional information line outputs to the serial port in the code before all calling kill(). The marker worked in this place:

void PrintJobRecovery::_outage() {
    ...
    SERIAL_ERROR_MSG("POWER KILL"); //for test
    kill(GET_TEXT(MSG_OUTAGE_RECOVERY));
}

Output strings when triggered in print: RECV: T:224.96 /0.00 B:69.98 /0.00 @:0 B@:0 RECV: echo:busy: processing RECV: Error:POWER KILL [ERROR] Error:POWER KILL RECV: Error:Printer halted. kill() called! [ERROR] Error:Printer halted. kill() called! RECV: //action:poweroff

I have a MiniUPS installed in my printer, and I did not assume that it could cause such problems. To begin with, I checked the hardware - all the wires were connected correctly and reliably, the MiniUPS also worked normally and give a signal when the power was lost, the pin number and configuration in Marlin were spelled out correctly. Then I assumed that with intensive printing, there may be pulsed short voltage dips, which sometimes coincide with the time of reading the signal. The multimeter did not show any voltage deviations, most likely it did not have time to read it and I do not have an oscilloscope. Then I found a place in the Marlin code where it reads the signal and saw that there is no protection against noise:

#if PIN_EXISTS(POWER_LOSS)
   static inline void outage() {
      if (enabled && READ(POWER_LOSS_PIN) == POWER_LOSS_STATE)
         _outage();
    }
#endif

All I had to do was fix the code in powerloss.h to fix the problem.

#define OUTAGE_NOISE_THRESHOLD  2;

#if PIN_EXISTS(POWER_LOSS)
   static inline void outage() {
      if (enabled && READ(POWER_LOSS_PIN) == POWER_LOSS_STATE) {        
         uint8_t outage_poll_count = OUTAGE_NOISE_THRESHOLD;
         while (--outage_poll_count && READ(POWER_LOSS_PIN) == POWER_LOSS_STATE) safe_delay(1);
         if (!outage_poll_count) _outage();
      }
   }
#endif

I had already done 6 test runs of printing, so far there were no crashes. I'm probably not the only one who has such a problem when using MiniUPS, can you tweak the Marlin code to help other users? I apologize if I wrote incomprehensibly, as English is not my native language.

powerloss.zip

[thisiskeithb]

All I had to do was fix the code in powerloss.h to fix the problem.

Since you've provided a fix, it'd be faster if you submitted a Pull Request so it can be reviewed.

[phantom-333]

All I had to do was fix the code in powerloss.h to fix the problem.

Since you've provided a fix, it'd be faster if you submitted a Pull Request so it can be reviewed.

Okay, I'll try it.

[billyd60]

Perhaps there are other portions of code where no noise tolerance is in place. I don't have a miniups nor do I have anything with power loss or autopower defined. But perhaps other devices may produce noise that are not provided enough tolerance in the code to prevent a halt?

[thinkyhead]

I've added some extra logging to the kill function in bugfix-2.0.x so please give that a test. This will give us extra context to know where the kill is coming from.

[thinkyhead]

Oops, I just posted that comment because it was sitting here un-posted. But, I see you've found your issue.

We do have de-bounce for buttons, endstops, and filament sensors. It sounds like we'll need to watch out for false signals from power-detect circuits as well.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.