Macro to assist with using object cancellation

dc42

If you decide to copy the Prusa approach, then RRF doesn't need the object name following "; stop printing object" because it already knows it.

The whole of the remaining text on the line after "; printing object " is treated by RRF as the object name. I suggest you include at least the name of the STL file and the copy number. Similarly if you use M486 to label the objects and you provide the A parameter.

ChrisP

@dc42
Just been having a play with this to see how it works. I've just done a slice of 4 instances of one object using PrusaSlicer and enabled labels, but it doesn't seem to detect any objects. The file otherwise prints fine.

Here's a snip of the file showing, like your example, the start and stop labels for two objects:

G1 X78.145 Y74.891 E0.24387
G1 X78.380 Y75.460 E0.05244
G1 X78.563 Y75.795 E0.03248
G1 X78.846 Y76.192 E0.04154
G1 X79.648 Y76.996 E0.09671
; stop printing object Marvin_KeyChain.STL id:0 copy 3
; printing object Marvin_KeyChain.STL id:0 copy 1
G1 F7200.000
G1 X78.846 Y76.192 E-0.44953
G1 X78.563 Y75.795 E-0.19310
G1 X78.380 Y75.460 E-0.15095
G1 X78.145 Y74.891 E-0.24374
G1 X80.170 Y76.916 E-1.13350
G1 X80.540 Y76.890 E-0.14686
G1 X80.701 Y76.844 E-0.06624
G1 X78.171 Y74.315 E-1.41607
G1 E-5.82113 F3000.00000
G1 Z0.500 F9000.000
G1 X42.461 Y73.912
G1 Z0.200
G1 E9.62113 F3000.00000
G1 F900.000
G1 X42.296 Y74.641 E0.06086

Running the macro from post #1 returns "No objects", and the OM returns this for job.build:

{
  "key": "job.build",
  "flags": "",
  "result": {
    "currentObject": -1,
    "m486Names": false,
    "m486Numbers": false,
    "objects": []
  }
}

Not sure if there's something I'm missing? Using 3.0.1-RC11 w/SBC.

dc42

Were you printing that file when you ran the macro? Object names are only added to the list as the machine starts printing them.

bot

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.

ChrisP

@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.

dc42

Thanks. It sounds to me that DCS isn't yet passing the comments on to RRF.

ChrisP

@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
2020-05-02 (2).png
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?

OwenD

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 yet

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"
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

@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?

OwenD

@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.6

I 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

OwenD

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 CODE

Corrected 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"

ChrisP

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

@OwenD
Thanks for sharing your macro, it covers off a couple of edge cases from a user perspective when displaying details

No 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.

chrishamm

@ChrisP This will be fixed in the next versions. For now, you can work-around this problem by putting iterations into curly brackets. Something like job.build.objects[{iterations}].x[0] should work.

The next DCS version will send whole line comments to RRF, too.