X axis off center

Evening

I hope someone can help.

I am recently having issues with the built in slicer for astroprint. Its printing off-centre toward the lower end of the X axis. If I pause the print then resume it then tries to print in the correct place. When I originally installed astroprint (Jan 19) this was not the case and the prints came out fine

Why I have tried so far

  • rebuilt astroprint pi - still off center using astroprint
  • reflashed printer firmware - still off centre using astroprint
  • 2 other slicers connected via USB - print is fine
  • astroprint with uploaded x3g from other slicer - print is fine
  • I have tried both ABS and PLA and get the same results

Please correct me if I am wrong but this points to an issue with the slicer for astroprint.

Hardware I am using

  • replicator 1 clone (CTC Dual)
  • raspberry pi zero w (I also have a pi 3b+ and this does the same)
  • connected via USB.

Please can someone let me know if I am doing something wrong?

Sorry for the long post
Richy

Could be that the print area is not set correctly or the bed center option is set incorrectly.

Will check when I get home

I got chance to try. The box was set to 0,0 so I tried it without. I made sure to recreate the print files but it still did the same thing

If that was the case why would it reset to the correct position on pause?

Just a thought.

Does astroprint auto update itself. I notice the version was released on Feb 20th and thats about when this started

The AstroBox does not autoupdate. It shows you when there’s a new update but the user always has to approve it.

Daniel.

Thank you for that. It is driving me crazy that I can’t figure out what is causing this as I have been using astroprint for 6 weeks prior without an issue

It is my understanding the pause sequence in AstroPrint is controlled by the printers firmware directly. When you un-pause your printer itself is putting the X/Y back at the correct position rather than AstroPrint.

AstroPrint Pause Settings

Did anything change in the Start GCODE in the Advanced Printer Settings under the printer profile?

What if you reflash the original AstroPrint image you downloaded to the SD card again and see if the issue stops occurring?

I already rebuilt the raspberry pi and tried a different model. It leads me to believe it’s either astroprint or the printer

The printer works fine when connected to USB and another slicer

Astroprint also works fine if I slice it in another slicer.

That’s what pointed me to the slicer issue. I don’t understand how to read x3g code but happy to upload an example if it helps everyone?

There is nothing in my start guide

It says “;do nothing”

I was going to say that the start/end gcode should have something it in but from other posts about similar issues with this printer, your start gcode looks correct.

Maybe @Daniel has more information on where to look.

I have a FF Creator Pro (Replicator clone) that has been doing the exact same thing. I was told by AstroPrint staff that they did not change anything; however, I have done, like all of you, reset, updated, changed, sliced in other programs, and uploaded from other slicers. The result is the same. All files sliced prior to the “error” remain ok. Only prints sliced after the “error” seem to be offset. It looks to either be affecting these models of printers or printers using this type of firmware. I have not gotten any updates from Daniel since February. This appears to be in conjunction with the integration of the Cura 3.6 slicer. Maybe someone can prove me wrong?

1 Like

Maybe we can be wrong together…

I still haven’t solved it. Actually considering octoprint but I do love astroprint

I originally used Octoprint for a short time when I first got started a year ago. It was nice but it used the AstroPrint plug-in to work with my printer. I thought “Why do I want to use the add-on when I can use the actual app?” So I switched.
It has worked almost flawlessly until this fiasco. I can’t print anything too large these days because of this issue. I like the slicer and the cloud app but this needs to be corrected soon or I am going to have to find another process. I don’t know if Octoprint still requires the AstroPrint plug-in to work with .x3g file types. Let me know what you decide. I’m curious. :stuck_out_tongue_winking_eye:

Hopefully @Daniel can help

I’d be happy for a temporary fix by offsetting the start g-code to the left by whatever the distance is between nozzles. If you or someone knows this information, please post it here. :crossed_fingers:

Walter. Can you try pausing mid print and then unpausing. See if it resets itself to the correct oocation

What if you throw a pause gcode into the Starting GCODE section so it pauses off the bat?

Then put the heat gcode for bed and hot end to ensure it gets up to temp.

Does the gcode process when it’s an x3g firmware?