Bed Mesh parameters missing and the return of errors
-
Not sure what is going on here.
My M557 is defined
M557 X30:280 Y45:290 S20but when I look at the paramters in 'Define Mesh Area' in the GUI it shows me this.
Should it not read the params from the M557?
And the other issue since upgrading to 3.3.0, I am getting numerous 'Network Errors'
I ran the G32 once, it errored, had to run again to make sure it had levelled the bed.
Regards,
Paul -
-
...And because I did not spot the 'Network error' running a G29, it has meshed the whole bed but no file has been created.
m122 === Diagnostics === RepRapFirmware for Duet 3 Mini 5+ version 3.3 (2021-06-15 21:46:11) running on Duet 3 Mini5plus Ethernet (SBC mode) Board ID: A45XG-F396U-D65J0-40KML-1F03Z-H03XP Used output buffers: 7 of 40 (20 max)and
m122 b20 Diagnostics for board 20: Duet TOOL1LC firmware version 3.3 (2021-06-15 16:12:58) -
@paulhew Are you running in SBC mode with a rPi attached? If so how are you connecting to the rPi? It might be worth posting the full output of M122.
-
@gloomyandy Yes I am running SBC. Was not getting the errors with the RC version.
As I mentioned after the Network Error, it finished the Mesh, but did not save a file.It was mentioned previously that it was my browser / computer, but cannot see how that is an issue considering the error is originating from the Firmware / software.
M122 in full
m122 === Diagnostics === RepRapFirmware for Duet 3 Mini 5+ version 3.3 (2021-06-15 21:46:11) running on Duet 3 Mini5plus Ethernet (SBC mode) Board ID: A45XG-F396U-D65J0-40KML-1F03Z-H03XP Used output buffers: 7 of 40 (20 max) === RTOS === Static ram: 102724 Dynamic ram: 94188 of which 0 recycled Never used RAM 43936, free system stack 128 words Tasks: SENSORS(delaying,0.0%,78) SBC(resourceWait:,8.1%,324) HEAT(delaying,0.0%,369) Move(notifyWait,0.1%,283) CanReceiv(notifyWait,0.0%,773) CanSender(notifyWait,0.0%,371) CanClock(delaying,0.0%,347) TMC(notifyWait,0.7%,106) MAIN(running,90.1%,500) IDLE(ready,0.2%,29) AIN(delaying,0.8%,264), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:26:24 ago, cause: software Last software reset at 2021-06-20 08:26, reason: User, GCodes spinning, available RAM 44108, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 MCU revision 3, ADC conversions started 1584037, completed 1584037, timed out 0, errs 0 Step timer max interval 1501 MCU temperature: min 26.7, current 37.1, max 44.3 Supply voltage: min 23.9, current 23.9, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/502/502, gc cycles 0 Driver 0: position 105400, standstill, SG min/max 0/390, read errors 0, write errors 1, ifcnt 85, reads 17806, writes 16, timeouts 0, DMA errors 0 Driver 1: position 5400, standstill, SG min/max 0/336, read errors 0, write errors 1, ifcnt 85, reads 17806, writes 16, timeouts 0, DMA errors 0 Driver 2: position 10019, standstill, SG min/max 0/232, read errors 0, write errors 1, ifcnt 81, reads 17806, writes 16, timeouts 0, DMA errors 0 Driver 3: position 0, standstill, SG min/max 0/260, read errors 0, write errors 1, ifcnt 81, reads 17805, writes 16, timeouts 0, DMA errors 0 Driver 4: position 0, standstill, SG min/max 0/254, read errors 0, write errors 1, ifcnt 81, reads 17806, writes 16, timeouts 0, DMA errors 0 Driver 5: position 0, assumed not present Driver 6: position 0, assumed not present Date/time: 2021-06-20 08:53:18 Cache data hit count 3647547555 Slowest loop: 199.35ms; fastest: 0.07ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 0.0MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 83, maxWait 336650ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 590, completed moves 590, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 3], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by null HTTP* is doing "M122" in state(s) 0 Telnet is idle in state(s) 0 File is idle 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 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === CAN === Messages queued 15382, received 20351, lost 0, longest wait 2ms for reply type 6031, peak Tx sync delay 259, free buffers 17 (min 16), ts 7921/7920/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === State: 4, failed transfers: 0, checksum errors: 0 Last transfer: 4ms ago RX/TX seq numbers: 56997/56997 SPI underruns 0, overruns 0 Disconnects: 0, timeouts: 0, IAP RAM available 0x10b2c Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.3.0 Code buffer space: 4096 Configured SPI speed: 8000000Hz Full transfers per second: 36.00, max wait times: 13.8ms/0.0ms Codes per second: 0.41 Maximum length of RX/TX data transfers: 3504/748P.
-
@paulhew If you are getting network errors with an SBC setup then those errors must be between your PC and rPi. How do you have these two connected (WiFi, wired ethernet, both?). You may want to open an ssh connection between your PC and the rPi and leave it running to see if that connection shows any errors. If you are using WiFi to the rPi you may also want to check the signal strength. The change in errors may just be a coincidence with the firmware upgrade if the signal is marginal. It is also likely that when you upgraded your SBC software you also picked up changes to the rPi operating system, which may have impacted things. Oh and how are you powering your rPi? It might be worth checking for low voltage events in the rPi syslog.
-
@gloomyandy Thanks for the reply.
Apart from the V0.1 all are hardwired to a managed switch, including my Linux machine.I ssh'd into the pi and it has not reported any power issues.
As I said, I had them previously, then they stopped as I updated to beta versions when there was a issue with the Mini5+, but since updating to 3.3.0 they have come back again.
However, just checked the other issue and that is now reading the correct parameters.
Do not understand....
-
Could you enable monitoring on the Pi side?
https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Monitoring_optional
