Macro errors in 3.3b1 on D2/Dx5
-
Hey guys,
I am running RRF3.3beta1 on a Duet 2/ Duex 5 Jubilee toolchanger, and I've noticed a really odd occurrence with how macros are called from gcode.
In my tpost.g, I have a sequence of commands that also includes calling a "tool_lock.g" macro to actuate my U-axis locking mechanism. Now this has always run just fine on every single stable RRF release since 2.0.5, and was running smoothly on 3.3beta1, until now.
Several times today, on multiple gcode files, it seems like the Duet isn't calling the tool change macro "tool_lock.g" from the tpost file. All the other commands in my tpost are being executed flawlessly, but it seems like running a custom macro has some sort of buffer glitch. My M122 report (attached ofc) states an error code of 0x0C, which could be both buffer errors being triggered (since there's nothing wrong with the SD card apparently).
I've triple-checked for any wiring issues, of which there are none, and manually running the macro from my PanelDue is flawlessly executed every single time. Its only when I call the macro "tool_lock.g" from the DWC console using the M98 command from the tpost that I get a weird pause in DWC, as if its churning away in the background to execute what I've inputted.
Event log is clear, nothing happening there. The only indication (other than the failure to lock my tool) is the error code in the M122 output. I'm stumped.
Any ideas?
=== Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3beta1 running on Duet WiFi 1.02 or later + DueX5 Board ID: 08DGM-917NK-F2MS4-7J1F0-3S46R-KGS4D Used output buffers: 3 of 24 (24 max) === RTOS === Static ram: 21448 Dynamic ram: 77604 of which 60 recycled Never used RAM 12968, free system stack 96 words Tasks: NETWORK(ready,229) HEAT(delaying,310) DUEX(notifyWait,23) MAIN(running,293) IDLE(ready,19) Owned mutexes: WiFi(NETWORK) === Platform === Last reset 00:15:12 ago, cause: power up Last software reset at 2021-03-11 18:16, reason: User, GCodes spinning, available RAM 12968, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x0c Aux0 errors 0,0,0 MCU temperature: min 19.1, current 34.4, max 34.6 Supply voltage: min 24.1, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: position 40770, ok, SG min/max 0/1023 Driver 1: position 5275, ok, SG min/max 0/1023 Driver 2: position 9373, ok, SG min/max 0/1023 Driver 3: position 0, ok, SG min/max 0/1023 Driver 4: position 0, ok, SG min/max 0/1023 Driver 5: position 0, standstill, SG min/max not available Driver 6: position 0, standstill, SG min/max not available Driver 7: position 0, standstill, SG min/max not available Driver 8: position 0, ok, SG min/max 0/1023 Driver 9: position 0, standstill, SG min/max not available Driver 10: position 0 Driver 11: position 0 Date/time: 2021-03-11 22:22:02 Cache data hit count 936346140 Slowest loop: 135.66ms; fastest: 0.11ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 8 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 4.2ms, write time 149.5ms, max retries 0 === Move === DMs created 83, maxWait 95560ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 10794, completed moves 10761, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 2], CDDA state 3 === 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 -1 -1, chamberHeaters = -1 -1 -1 -1 Heater 0 is on, I-accum = 0.0 Heater 3 is on, I-accum = 0.7 === 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 F7200.000" 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is not empty: Queued 'M106 S247.35' for move 10783 1 of 16 codes have been queued. === DueX === Read count 1, 0.07 reads/min === Network === Slowest loop: 157.77ms; fastest: 0.00ms Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.25 WiFi MAC address 60:01:94:2e:9f:97 WiFi Vcc 3.39, reset reason Turned on by main processor WiFi flash size 4194304, free heap 26616 WiFi IP address 192.168.1.202 WiFi signal strength -57dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 2 0 0 0 0 0 0 -
Beta2 is out now, please give that a try.
https://github.com/Duet3D/RepRapFirmware/releases/tag/3.3beta2
-
Forgot to reply and close this out: running beta 2 now, seems to be alright, but the root cause was my hardware and not the controller or the firmware. A slight oversight on my end was definitely the culprit!
Cheers!
