Crash on heating Hotend just moves x 200mm then

Get Help
1

Printer heats the BED, then trys to heats HOTEND, stays frozen at 0 degree target temperature and moves X Axis just 200mm

Changing the Serialparameters, increased the timeout settings, Upgrading and Downgrading from 1.3.12 to 1.4.0, complete clean install of Octopi 1.3.12 without anything

I then get these error messages: Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N22 M105*23)

Octopi 0.17 without anything, with Marlin 2.0 on a SKR 1.3 Board)

2020-03-26 21_25_59-OctoPrint
2020-03-26 21_25_59-OctoPrint631×592 40.5 KB

I already printed with this setup 3 Days ago. The only thing i changed, was to install the hue gcode plugin, but it seems to work fine.
I first removed this plugin and hope that solves the problem, but did not fixed it.

I'm using Octoscreen and after boot of the Raspberry and Showing the Octoscreen Touchinterface i can heatup the hotend without issues and i also can heat up the bed without issue.
I have a start script, that will start bed leveling, after connecting to the printer. Thats working fine too. So hard should not be the problem in my opinion.

But i really have absolutly no idea where i should investigate at. I already changed the cable to an older one, i used with my previous printer. but its exactly the same error.

The only way is to shut everything hard off.

Would be really happy if someone had an idea where to start from.

octoprint.log (61.5 KB) serial.log (148 Bytes)

Communication logging:
serial_communication.log (56.7 KB)

2

Hello @dexter11!

Could you please share the logs?

3

Thank you for your fast reply!

Added the octoprint.log and the serial.log let me know if you need any more information.

4

Thanks for the logs. You may have to enable the serial logging.

Could it be that you just pull the plug of the RasPi instead of shutting down? That can cause problems with the data structures on the SD card.

You also may check if the hotend heating cartridge is properly connected to the printer board and all other connectors too.

5

There is no other way to shut the raspberry down :frowning: it should not be the solution.

The hotend is fine, i can heat it up using my touchscreen with octoscreen on it.
i also can heat up the hotend via octoprint webinterface. there seems to be no hardware issue.

6

I added a serial log with communiction logging, in the start post.

7 
2020-03-27 07:06:41,179 - Send: N8 M117 Heize auf ...*11
2020-03-27 07:06:41,179 - Recv: ok
2020-03-27 07:06:41,181 - Send: N9 M109*34
2020-03-27 07:06:41,182 - Recv: ok

That M117 there is a blatant lie, that single M109 is doing exactly nothing, least of all heating up. It's lacking temperature.

2020-03-27 07:06:41,188 - Send: N11 M117 Drucke :)*41

Get rid of : there, some firmwares react with buggy behaviour to that.

2020-03-27 07:06:41,195 - Send: N12 M73 P0 R509*42
2020-03-27 07:06:41,197 - Recv: echo:Unknown command: "M73 P0 R509"
2020-03-27 07:06:41,197 - Recv: ok
2020-03-27 07:06:41,199 - Send: N13 M73 Q0 S556*33
2020-03-27 07:06:41,200 - Recv: echo:Unknown command: "M73 Q0 S556"

Your firmware can't make heads nor tails of M73, get rid of that.

2020-03-27 07:15:30,350 - Send: N21 M104 S225*83
2020-03-27 07:15:31,569 - Recv:  T:24.09 /0.00 B:69.63 /70.00 @:0 B@:127
2020-03-27 07:15:41,570 - Recv:  T:24.19 /0.00 B:70.12 /70.00 @:0 B@:127

This is OctoPrint sending a non blocking heatup command to your printer and your printer ignoring it. That's a firmware issue. Try if the same behaviour happens with a blocking heatup command (the M109 from earlier, but with a temperature value). If so you have some kind of firmware issue on your hands, that's nothing that OctoPrint can fix.

I also don't see a movement command in the vicinity of that, so if you head starts moving, something's really broken.

8

Gina thank you a lot for taking the time to answer me.
I really going to investigate in the Firmware and the GCommands i'm using for startup and printpreparation.

But what gets me total crazy is, that it was working 4 days before even with octoprint 1.4.0. And i no issue like that before.

Now i'm going to get the lastest marlin 2.0 version set it up and check it out!

9

Make sure that the printer itself is plugged into power and the switch is ON. The Pi can power the printer enough so that it thinks that it's on but just wouldn't heat up.

Check all connections in the printer like the thermistor and the hotend power and those on the print bed.

10

The pi and the printer are complete powered on their own.
Everything is working like expected when im using the Webinterface of Octoprint.
I can move every axis, i can heat up the bed and the hotend without problems.

I now updated to the 3 day old marlin 2.0.5.2 release and still have the same issue :frowning:

11

and i removed every M117 line and the M109 command from the start and the connect gcode.

i just got this at connecting:

G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
G28 ;homeing
G29 ;autobedleveling
G1 X0 Y0
G1 Z35

and this before start the print:

G1 X0 Y0
G1 Z35
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
G92 E0 ;zero the extruded length

