M486 does not list all objects and M486 C does not work
PaulHew last edited by PaulHew
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.
Does the same hold true for firmware 3.1.1?
I will check @Phaedrux
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.
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
Also in the Bottom right - I am in the console!
Hope this info helps
@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?
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 last edited by
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.
@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."