Marlin: Prints take forever to start/don't start (echo:busy: processing)

[pbrgle1]

I am using dual x carriage and since the RC5 update my prints (mostly) don't start and the terminal in octoprint keeps outputting:

Recv: echo:busy: processing
Recv:  T:240.7 /240.0 B:93.4 /95.0 T0:240.7 /240.0 T1:237.9 /240.0 B@:127 @:29 @0:29 @1:127 W:?
Recv:  T:240.5 /240.0 B:93.4 /95.0 T0:240.5 /240.0 T1:237.9 /240.0 B@:127 @:40 @0:40 @1:127 W:?
Recv:  T:240.4 /240.0 B:93.4 /95.0 T0:240.4 /240.0 T1:238.3 /240.0 B@:127 @:48 @0:48 @1:127 W:?
Recv:  T:239.9 /240.0 B:93.4 /95.0 T0:239.9 /240.0 T1:238.6 /240.0 B@:127 @:72 @0:72 @1:121 W:?
Recv: echo:busy: processing

Even if i cancel the print, the heaters don't turn off and the whole thing in the terminal continues. This is not specific to octoprint because i tried direct USB also. The only option to get out of this loop is a reset.

[jbrazio]

@pbrgle1 from the log it seems that you hot bed is not reaching the target temperature of 95C, could you try to set the bed temperature to 90C and see if the problem still persists ?

[thinkyhead]

It may also help to do a new run of M303 on the bed.

[pbrgle1]

I think the bed temperature is not the problem. When i start the print the temperature is stable at 95C and as far as i know the bed temp only gets checked at the beginning of the print. I noticed that my extruder temperature has to be below the target temp when i start the print to even get the print started. Before i used to preheat to about 240C and then start the print. That's when the loop happened. If i preheat to say 220C it will heat up normally and then start the print (but it still takes a lot longer than before).

[jbrazio]

This description is a bit different from the initial, so the issue is not cold starting the print but hot starting.

Are you using the latest configuration files ? Can you show us the section related with nozzle and THERMAL_PROTECTION_BED_HYSTERESIS ? Thanks

[pbrgle1]

I'm not using thermal protection because it creates other problems. It probably has something to do with dual x carriage. (mostly the extruder) temperatures get stuck and the whole thing shuts down if i leave it enabled.

[jbrazio]

do a new run of M303 on the bed
could you try to set the bed temperature to 90C

@pbrgle1 we've asked you to do a couple of tests and provide a config file, none of them you replied "exactly" to, if you want our help you got to start answering the questions [and doing the tests] we ask, thanks.

I think the bed temperature is not the problem
B:93.4 /95.0
T1:238.3 /240.0

:unamused:

Your PIDs seems to be a little low, or not enough juice on your power supply or we have a bug. :sweat:

[pbrgle1]

Sorry i forgot to mention that yes, i tried setting the temp to 90 and it didn't solve anything. Ill try to autotune again but i had no problems with the current values in the previous RC. The problem only seems to appear when the extruders are preheated over/or really close to the target temp.

[jbrazio]

Just to clarify when you speak about RC5 are you using the RCBugFix branch ?

[pbrgle1]

Yes i believe so. I downloaded the zip 4 days ago.

[thinkyhead]

[pratap3369]

echo:busy:processing
same problem here
i tried every firmware rc4,rc5,rc6,bugfix but no use
somebody please help me

[paulusjacobus]

Your nozzle and or heated bed are not stable enough to reach and maintain their temperature. Eliminate the cause by trying to print just with the hot end so no heated bed. Try to tune the hot end with the M303 C8 190 command and see if it improves. In the config.h file you can set the method of heating the bed as well (pid or "bang bang"). You can store the pid settings in eeprom if you have enabled eeprom. Best is to tell us your set up so we know a bit more.

Usually you see these issues when there is some buildup of molten plastic on the top of hot end.

Sent from my iPad

On 25 Apr 2016, at 7:19 PM, pratap3369 [email protected] wrote:

echo:busy:processing
same problem here
i tried every firmware rc4,rc5,rc6,bugfix but no use
somebody please help me

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[turboproc]

Just one other element to check: which Arduino IDE version did you use? I had similar behaviour when using an old version.

[thinkyhead]

If your hardware or PID tuning is being flaky, then try relaxing the THERMAL_PROTECTION_BED_HYSTERESIS and/or TEMP_BED_RESIDENCY options so it will succeed as long as you're within a few degrees of the target. With the bed it matters less. The TEMP_BED_RESIDENCY options are new with RCBugFix (and upcoming RC7).

Be sure to compile with Arduino 1.6.7 or newer.

[Blue-Marlin]

@pratap3369

echo:busy:processing

is not an error but a now wanted output. If you feel disturbed by it please activate DISABLE_HOST_KEEPALIVE in your Configuration.h

[thinkyhead]

