2.6.0a6 Label Objects

[claudermilk]

Description of the bug

Label Objects doesn't seem to be working. Setting this option to on in Print Settings/Output options/Output file should allow Klipper with Mainsail or Fluidd to use the object exclusion. When printing a file with multiple objects sliced on 2.6.0a6 there is no object box to select in the Gcode preview.

Project file & How to reproduce

In Print Settings/Output options/Output file check Label objects. View Gcode Preview in Fluidd or Mainsail web interface.

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.6.0alpha6

Operating system

Windows 10

Printer model

Voron Trident with Stealthburner and Revo

[kubispe1]

It seems to me it is broken in all 2.6.0 releases.
All objects are in id:0 so you are not able to disable them.
There is an example of my G-Code:
260_a5_STL_Import_CrossCheck_0.2mm_PLA_MK3S_1h17m.zip

; printing object STL_3.stl id:0 copy 0
G-CODE
; stop printing object STL_3.stl id:0 copy 0
; printing object SLT_1.stl id:0 copy 0
G-CODE
; stop printing object SLT_1.stl id:0 copy 0
; printing object STL_2.stl id:0 copy 0
G-CODE
; stop printing object STL_2.stl id:0 copy 0

[kubispe1]

SPE-1641

[robot256]

In my case, Klipper does show the dialog to select which object to exclude, but the objects are grouped randomly. I have a project with 40 copies of one STL file. There are 40 object start and stop pairs, but the numbers are not unique or comprehensive--there are several different "copy" numbers used, but multiple objects are labeled with the same number and many numbers are omitted. For example, this snippet appears in the first layer:

;WIDTH:0.478294
G1 X38.241 Y53.025 E.03722
M204 S3000
; stop printing object visor.stl id:0 copy 3
; printing object visor.stl id:0 copy 3
G1 E-.5 F3000
G1 Z.6 F18000

The full sequence of "id:0 copy" numbers in this case is "20, 17, 8, 9, 6, 7, 15, 18, 13, 8, 4, 3, 3, 6, 9, 15, 17, 10, 4, 0, 0, 2, 5, 14, 12, 7, 2, 1, 1, 5, 11, 14, 21, 16, 13, 11, 10, 12, 16, 19", and then the layer change and the sequence repeats. This would be nice for a series of D24 rolls, but doesn't help identify which of the 40 objects to disable.

Full example: broken_object_ids.zip

In fact, I loaded this same project in PS 2.5.0 and got the exact same garbled sequence of copy IDs out. When I selected "new project" and re-added the STL objects (transferring all the previous settings to the new project), it created the correct sequence of object ids in the gcode file.

Further edit: When a 2.6.0a6 project contains multiple different STL files, they are labeled " id:0 copy 0", and Klipper correctly distinguishes them. It appears to be only when multiple copies of the same object are added that it becomes a problem.

A further hypothesis: In the problematic project, I may have done something like add the first object, click "+" 20 times, selected some copies at random to delete, and then added more with the "+" button again. It's possible that this is related to the copy numbering corruption. If the copy numbers are stored in the project associated with a particular instance, that might explain why PS 2.5 used the same incorrect numbers when loading the 2.6 project.

[bubnikv]

The object labeling likely never worked in PrusaSlicer. Likely it was contributed,
but not reviewed sufficiently (by me I suppose). The instance ID was calculated correctly, but not the object ID.

Now the object ID is calculated as an index in the list of PrintObjects,
the order is arbitrary but stable, indices start with 0 and incremented
for every printed object with no gap in indices.

We are not quite sure how the indices are used by the OctoPrint
"Cancel Object" plugin or by Klipper / Mainsail, I suppose this change is sufficient.

Implemented with fd3c41b, which will be published with the next alpha (or first beta).

[robot256]

Thank you! I just finished a postprocessing script to reassign names. It will be good to have the fix built in.

AFAIK, Klipper and Octoprint don't actually parse the contents of the label. Everything after "; printing object " is treated as a string key. This is why object detection works when only one copy of each STL was included, even though they were all given the same id and copy number.

[FidelCapo]

This issue should be fixed and fix will be part of next release.
Closing.