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

PaulHew

m115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.1.0 ELECTRONICS: Duet Ethernet 1.02 or later + DueX5 FIRMWARE_DATE: 2020-05-15b1

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.0 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-917DA-G4MS8-6JKDL-3SN6N-TVVB9
Used output buffers: 3 of 24 (22 max)
=== RTOS ===
Static ram: 28180
Dynamic ram: 94464 of which 48 recycled
Exception stack ram used: 568
Never used ram: 7812
Tasks: NETWORK(ready,76) HEAT(blocked,1224) DUEX(suspended,160) MAIN(running,1632) IDLE(ready,80)
Owned mutexes:
=== Platform ===
Last reset 57:53:39 ago, cause: software
Last software reset at 2020-06-06 12:27, reason: User, spinning module GCodes, available RAM 7820 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 23.6, current 36.4, max 38.9
Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, SG min/max 0/1023
Driver 1: ok, SG min/max 0/1023
Driver 2: standstill, SG min/max not available
Driver 3: ok, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max 0/1023
Driver 6: standstill, SG min/max 0/1023
Driver 7: standstill, SG min/max 0/1023
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-06-08 22:21:32
Cache data hit count 4294967295
Slowest loop: 147.74ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 5.1ms, write time 30.4ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 162, MinFreeDm: 106, MaxWait: 25311689ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 238143, completed moves: 238117, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: 3
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 E1.00000 F3600.00000" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 217.04ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
Interface state active, link 100Mbps full duplex
=== DueX ===
Read count 1, 0.00 reads/min

I have a lot of objects on my build plate, Sliced with SuperSlicer (PrusaSlicer enhanced) and Label objects was enabled.

One object decided it did not want to stick.
Ran M486 and only 10 objects were listed, some with names most with out.
Could not find the one I wanted, even using the XY references.

This is my build plate, as you can see there are more than 10 items.

This is the info I get from M486

0: X 69 to 78mm, Y 66 to 122mm, XYZ-Clip_Option1_defaultxA.stl id:0 copy 0
 1: X 55 to 75mm, Y 104 to 133mm, XYZ-Clip_Option1_defaultxA.stl id:0 copy 8
 2: X 56 to 72mm, Y 116 to 153mm, XYZ-Clip_Option1_defaultxA.stl id:0 copy 14
 3: X 54 to 69mm, Y 136 to 174mm, XYZ-Clip_Option1_defaultxA.stl id:0 copy 7
 4: X 59 to 77mm, Y 158 to 186mm, 
 5: X 68 to 77mm, Y 171 to 209mm, 
 6: X 73 to 105mm, Y 172 to 206mm, 
 7: X 100 to 132mm, Y 172 to 206mm, 
 8: X 128 to 160mm, Y 172 to 209mm, 
 9: X 158 to 187mm, Y 183 to 222mm,

When it started printing the long object, I issued a M486 C but it did not stop printing that object and continued printing on subsequent layers.

Even with the macro some kind person wrote, it does not go above 10

10 objects on build plate
Object 0 XYZ-Clip_Option1_defaultxA.stl id:0 copy 0
  X 69.4 to 79.0
  Y 66.0 to 122.5
Object 1 XYZ-Clip_Option1_defaultxA.stl id:0 copy 8
  X 55.0 to 75.7
  Y 105.0 to 133.5
Object 2 XYZ-Clip_Option1_defaultxA.stl id:0 copy 14
  X 56.4 to 72.6
  Y 116.0 to 154.0
Object 3 XYZ-Clip_Option1_defaultxA.stl id:0 copy 7
  X 54.9 to 69.3
  Y 136.5 to 174.3
Object 4 
  X 59.6 to 77.7
  Y 158.3 to 186.2
Object 5 
  X 68.4 to 78.0
  Y 171.1 to 209.2
Object 6 
  X 73.0 to 105.2
  Y 172.7 to 206.2
Object 7 
  X 100.7 to 132.8
  Y 172.7 to 206.2
Object 8 
  X 128.3 to 160.4
  Y 172.6 to 209.1
Object 9 
  X 158.0 to 187.9
  Y 183.5 to 222.9

Also I did not enter the command once, but multiple times so I could save the rest of the parts, but it carried on printing the part I no longer wanted it to print!

Hope someone can shed some light on this please.

Kind Regards,

Paul

Phaedrux

Does the same hold true for firmware 3.1.1?

PaulHew

I will check @Phaedrux

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?