But i still get this messages:

echo:Unknown command: "M73 Q0 S556"

But what can i do to enable marlin 2 to get use of it?

And what seems a bit strange to me, usually when octoprint connects to the printer, the board of the printer resets, stops heating and starts with the start script.
Now i can disconnect and reconnect and the printer is still heating up the bed!?

12

I got rid of the M73 Unknown Commands, was just an option in PrusaSlicer for the Progress.

Everytime right after he sends the M104 Command to heat up the hotend he saiys timeout:

Send: N14 M104 S225*85
[...]
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

i switched to the raspberry pi2 i used before, powered it with another 2.1A powersupply and used another USB Cable, and still running in the same error.

And if i set the heatbed temperature for the filament to 0 in my slicer and start printing he is heating up the hotend without problems, but then i got the same issue.

13

You checked the connections to the thermistor and the hotend(s), right?

In the Terminal tab, just manually run commands to see if things work.

M104 S170
# Here, I would hold up a piece of loose filament near the nozzle to see if it tries to melt
# Also, watch for the reported temperature to rise in response to this

Here's what your firmware is trying to tell you about the hotend:

Recv:  T:24.09 /0.00 B:69.63 /70.00 @:0 B@:127
#      ^ actual ^ target

Immediately after issuing either an M104 (nonblocking) or M109 (blocking), the next temperature report should change that target value. That's a bare minimum. You expect the firmware to accept the command to do something.

Next, you expect that actual reported temperature to start increasing. If that doesn't happen then something is really wrong: no power to heat things up, bad connection, bad thermistor, incorrect configuration settings in your firmware.

14

As i wrote above, the hotend is working fine.
I can heat it up using the webinterface and if i set the bedtemperature to 0 in the slicer, the printer heats up the hotend and then runs into the same issue.

15

Here's what I can see:

  • Your Pi either isn't connected to the Internet or it can't do DNS name resolution. So a variety of things are failing on each restart.
  • Your octoprint log has a number of these errors: Communication timeout while printing, trying to trigger response from printer. So your firmware is being unresponsive at times when OctoPrint sends it some unknown command.
  • I see no logging for under-voltage so that's good
  • You're running on a Raspberry Pi 4B. If it were me, I'd make sure that the serial cable is plugged into one of the USB v2 connectors to be on the safe side of things. I note that the 4B is compatible with 5Ghz wifi zones.
  • I note an SD init fail message. You might consider just removing that from the printer controller board.
  • You might want to add some shims to your print bed to get things closer to level.
  • It looks like you're homing the XY and going to Z35 twice
  • You're setting absolute mode twice in both movement and extrusion
  • You're turning off the hotend on startup
  • You've got several M73's which your firmware doesn't like
  • Not sure what you're trying to accomplish with M205 S0 T0 but it sounds like it disables minimum printing speed for the first hotend
  • Your bed seemed to take a long time to heat up, for what it's worth
  • After this apparently succeeds, you throw a nonblocking heatup command for the first hotend to 255C and things fall apart:
2020-03-27 07:15:30,350 - Send: N21 M104 S225*83
2020-03-27 07:15:31,569 - Recv:  T:24.09 /0.00 B:69.63 /70.00 @:0 B@:127

Note that the target temperature for the first hotend didn't change to /255.00 there. If it were me, I would try to manually heat the hotend to 170C and see if the temperature responses accept that temperature and heat it up. Is it possible that your Marlin thinks that 255 is too high?

16

I really appreciate your effort and your help, but I have already written a lot of information about what I have done, which you seem not to have read

The pi have got internet and i already used a pi 2 with the same result

yeah thats the issue its running to, when heated up the bed and it should heat up the hotend

and i used a pi2 already with a complete different power supply

i changed the usb port and also the cable and also the whole raspberry

its just a left over from a display with sd card which was connected a long time ago

why shims? it is not printing, there is no leveling issue or something like that

yeah at the start before leveleing the bed, and right before every print, thats fine

yeah maybe, but its not nessassary but it wont run into any errors, it think

nope, i also removed the start gcodes and it changes nothing. and it was running like this for years

its an option from prusaslicer which i already disabled,

has to be some firmeware or slicer related, is no option i set, but doesnt sounds like it will change anything

here i also thing its just okay as it is, faster heatup wont change my problem

as you can see, it tries to reach 225 not 255 degrees and thast absolutly fine, because i can heat up it manually

as you can see, it tries to reach 225 not 255 degrees and thast absolutly fine, because i can heat up it manually

I already wrote almost anything of this in my comments above.

17

The point here isn't 225 versus 255, it's that you set a target and the firmware didn't accept that. If neither your 4B nor 2 can do name resolution then it's worth troubleshooting if you have anything else that relies upon this.

18

I found the issue, but it was absolutly nothing you recommended in my configuration.
The printer did exactly what it should.

19

Can you share the fix so that others later might benefit from it? Thanks.

20

wisdom_of_the_ancients

^ please avoid this

3 Likes