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


#11

My Flashforge Pro is doing the exact same thing, the first time I noticed, I set a print going and when I came back it was printing in midair. I assume it tried to home the Z but timed out and just started, I know I just pressed print and assumed it was working, bad form. On cancelling it crashed into the base, it obviously thought it was at the correct Z and dove to + 160 or whatever the max z is. I think I managed to print once from Octoprint by homing manually on the printer first but the last time didnt work you can hear and just about see the z axis moving back from the stop. I can still print fine from sd card and I have checked the homing code in the gcode from Simply3D and it looks the same, just Octo is moving at microturns instead of its normal fast up to home switch then down and back up slowly.


#12

Were you ever able to resolve this?


#13

Hi everyone, Octoprint works again! First, thanks to Mark because I think your advice about it printing at the same speed as the last print, really helped it. I am not sure how it got into a state where the last print speed was "slow". Here's what I did:

First, I updated my G92 Z0 gcode to include your suggestions on all the axis. Next, I tried tedder42's suggestion of entering moves into the Terminal tab. Sadly, only the first one (G28 W F1000) resulted in any movement. The rest did nothing although they didn't produce any errors at all. It seems like the machine accepted the commands but didn't do anything I could see.

I also restored my machine definition to default (which changed nothing). And now, I am printing and it seems to be working fine! Yay!

Update: Print the next day and it's slow again. I think I have to preface each print with a manual terminal command like "G28 W F1000" to get it in "fast mode". This is so weird and unnecessary.


#14

I'm waiting on a new fan before I can test again, but I had a similar experience, if I manually homed the axis from the printer controls it worked. However this doesn't seem to work every time. Did you by any chance install the plugin to allow you to skip parts of the print if it fails? That is the only thing I can think that changed before this started. I have uninstalled it but waiting on fan to test.


#15

Ok just tried it and if anything it's worse, If I just power on the printer and connect octo to it, if I press the home XY button it slams the print head into the front left corner and tries to press it through the steel plate. If I manually home it first and then load a file and press print it makes a click then seems to start winding one of the axis at about 1 thousandth of a degree a second. This is really annoying. I wish I remembered when it started, not sure if a octo change or a simplify3D. I have compared old and new Gcode and prety much the same. It did use to start from the front right on left and right extruder prints but now starts from the left on left prints but it worked doing that through Octo fine for a while.