Lately I print one certain part pretty often. I have a GeckoTek EZ-Stick surface which is great, but they say it lasts arrount 100 up to 300 prints.
Well the part I print is pretty small and when I print it is always on the same spot.
So the surfce there wears out and arround it is like new.
Of course I could slice several files with differtent positions, but I wonder if there is a better way.
Maybe a plugin that automatically changes the starting point in a defined area.
Or a setting in the slicer (I use repetier host with cura engine).
Is there a way to do this.
Unfortunaltey I'm not up to date. The last time I upgraded my Printer firmware is nearly 2 years ago. Unfortunately updating Marlin was always a lot of work. However I think this certain issue, should have nothing to do with the firmware. I could be wrong and there is firmware that is able to do this. Someone will hopefully bring me up to date on that one.
That's an interesting suggestion and a compelling problem, of course.
The work involved to offset X/Y over the entire job seems a bit intense to me for a plugin. If the movement mode is absolute, you're only talking about adjusting every X-value and every Y-value by individual offsets.
Randomly generating these offsets needs to know the usable size of the bed, overall size of the extent of the part itself at its maximum ranges. Making this a general-purpose plugin would be a pain for this reason. Otherwise, you'd end up randomly pushing the part over to the edge and it wouldn't print correctly.
My initial take on this is to do what I normally do, I print lots of them each job. That's twenty parts in one job. In Cura, I just bring in all the parts, calculate their widths and then type in the X/Y offset so that they're precisely placed like this. I'm sure I could now squeeze in many more of those tiles into the same print; this photo was a long time ago.
If you took this approach and then still needed to move everything around, you could type in the offsets manually in Cura and create your several versions to add that "randomness".
And yet, I have been known to write post-processing scripts in the Go language to process an entire gcode file in the way you're describing.
I'd probably look into getting the firmware handle all the offsetting for me. A combination of G28 and then resetting (0,0,0) to something slightly off by a random factor via G92.
Could be done by a very trivial plugin that rewrites G28 into that if enabled.