M113 S0 will also disable those busy messages, and you can save that to EEPROM. Hosts will enable it if they need it. At least, Repetier, OctoPrint, and Cura should be updated to do this soon.

[jbrazio]

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.

[eduozzy]

Hi Everyone! I'm having a similar (but different problem, I presume) that I'm not being able to solve. A little description:
When I start printing, the heat bed starts to reach the set point. When it gets to the correct value, the printer simply stays in that state without advancing to the next step (start heating the nozzle) for a couple of minutes and then advances to the nozzle heating.
In parallel, Pronterface is continuously showing the message: "echo:busy: processing" for the whole printing process. I don't know if this is related to this problem, but at the same time is annoying.

I'm using Marlin 1.1.7
Core XY printer
Arduino Mega + Ramps 1.4

If you guys need more info, please ask.

[revilor]

What is your g code to wait for bed temperature? M190 R or M190 S ? And did you PID tune the bed?

And by the way: you can disable the busy messages, just comment HOST_KEEPALIVE_FEATURE or BUSY_WHILE_HEATING in Configuration.h. Or use M113 S0.

[eduozzy]

Hello revilor,

I didn't PID tuned the bed. For the g code I believe is the M190 S (I'm using slic3r 1.2.9). Here follows the beginning of the code generated for one of the parts:

; generated by Slic3r 1.2.9 on 2018-01-13 at 23:14:27

; external perimeters extrusion width = 0.30mm
; perimeters extrusion width = 0.48mm
; infill extrusion width = 0.48mm
; solid infill extrusion width = 0.16mm
; top infill extrusion width = 0.16mm

M107
M190 S105 ; set bed temperature
M104 S230 ; set temperature
G28 ; home all axes
G1 Z5 F5000 ; lift nozzle

M109 S230 ; wait for temperature to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
G1 E-1.50000 F2700.00000
... and so on...

BTW, thanks for the tip to disable the busy messages. I thought it was a problem with the printer.

[revilor]

I for sure would run a PID autotune for the bed then. The temperature curves from the start of the print are not in your screenshot but I suppose there is an overshoot when heating up and then it takes forever while the printer is waiting for the bed to cool down again towards the target temperature. If PID tuning does do the trick you could also try to reduce MAX_BED_POWER (in case my theory regarding the overshoot in the beginning is right).

[eduozzy]

I'll run the autotune as soon as I get home for sure.
I'm not near the printer right now but I can assure you that is not having
a overshoot. Actually, the temperature takes a long time to reach the
target (almost a 1st order system). My bed is supplied with 12V (360W power
supply). I'll take a screenshot of the temperature when is close to the
target for you to see.

Eduozzy

On Tue, Jan 16, 2018 at 9:52 PM, revilor [e-mail] wrote:

I for sure would run a PID autotune for the bed then. The temperature
curves from the start of the print are not in your screenshot but I suppose
there is an overshoot when heating up and then it takes forever while the
printer is waiting for the bed to cool down again towards the target
temperature. If PID tuning does do the trick you could also try to reduce
MAX_BED_POWER (in case my theory regarding the overshoot in the beginning
is right).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3585#issuecomment-358147146,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AhxOlEfR0A42RRO-oiRPd0QBZh4nHPuOks5tLTZJgaJpZM4IM-VF
.

[eduozzy]

Hi,
I finally was able to connect to the printer again!
So basically I could tune the extruder heater but not the BED specifically (some error messages as shown below).
Anyway, the bed temperature is not overshooting, as seen at the picture below (I`m using a 12V at the bed and my power supply is 360W). The bed temperature takes about 9min to reach the target (105C). Once it reaches it takes 1-2 minutes to start the extruder.

>>> M303 E-1 C8 S90
SENDING:M303 E-1 C8 S90
PID Autotune start
Error:Heating failed, system stopped! Heater_ID: bed
[ERROR] Error:Heating failed, system stopped! Heater_ID: bed
Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!

heating tgt

[AnHardt]

Please don't be that laude. My child is sleeping.

Already fixed in the 'bugfix-1.1.x' branch.

[eduozzy]

Hahah,

Sorry, I didnt see that out loud coming! But I dont know how that happened.

Thanks for the update!

[AnHardt]

https://guides.github.com/features/mastering-markdown/

Just be careful with the '#'

[hitchcme]

I just had the same problem. I'm using firmware retraction, and just found the Swap retract Velocity set to Zero, and stepper moving extremely slow, after waiting for print to finally start, and a tool change. Waiting for filament to travel 13mm @ 0 (IAW the LCD, I'm sure it's some tiny decimal) mm/S will take a long time.

M209 S0; Disable Autoretract
M208 S${DISTANCE} W${SWAP_DISTANCE} F${SPEED} R${SWAP_SPEED} ; Set Retract Recovery values

I think my problem is fixed!

[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.

[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.