Print head moves extremely slowly during the start of printing


#1

Starting about a month or so ago, my print head started moving really slowly to get into position. I thought this had something to do with my printer so I used to jogging feature to move the X, Y, and Z positions and they had no issues with speed. There was nothing stuck.

I thought it might be my start code but I haven't changed it in years. Finally, I tried putting the gcode onto my SD card and printed from the printer directly and it works fine. I am slicing everything in Simplify3D and my start gcode is below.

Only when I print through Octoprint do I have this issue. I have never let it get to the point where the printer is preheated and starts printing because it's agony watching it trying to get to the home position, so I cancel the print.

Does anyone have any insight into what might be causing this?

Printer: QIDI Tech, Replicator clone
OctoPrint Version 1.3.10
OctoPi Version 0.13.0, running on Raspberry Pi 3 Model B Rev 1.2

; **** Replicator 2X start.gcode ****M73 P0 ; Enable build progress
G162 X Y F3000 ; Home XY maximum
G161 Z F1200 ; Home Z minimum
G92 Z-5 ; Set Z to -5
G1 Z0 ; Move Z to 0
G161 Z F100 ; Home Z slowly
M132 X Y Z A B ; Recall home offsets
M135 T1 ; Load left extruder offsets
G1 X-110 Y-75 Z30 F9000 ; Move to wait position off table
G130 X20 Y20 Z20 A20 B20 ; Lower stepper Vrefs while heating
M126 S[fan_speed_pwm] ; Set fan speed
M140 S[bed0_temperature] T0 ; Heat buildplate
M134 T0 ; Stabilize bed temperature
M104 S[extruder1_temperature] T1 ; Heat left extruder
M133 T1 ; Stabilize left extruder temperature
G130 X127 Y127 Z40 A127 B127 ; Default stepper Vrefs
G92 A0 B0 ; Zero extruders
M135 T1 ; Load left extruder offsets
G1 X-100 Y-65 F9000 ; Move to front left corner of bed
G1 Z0.3 F6000 ; Move down to purge
G1 X90 Y-65 E24 F2000 ; Extrude a line of filament across the front edge of the bed
G1 X100 Y-65 F180 ; Wait for ooze
G1 X110 Y-65 F5000 ; Fast wipe
G1 Z1 F100 ; Lift
G92 A0 B0 ; zero extruders
M73 P1 ;@body (notify GPX body has started)

; **** end of start.gcode ****

#2

That's really slow.

Put all of your Fnn values at, say, F2000 or F3000. See what happens.

Or remove the custom gcode so you are using the exact same stuff as when on the SD card.


#3

Hi, that bit of movement for Home Z is supposed to be slow, I assume, since it's labeled that way. It doesn't matter if I boost it to F3000, the issue is all homing movements through Octoprint have suddenly slowed down. I am using identical gcode and thus identical start code for both printing through Octoprint and the SD card. I get the model, slice it with Simplify3D and copy the same output gcode to Octoprint and the SD card. The latter prints at normal speed and the former sounds like someone is holding onto the head and preventing it from moving.


#4

What are the sliders on Octoprint's 'control' tab set to?


#5

Hi, the sliders on the Control tab are set as:

Feed Rate - 100%
Flow Rate - 100%
10 - button under X/Y


#6

in the Terminal tab, try experimenting with moves like this and see if any/al/none move at a decent speed:

G28 W F1000
G1 X80 Y80 F1000

G28 W F3000
G1 X80 Y80 F5000

G28 W F5000
G1 X80 Y80 F5000

G28 W F7000
G1 X80 Y80 F7000

#7

Hi, thanks I will try that tonight.

I actually realized something that might change the troubleshooting. My printer requires x3g code to run not gcode. So when I am testing on the machine's SD card, I am using x3g. Simplify 3D produces both gcode and x3g for output and Octoprint only accepts gcode. I am using a plugin to translate the gcode to x3g on the fly and this has worked for years but recently a new update of Octoprint has caused it to cease working properly. I don't believe this is a plugin issue since the plugin's code hasn't changed since 2016. Is anyone else using the GPX plugin?

@markwal have you seen any issues recently with the GPX plugin? Everything was working fine for me for years and now Octoprint is unusable for me.


#8

I just printed something using the GPX plugin and the latest Octoprint maintenance branch. Worked fine.

One of the differences between printing with Octoprint rather than from the LCD menu is the current speed is retained from the last print. Your first moves after homing don't specify a speed so it will go as fast as the last move from before the print. You can resolve by specifying appropriate speeds on the moves.

It may also be that your machine spec got modified at some point to have the wrong max speed (machine settings under GPX plugin settings).


#9

Thanks for chiming in. I wonder why the move speeds are not specified by the code Simplify3D produces. I am a novice at gcode, do you think you could give me an example of some additions I could make to specify speeds?

Doesn't the F9000 here indicate the speed? Or should I be modifying something else? I uninstalled the plugin and reinstalled it and used the steps on your github to setup the machine type. I will double check the max speed under machine settings per your advice.


#10

That's the speed (F). I was commenting on your start gcode though not the generated moves. The other thing that occurs to me is that if the plugin ever thinks one of the axes is unknown to it, it has to issue a slow unaccelerated move. Your start gcode could zero all the axes to avoid this problem.

That G92 Z0 would work better if it were G92 X0 Y0 Z0 A0 B0