Print starting too high Tronxy XY-2 Pro

Get Help
#1

Just wondering if anyone can help me. I’m brand new to 3D printing, I have a Tronxy XY-2 Pro and just set up OctoPrint with a Raspberry Pi 4. The issue is whenever I start a print with octoprint the nozzle start a little bit too high resulting in it not sticking to the bed.

I have tried searching but all I can see is people recommending G codes and M codes and I just don’t have a clue what they all mean :disappointed:

When I slice it and save it to the SD card and load it to my printer it works fine so they issue is definitely something to do with octoprint.

#2

Did you already set the Z-offset in your printers menu?

#3

Yeah, I’ve levelled the bed and set the Z offset. It works fine if I print from the memory card plugged into the printed, the issue is only when I print from Octoprint

#4

Does the printer do anything else different when you print from sd card?

#5

No I don’t think so, it just prints normally.

#6

In that case I guess the bed leveling isn't loaded.
Which slicer do you use?

#7

Cura and the Tronxy one. If I slice them to the memory card and load into printer they work fine. If i slice them and load them to Octoprint, the nozzle is too high.

#8

I don't know the Tronxy slicer but in cura you would add M420 S1 to the start gcode
It could look like this
image
But show me your start gcode first so I know how it looks like

I just looked up your printer on youtube and noticed a weird thing:
When the person in the video selected Z-offset on the printers display the Z axis homed in the front left corner of the bed but then moved to the middle of the bed for the Z-offset setup
That is weird because you obviously would set the Z-offset at the point where it probed the Z home.
If it homes on different place the saved Z-offset could be off.

Does Z home at the same location with octoprint as it does when you print via sd card?

You could test that really quick when you edit/create a gcode file with just G28 in it and "print" it via sd card and then via octoprint.

#9

This is the start G-code if I go into Cura and machine settings:

; XY-2 Start Code
G21
G90
M82
M107 T0
M140 S{material_bed_temperature_layer_0}
M104 S{material_print_temperature_layer_0} T0
M190 S{material_bed_temperature_layer_0}
M109 S{material_print_temperature_layer_0} T0
G28
G92 E0

If I go into OctoPrint and GCode scripts, the start GCode box is empty, shall I try putting that in there?

#10

Anyone any ideas? at the minute I feel like I have wasted £125 on the Pi and webcam to plug in to it :frowning:

#11

When people have ideas, they will come and reply to you.

You're going to have to do some experimentation here, since it's not really something we've seen before.

  • Run G28 X Y, it should home the X and Y axis
  • When you run G28 Z where does the nozzle end up?
  • After, run G1 Z0. If the nozzle is now above the bed, then there is an offset applied.

If the offset is not applied by the printer printing over USB, then that is a firmware bug. You might be able to fix this, but we will cross that bridge when we come to it.

#12

Hi Charlie, thanks for coming back to me. After running G28 Z, the nozzle ended up a couple of mm above the bed. After running G1 Z0, the nozzle was practically touching the bed.2

#13

Ok, I was kind of hoping that that was the problem. In this case, to check it is definitely not OctoPrint you should now enable serial.log and start a print. Then we can review this log here, and we can see if there is anything odd or that shouldn't be there, or something that looks like it might be missing.

It is really confusing me why it would start above the print bed, if G1 Z0 is the bed.

I am suspecting firmware, Tronxy are close to Creality in terms on firmware quality, and that is quite low down. They often don't fully test serial communication vs. SD card handling. Marlin doesn't have an example configuration officially, but you may be able to find something on the internet if we work out it must be a firmware bug.

#14

Thanks Charlie, I have just put the below code into OctoPrint GCode before print and it seems to have helped. I found it on another thread, haven't got a clue what it all means.

G91 ; Set to relative positioning
G28 X0 Y0 Z0 ; Home all three axes
G90 ; Set to absolute positioning
G92 E0 ; Set position (zero out) the extruder

I will activate the log now and start a print and post it here.

1 Like
#15

Just ran the start of a print with the log enabled. I removed the GCode from the before print in OctoPrint and it actually started ok, I think it's just hit and miss. Not sure if it's even something I am doing wrong, with using OctoPrint do I still set the Z Offset on the machine and I don't have to set it somewhere in OctoPrint?

serial (1).log (102.3 KB)

#16

Hmm, the log gives no indication of why it went wrong, the intermittent nature points to bug for me.
The Z offset on the machine should be respected by OctoPrint, there isn't a separate setting within OP for this.

Keep the log enabled, come back when it fails I guess? Be aware that it can get quite large, and impact performance a little.

Also, what was in the before start gcode in OctoPrint before?

#17

Nothing, it was blank before. I will keep it on and see how it goes.

Also, I don't suppose there's a way to get it to hold off extruding a bit longer is there? by the time it starts moving there's normally about a cm worth of material oozing out :frowning:

#18

That's probably gravity, the log shows no extrusion commands until it starts moving. Not a lot you can do about that, that's why there are things like prime lines and skirts, to wipe off this material that you can enable.

#19

I've got them on, was just wondering if there's maybe a command to pull back the filament a little bit to stop gravity doing it's job. I'm just always looking for little ways to improve things lol.

#20

The command to pull back the filament 1mm would be G1 E-1 if the command G92 E0 ; Set position (zero out) the extruder had just been issued or if the extruder is in relative mode.

To get this right, an understanding of the Marlin commands G90, G91, G92, M82, and M83 is necessary as well as determining if/when they are issued by your slicer (i.e. examining the resulting G-code).