Octoprint skipping bed raise and skirt print

Get Help
1

Hello all. I'm still new to the whole 3d printer thing especially the backend process with gcode and how it interacts. I've only had a printer for 1 month, then decided to add octopi to it.

I am confused at what went wrong. My octopi setup is skipping the initial bed raise, sweep, and skirt printing. It seems to load gcode then begins to head up the hotend and bed.

I have reinstalled Octopi, but the issue still remains. The confusion thing the first print I did worked just fine as well as the timelapse. Now it starts printing at the object and not at the beginning of the gcode. At least that's what it looks like to me as I haven't started to dive into the world of gcode and log data.

QIDI X-Maker using the UART header and RPi2 GPIO
Octoprint version: 1.3.12
Octopi version: 0.17.0

20191130_141942
20191130_141942.jpg4032×2268 544 KB

octoprint.log (79.8 KB)
serial.log (211.0 KB)

2

I don't know if your installation instructions included this but whenever your printer is connected with serial over GPIO then you need to make some adjustments to your Raspbian. You'd go into raspi-config to turn off console use of serial, turn on the UART for serial and disable Bluetooth or demote it to the mini-UART. All this—after a reboot—will ensure that serial-over-GPIO uses the good UART on the Pi and doesn't cause serial errors.

You might want to add homing commands to your OctoPrint's Settings -> Gcode scripts for each time a job begins. On mine it's something like G28 XYZ or something like that. And I think I also default the motor movement mode to absolute to make sure that it wasn't left in a weird state from before.

3

That was part of some instructions I looked at, but not all of them. I'll add that to the boot config and check back.

Thanks.

4

Still the same. I would have to learn the basics of GCode before I start adding commands to the beginning of the print.

There is a line in the serial.log file that reads "Recv: //####checkSum error,i:2 expect:0x7e,actual:0x7d!str:N0*125".

5

Yet another case of shit printer firmware, try this

It would be so nice if companies who have no idea of what they are doing stopped fiddling around with their printer's firmwares and/or copying the fiddling results from others. Ffs.

2 Likes
6

The thing it when using the same gcode file octoprint doesn't like it, but when loaded directly onto my printer it works just fine.

7

Yes. Trust me. Shit firmware.

It isn't OctoPrint that doesn't like the file, it is the firmware speaking a weird dialect instead of the commonly agreed upon protocol because someone somewhere decided they needed to mess with stuff they don't understand and ship the result with their printers.

3 Likes
8

That makes things even more confusing as the first print I ran through octoprint actually worked.

9

Just try the two plugins from the link please. I've been doing this for a while.

10

I guess we'll see how this Pi2 likes extra plugins.

13

I really need to work on my forum skill again.

A 3 minute print went fine. I'll run a 3hr print to see how it goes. Thanks. bows in respect

14

Told you so :wink:

15

I guess now I need to manually install a remote access plugin. I'll post an update once the 3hr gets done.

16

Everything seems to be in working order now. Thanks for your help!

2 Likes
17

This solved also my GCode issues with the Tronxy X5SA-400. Once in a while it followed GCode M190 and M109 correct, most of the time it didn´t. Thanks for that post!

1 Like