Successful: Print Queue and Automated Print Cycle

dc42

A macro that is not called from a SD card print can start a print (that's how resurrect.g works). But if the macro is called from a SD card print, it can't start another one, because a print is already in progress.

Phaedrux

@dc42 What if at the end of the print a macro is called which attempts to start another print?

cookie

@dc42 I have developed a lift and push technique, which I've tested is possible to eject 4"x 4" footprint for PLA (possible a lot bigger) using any Prusa style machine with glass heated bed. This is a very important step because it could apply to many inexpensive machines. I will post the details after I thoroughly tested it

Any idea how could I start other gcode files after I cleared my print bed with my custom end.g macro?

E.g. I have a set of files to print, 1.gcode, 2.gcode, 3.gcode, ... and so on.

After finished 1.gcode .. Is there any way I could continue print 2.gcode, then 3.gcode and so on until the end of the list in the folder?

Phaedrux

@cookie What if instead of printing each gcode separately you combine them into a single gcode file? The ejection macro to clear the bed just gets called between each part. The printer executes all the actions in series during a single print session rather than starting and stopping and trying to start a new print each time.

cookie

Just learned that I can't call M32, to select and print another file, at the ending script of a gcode

Using multiple M98 or M32 commands in a macro

@phaedrux seem like that I have to do that at the moment. It is quite a messy way and error-prone way to do it.

I may have up to a hundred of different print queues, 4-5 files for each. Is there any good way to check gcode validity after concanated them before printing?

dc42

@cookie said in Print Queue and Automated Print Cycle:

I may have up to a hundred of different print queues, 4-5 files for each. Is there any good way to check gcode validity after concanated them before printing?

Run simulation on them and check the console for error messages.

BTW I think there may be an indirect way to have one print file start a different print at the end. Instead of using M32 directly, you would use M581 to set up a dummy trigger and M582 to check and execute it immediately. Then put the M32 command in the trigger file.

cookie

@dc42 said in Print Queue and Automated Print Cycle:

BTW I think there may be an indirect way to have one print file start a different print at the end. Instead of using M32 directly, you would use M581 to set up a dummy trigger and M582 to check and execute it immediately. Then put the M32 command in the trigger file.

Thanks, seem like it's works! Now, I've tested that I could do recursive call between a.gcode and b.gcode by:

1.) Create trigger2.g and trigger3.g in "sys" folder.

1.1) Trigger2.g

; Switch off trigger2.g

M581 Z S-1 T2 C0

; Print a.gcode

M32 "0:/gcodes/a.gcode"

M400 ;Wait for current moves to finish

G4 S2 ;Wait 2 Seconds

; Call trigger3.g

M581 Z S0 T3 C0

M582 T3

1.2) Trigger3.g

; Switch off Trigger3.g

M581 Z S-1 T3 C0

; Print b.gcode

M32 "0:/gcodes/b.gcode"

M400 ;Wait for current moves to finish

G4 S2 ;Wait 2 Seconds

; Call Trigger2.g

M581 Z S0 T2 C0

M582 T2

2.) Create a Recursive.g in "macros" folder which called Trigger2.g

M581 Z S0 T2 C0

M582 T2

3.) Run the macro and the machine go in an infinite loop of a.gcode and b.gcode

Now, seem like I can chain many triggers into this loop. I'm testing more to see if it really works with actual printing files or not

Updated: It's really working nicely .. by just call a trigger, which there's a M32 command in it, at the end of gcode. The nice thing is you can change the macro or trigger any time without stop printing.

Finally, I'm really happy that this project to becomes fruitful. It takes me more than a year in gathering info, research, learning, pick the right products and putting everything together.

Of course, Duet is the most important part which realized it!

I will wrap up and update the process after finished testing with PETG.

cookie

How-to Print Queue and Automated Print Cycle

Machine: Prusa-Style machines with heat bed, using Duet Controller is convenient e.g. Prusa MK3, Cetus MK3, MakerGear M2
Bed Surface: Clean Glass using Isopropyl alcohol (I use Ikea LOTS mirror because of the quality and availability)
Filament: Tested working with typical PLA, PETG but should works with any materials which can be print on the glass surface and removed easily.
Model Size: Base 10x10cm (Width x Length) or bigger, Height: 2-3cm shorter than the maximum height of the machine.

The important aspect for the removal process is to lift the model up vertically instead of pushing horizontally. There's some strong force, that I feel like the vacuum, which prevented the model to move if push from the sides even if it was once removed. From my tests, I can only remove small models if push horizontally which also stress the gantry a bit.

Instruction:

Leveling the bed Manually level the bed or using manual/auto mesh bed compensation and make sure you get a good first layer adhesion, while it is not too squished or too high.
Add sprue Add 1mm cylinder in the model to an area that can be cleanly cut or easily broken off when the print finished. It can be added within your slicer software without modifying the original model. The sprue height should be 10-20mm higher so the model doesn't touch the heat block when ejecting. The tip of sprue is the area where the nozzle will be stopped.
Test print We will simulate some ejection steps first. The test model should be around the same footprint of your target model, with at least 1-3 mm thick so it is not flexible. e.g. 15cm x 15cm x 3mm rectangular plate. Test printing your model using the right temperature for heat bed, which doesn't warp your model or make it too sticky to the glass, then wait for the model to cool down after finished printing. Try pulling the model up vertically from the sprue, which should take only a little hand force to do if the first layer height is correct. Pay attention to the waiting time and the temperature that the model can be removed successfully because this is the value that you will be used in your ending script of the print. e.g. printing PLA at 60c heated bed, and the model can be successfully removed when the heat bed go down to 32c (which takes 5 minutes from 40c ... Duet's M190 command monitor the bed only when it is over 40c ).
Create End.g Macro This is the end script which will be called at the end of your model gcode, the essential steps are:

