If one were to set up the printer so it prints an object and then knocks it off the printer once the hotend cools down, and cycles again endlessly, what would the gcode look like?
The entire list of consecutive jobs. Your end gcode should cool down the heated bed, run the knocker-over.
Then the start gcode of the next print heats it back up.
you can’t repeat endlessly in the limited g-code most printers understand. Without loops or recursion into subroutines or jumps that’s not possible.
Don’t know if smoothie supports it, but you should be able to call a gcode file from within a gcode file. Probably doesn’t return to where it left off after finishing (I know it doesn’t in Marlin), but it should allow you to run a file in a loop by putting a line at the end that tells it to start that file again. You may also be able to do it by resetting a byte offset.
@Whosa_whatsis That’s pretty clever. Maybe have 2 files and have each file call the other file?
That rather depends on whether that is implemented as a reload or an import. If the reference to another file is taken as “import this file and replace this command with its contents” then an import loop would just either hit a recursion limit or blow the stack.
‘Call’ appears to be unsupported. ‘Goto’ isn’t mentioned and ‘loop’ shows as unsupported. http://reprap.org/wiki/G-code#M98:_Call_Macro.2FSubprogram
bash / python script + printcore?
https://github.com/kliment/Printrun has a command line interface, I suspect you could just write some sort of bash script to tell python to run the command to print a gcode file over and over, or do it directly through python somehow by importing printcore (don’t quote me on that, been a while since I messed with printrun’s command line thing)
I can’t speak for smoothie but auto0.g starts a print so maybe at the end of auto0.g call it up again?
You would need quite a lot of force to knock some prints off. Unless you use a roller platform I don’t see that as viable
I use auto0.g often but never could get it straight in my head how auto1.g and auto2.g are intended to be used. Maybe this is the use case. Anyone use a series like this?
@Griffin_Paquette It’s a bracelet.
I should also mention we use smoothie
You could use auto0.g, auto1.g, etc (it would run them sequentially, though if there’s no auto2.g, for example, it won’t continue to auto3.g), but it would only get you 10 files (0-9).
Of course, if you’re willing to hit the reset button each time one finishes, you only need auto0.g (this is how I do all of my printing). If you’re rigging a mechanism to remove prints automatically, I suppose it could also hit the reset button when it’s done…
Of course, as @Steve_M mentioned, creating a loop on a computer hooked up to the printer would be trivial, though it seems like a waste.
@Shai_Schechter Look here: http://smoothieware.org/player
Looks like you can start a new file (or restart the same file) by specifying it with an M32 at the end. Easiest way to see if that actually works is to try it.
For some bracelettes, a mold may be better. If you do want to print, the gcode sender may be more capable of doing the loop than the gcode itself.
@Whosa_whatsis I have a raspberry pi running my printer so that’s why I mentioned it.
Not a huge programming guy but I bet you could write a python script to run through the gcode once it sends a certain command. You could add a line to the end gcode that the computer recognizes to restart the program.
He could probably also set the print job to print a number of bracelettes in the same session. They could be done one at a time even if desired and the gapping is large enough so that the head does not hit a bracelette that it already finished.
Hmmm…if gcode is made for one at a time, checking the gcode for instruction to move to a Z of zero would reveal a good place gcode to pop the print off of the bed. Reminder: do not leave prints unattended