Macro to assist with using object cancellation
-
If that is the case, would it be possible to add support for pre-labeling the objects in the header/comment area of the Gcode file? That way, you could start a print and cancel an object right away even if that object had not been "encountered" yet by the gcode interpreter.
-
@dc42 said in Macro to assist with using object cancellation:
Were you printing that file when you ran the macro? Object names are only added to the list as the machine starts printing them.
At the time I ran the macro and the M409 I'm pretty certain that at least 1 layer of all four objects had been printed. However, its a quick print so I'll try again just to double check...
@bot said in Macro to assist with using object cancellation:
If that is the case, would it be possible to add support for pre-labeling the objects in the header/comment area of the Gcode file? That way, you could start a print and cancel an object right away even if that object had not been "encountered" yet by the gcode interpreter.
Assuming that objects just get added to the object list as/when they are first encountered, this should be easy to do with a post process. What would be neat is if running a simulation (or post-print) could then prepend this to the g-code file.
edit: I've just checked and yes, I get the same results as above even after n>0 layers of all parts have been printed.
-
Thanks. It sounds to me that DCS isn't yet passing the comments on to RRF.
-
@dc42 said in Macro to assist with using object cancellation:
Thanks. It sounds to me that DCS isn't yet passing the comments on to RRF.
One for @chrishamm, I guess then.
To get around this issue, I post-processed the file to replace PrusaSlicer's labels with M486 commands and can now see them fine in the OM
However, the macro still has an issue as I get the following error when I run it:
I've made sure that all the lines are inset correctly and I've also found that if I insert an extra
echo iterations
on line 6 then that line works but subsequent ones fail and terminate the macro
If I then comment the last 3 lines, but leave my addition, I see the expected output in the console, so the issue seems to be when "iterations" is used as an argument.Is this perhaps another issue with the way DCS is passing the comments?
-
I found that if you pass M291 using anything but the S3 parameter, or use M117, then you get that error about iterations being called while not being in a loop.
This is my code which works.
Cura calls all supports "NON MESH" so I haven't worked out how to post process to identify what support goes with what object yetif !{state.status="processing"} M291 P"Not printing" R"Error" S1 T7 abort "Not printing" if {job.layer<2} M291 P"Not all objects may be detected yet. Continue?" R"Warning" S3 G4 S0.5 if {(#job.build.objects=null) || (#job.build.objects=0)} M291 P"No objects detected. Check slicer or wait till end of first layer" R"Error" S2 ;abort "No objects" ;if {(job.build.currentObject=null) || (job.build.currentObject=-1)} ; M291 P"Current print move is not a print object" R"Not a print object" S2 ; abort "not a print object" echo #job.build.objects while iterations < #job.build.objects if job.build.objects[ iterations ].cancelled echo "Obect " ^ iterations ^ already cancelled continue M291 P{(job.build.objects[iterations].name)} R"Delete?" S3 ;M486 P{iterations} G4 S1 echo "Finished"
-
-
@ChrisP said in Macro to assist with using object cancellation:
@OwenD
Interesting. What's your Duet setup? For now I was just starting with @dc42's macro as I assumed it should work for at least whatever setups he has. Have you tried this one & did it work for you?Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-RC11 (2020-04-30b3)
Duet WiFi Server Version: 1.23
Duet Web Control 2.1.6I have run it and it works.
I'm just running a test with supports (sliced in Cura)
I'm not sure if I can identify the supports and as they'll be outside the X,Y of the object it might fail.
Will report back shortly -
As I suspected, in Cura at least the supports aren't identified as objects by RRF
That will require some post processing to get working (or the Cura devs to change their code)
However the code does cancel the obects.
NOTE: THERE WAS A SYNTAX ERROR IN THE ABOVE CODECorrected code here
if !{state.status="processing"} M291 P"Not printing" R"Error" S1 T7 abort "Not printing" if {job.layer<2} M291 P"Not all objects may be detected yet. Continue?" R"Warning" S3 G4 S0.5 if {(#job.build.objects=null) || (#job.build.objects=0)} M291 P"No objects detected. Check slicer or wait till end of first layer" R"Error" S2 ;abort "No objects" ;if {(job.build.currentObject=null) || (job.build.currentObject=-1)} ; M291 P"Current print move is not a print object" R"Not a print object" S2 ; abort "not a print object" while iterations < #job.build.objects echo "check object " ^ iterations + 1 if job.build.objects[ iterations ].cancelled echo "Obect " ^ iterations ^ "already cancelled" G4 S2 continue M291 P{(job.build.objects[iterations].name)} R"Delete?" S3 M486 P{iterations} G4 S2 echo "Finished"
-
I have just tried @dc42's macro with my system setup in standalone mode rather than the D3+SBC setup I tried yesterday and can confirm that it works fine & as intended.
So I guess that's a bug in the way DCS handles the "iterations" variable in meta commands?@OwenD
Thanks for sharing your macro, it covers off a couple of edge cases from a user perspective when displaying details -
@OwenD
Thanks for sharing your macro, it covers off a couple of edge cases from a user perspective when displaying detailsNo Problem.
My macro won't work as it should until there's a third option for M291 that will allow us to skip over objects.
At present you can't cancel object two until you have done object one. -
@ChrisP This will be fixed in the next versions. For now, you can work-around this problem by putting
iterations
into curly brackets. Something likejob.build.objects[{iterations}].x[0]
should work.The next DCS version will send whole line comments to RRF, too.