; ###Cool down###
; Wait 120 Seconds for nozzle to cool down to under the Glass Temperature of material e.g. My PLA is 60 Celsius
G4 S120
; Wait for Heated Bed to Cool down to 40 celsius
M190 R40
; Wait 600 Seconds for the heat bed to cool down to 32 celsius e.g. My PLA can be removed easily from the heat bed when it reach 32 celsius
G4 S600
;###Lift up###
;Set relative positioning
G91
;Move Z up 20mm, the nozzle will pull up the model effortlessly
G1 Z+20 F1000
###Drop the model###
;Move X,Y to edge of print bed, choose the suitable X,Y values for your printer
G1 Y-999 X999 F1000
;Heat the extruder to 200 celsius, so the PLA at the nozzle tip melts and the model drops from it around the corner of the heat bed. The model should fall to the table by gravity if placed the sprue at the other corner (Adjusted the location to suited your machine)
M109 S200
;Extruder heater off
M104 S0
###Push the model outside printing area###
; Slowly push the model out of printing area, this should be carefully planned if the model has an irregular shape. It can be easier if you have a mechanical push part on X/Y and set up the printing area to facilitate the ejection process.
G1 Y900 F1000
;Home X/Y/Z
G28 X999 Y999 Z999

Test End.g Macro Test your macro and refined it before use is a good idea. You will actually see how thing works at this time.
Create trigger2.g Go to System directory using System editor in your Duet Web Control and create trigger2.g (2-9 will do) and add this:

; Switch off trigger2.g
M581 Z S-1 T2 C
;Wait for current moves to finish
M400
;Wait 10 Seconds (can be omitted or changes)
G4 S10
; Print a.gcode, this is your xxx.gcode in your SD card to be printed
M32 "0:/gcodes/a.gcode"

Create CallTrigger2.g Macro

; Set up trigger2.g
M581 Z S0 T2 C0
; Execute trigger2.g
M582 T2

Test CallTrigger2.g Macro Test run your macro, it should start printing a.gcode now.
Putting them together Go to your slicer, loaded your model, add sprue, finish settings and put End.g and CallTrigger2.g in the ending script by adding this 2 lines:

; Run end.g macro
M98 P"/macros/End.g"
; Run CallTrigger2.g macro
M98 P"/macros/CallTrigger2.g"

Save the file The file name should be the same as one in CallTrigger2.g, in this example is a.gcode
Print them Congratulation! Now your printer should print a.gcode repeatedly without manual removal process .. with glass-like finishing at the bottom side

You can continuously print only one or many sets of model by using more triggerX.g files e.g. a.gcode call trigger2.g which print b.gcode, b.gcode call trigger3.g which print c.gcode and so on. Named the folder and copy that trigger set to /sys when you want to print them. This way, you could have many print sets with a limited number of triggerX.g.

Also, triggerX.g can be changed, modified without stop printing until the filament run out. You can print set A two times, then set B four times and so on with some planning, a webcam and come back a few times to delete, copy/paste trigger sets in Duet Web Control.

Notes:

The process was simplified, to make it easier to understand.
Now you get the idea, So, you should customize/modify and test your processes e.g. nozzle priming, heat bed temperature, removal, ejection that suitable for your machine before you begin your production run.
I think the process is not restricted to Duet only. With some more researches and knowledges, other controllers and firmwares should be able to do it too.
I'll add more videos, photos and details later on..
I'm curious what is the biggest footprint area that this method works because I don't have big printer. Please post it, if you tried it succesfully with big prints.

Credits:
Sanjay Mortimer, RepRap Auto Printing - Ejection of print and starting of new print.
P&U, 3d printer: auto removing of printed object

dogon1013

Awesome. thanks for this. I have also been wrestling with this issue (using a bed swapping mechanism though) and found another work around that might help some folks.

Simply upload your Gcode files in the macro folder and call them like a macro, from a master gcode file (one that can call the macro as many times as you like). I also put M99 at the end of the macro gcode file, but that was probably not needed.

Only downside of this is the status of the print is not shown like normal (no tracking of what layer you are on, % left, etc), as it thinks you are just running a macro... But the upside is that you can specify easily how many times to print in the master program.

I need to see if there is a way to specify the number of reprints using the trigger method. I am sure there is, but have not figured that out yet.

Toby

dogon1013

Just thought of another way to improve on this. Since the program that is next in the cycle is controlled by Trigger2.g (or whatever trigger number you use), This file should be able to be deleted and re-written with the M30, M28, and M29 commands in a macro.

That is assuming those commands will allow writing to a system file (I have not tested it yet).

This means a macro can be used to set the next program, and also start the first program. so you could have a macro for each production program you want to run....simple 1 click operation, once it is setup.

SCMagi

This post is deleted!

SCMagi

This post is deleted!