I just made all my old gcode files useless

…on purpose.

When I started 3D printing, I followed common practice of printing only in the first quadrant — with the origin at the lower left looking down at the build plate. Some time later, I read advice on Mark Rehorst’s blog suggesting that putting the origin at the center of the build plate would make gcode portable between generally similar printers, and thought it made sense but didn’t want to invalidate all my existing gcode files.

But now I just put a spring steel PEI-surfaced bed on one printer, and after tearing apart my original printer apart for spare parts, I built a new printer from scratch that just started printing today. So I set both printers to have the origin at the center so that gcode will be generally portable between the printers, at least if it’s not running too fast for the slower printer.

I hope I like this. :slight_smile:

I used to have, but lost it over the years, a python gcode post processor someone wrote back in the day. It would do a coordinate transform to adjust it for different XY size beds.

I have too many files, but not the best organization unfortunately.

1 Like

In our FabLab we recommed to always bring and use the STL because each printer (even same model) has some differences and also the slicers get better from time to time, so it doesn’t make sense to store the gcode for longer time.
As we work with a Repetier Server on a Raspberry Pi connected to 3 Prusa i3s, the gcode jobs are stored on the raspi (for each printer) and one could repeat a job from the job history, but we clear the history every month or when anything changes on a printer (mechanical or frimware).

I understand that. But it turns out that almost anything I slice for the cantilever printer should be able to print on the corexy printer as well. Both use the same hotend, both are direct drive, etc. So it could occasionally be a convenience.

At least prusa-slicer, which I primarily use, sends the nozzle all the way across to the opposite side of the bed to start printing the skirt, dragging any goo along with it that would otherwise be purged at the beginning of the skirt near the origin. That’s ugly and I don’t want to do it.

And really, if the bed is really flat, it doesn’t matter if I print at the center, so even without putting the origin at the center I can if I want still use gcode from the flinger on the corexy, which pretty much is a superset of capabilities.

So I’m back to the normal origin, and I deleted my now-useless center-origin gcode files.

Haven’t done any printing for a while. But I also use prusa-slic3r and have a custom start & end gcode routines that I simply replace theirs with, so I always know where it’s going to start and end, if that makes sense. Worked well like that. Any changes to those routines could always be easily made and accommodated in any gcode file without worrying about unexpected results.

Custom start/end gcode doesn’t tell it where to start printing a skirt.

Now that I’ve slept and am a little less foggy, I believe it starts printing the skirt at a point close the origin, which could be anywhere around the bed if the origin is set at the middle, depending on the shape of the skirt. (The rule appears to be something like “the beginning of the first straight edge counter-clockwise from the/a point closest to the origin”, based only on observation of behavior and not on reading code.)

True Michael, but you define your start position and can set a slight pause so you can cleanup the nozzle (with needle nose pliers) before it drags the goo all over the place, I find that beneficial in many cases.

I can define the start position, but my point is that the start position for the skirt is potentially different for every print, so setting a different start position in custom gcode isn’t helpful.

Yes, I keep tweezers to clean goo from ooze. But if the skirt starts at the closest point to the home position, it mostly doesn’t matter, whereas if the skirt is going to start printing in some arbitrary position, it matters a lot that I remove any ooze the instant before it starts moving.

Or, I can (as I did) just give up on this experiment and go back to what has worked well for me. :slight_smile:

1 Like

I tend to only save the STL file and generate new gcode again as needed to reprint something. As someone else mentioned slicers change and get better so for my useage/workflow I’m fine only keeping the STL. Also I only have a one 3d printer, but I can see this could be useful if you had multiple similar printers.

I often tweak slicer settings for a particular print, so saving the gcode often makes sense for me.


What I hate is when a print comes out really good and you forget to save the gcode/settings, and later on you try and print something very similar and you can’t find what settings you used. Nowadays with prusa slicer I just save every single thing out as a project so I can reopen it later delete out the model and add a new model for very similar settings.