M486 does not list all objects and M486 C does not work

Phaedrux

Does the same hold true for firmware 3.1.1?

PaulHew

Regards
Paul

dc42

Due to the amount of memory needed to store the details of objects on the build plate, RRF on Duet 2 tracks a maximum of 10 objects on the build plate, and allows up to 200 characters to store the object names. I could increase these figures a little, but not sufficiently to cover the large number of objects on your build plate.

Duet 3 has more RAM so the limits are higher.

PaulHew

12 Objects on the bed, 2 different items, 6 of each

Layer1 is down, this is the response from M486

0: X 92 to 169mm, Y 107 to 163mm, XY_Link.stl id:0 copy 0
 1: X 135 to 169mm, Y 113 to 151mm, XY_Link.stl id:0 copy 4
 2: X 135 to 153mm, Y 99 to 122mm, clip_xX.stl id:1 copy 5
 3: X 96 to 142mm, Y 106 to 135mm, XY_Link.stl id:0 copy 5
 4: X 96 to 130mm, Y 121 to 163mm, XY_Link.stl id:0 copy 2
 5: X 96 to 130mm, Y 148 to 190mm, XY_Link.stl id:0 copy 3
 6: X 107 to 169mm, Y 168 to 190mm, XY_Link.stl id:0 copy 1
 7: X 146 to 192mm, Y 170 to 179mm, clip_xX.stl id:1 copy 3
 8: X 174 to 192mm, Y 155 to 178mm, 
 9: X 174 to 192mm, Y 141 to 164mm

Console output

Also in the Bottom right - I am in the console!

Hope this info helps

Kind regards,

Paul

PaulHew

@dc42 Thanks for your reply, appreciated.
When the interface for Duet2 to Raspberry Pi is complete, will this then be unlimited in regards to 'objects' as the majority of the processing is done on the Pi as opposed to the Duet?

Regards,
Paul

dc42

The object tracking is done on the Duet. We have no plans to move it to the Pi, although it would be possible to write a plugin to do that.

I could increase the number of tracked objects. When I chose 10, I thought that would be enough. Evidently, it isn't!

pixelpieper

You have a for all practical purposes infinite amount of memory on the SD card - why do you need to keep more than the current object information in SRAM? That could also be useful for error recovery with object cancellation, allowing to safely resume.

PaulHew

@dc42 But as you say, if object tracking is done on the Duet and it can only track 10 objects, what is the point of having a plugin that will interrogate the tracking on the Duet, its only going to report 10 objects.

300mm x 300mm bed is small compared to others who use Duet and I am sure they do not think, 'I can only put a max of 10 objects on my bed just incase one fails and I need to cancel'

Looking at the GCode bible, there is nothing that states the maximum of how many objects can be tracked.
M486 C specifies that it will cancel the current object, which I tried multiple times to no avail.
Maybe it should be clearer and say 'M486 C will only work if the object is listed with M486'

You may think I am being picky, but when a function informs it will do X function, you kind of expect it to do it. My main issue as mentioned, 'M486 C' does not work as stated.
FYI I lost all of the parts on that plate, due to one failing and not being able to cancel it. Wasting 6 hours of 12 hour build.

@pixelpieper Is not the first person to mention about using the SD Card instead of RAM.
Quote from another Duet User
"Memory should not be an issue, he can dump the object tracking onto the SD card, the printer movements are typically much slower than reading/writing from the SD.
And by definition you are always only printing a single object at once, so no need to keep the full information in memory all the time.
And no, this is not going to kill the card with the little amount of data needed to be written."

Regards,
Paul

gnydick

@dc42 I just found this post because I hit this myself. Am curious to know the details of how the build plate objects are stored. For example, wouldn't it be pretty minimal to do something like the below array?

objs[i(int)] = [0|1(bit)]

I know nothing about coding for these boards, so any friendly discussion/teaching in a DM would be cool.

ww1g16

Reviving an old thread, apologies!

We're coming across this same issue on our print farm. Our use case is normally printing the same small part around 50-80 times on a print bed, and we recently moved to incorporate object labelling to our gcode from PrusaSlicer. Only came across the 10 object issue during preliminary testing, and then found this forum thread. Is there any planned increase of this object limit? By what means I don't know, others seem to have made some suggestions about storing information on the SD card - is this feasible?

dc42

Storing object details on the SD card would currently create a lot of SD card traffic because of the way that the objects are described and accessed in the object model.

It would certainly be possible to increase the number of objects stored in RRF builds for Duet 3, especially if the names of objects were not stored, or the names of only the first ~10 objects were stored. How many objects need to be handled?

ww1g16

Having seen a lot of the work that has been done with the gcode viewer, I don't think being able to see the part names for all of the parts is too essential. I know this is only in my use case, but despite having up to around 180 parts they are all the same part so storing the name for all of them isn't necessary. Alas all our machines are on Duet 2 Wifi's though - so am I right in thinking this would definitely need to be Duet 3 and above?