Posts made by Leonard03

Just yesterday, I noticed that temperatures now are shown as integers in DWC and PanelDue. I also checked the Object Model, and all temperatures are reported as integers. Yes, there is a decimal point in DWC and PanelDue, but it is always 0.
For example, heating the nozzle shows 80.0, 81.0, 82.0, etc.
It is not an issue per se, but I thought it was worth pointing out.
This happens at least with 3.6.0-beta.2+4. I don't know if earlier versions behaved the same.

@dc42

@dc42 said in [RRF 3.6.0-beta.2 Error code 7]:

Was the issue readily reproducible using the earlier beta version, or didn't occur just once?

This issue occurred twice, with two different gcodes and two different RRF versions.
With 3.6.0-beta.1 I had some Code 3 errors wich now are solved.
With 3.6.0-beta.2 first saw the Code 7 but printing the same gcode again next day did the trick. First time I got that error, second time completed without any issues.
Second occasion when I encountered this error was with another gcode (that in the first post) but again, repeating a slightly modified gcode (repositioned a modifier in PrusaSlier) completed without any issues.

I cannot reproduce this error twice, and it was very random. A simulation of that gcodes completed every time without problems. Printing that gcodes second time, again, completed without issues.

By the way, also with beta.2+4 now I can get a M122 report via DWC.

As regarding the PannelDue and DWC:
I followed @chrishamm advices from this post https://forum.duet3d.com/post/347660 and modified those parameters:
Number of maximum AJAX retries: from 20 to 3;
Time to wait between AJAX retries (ms): from 200 to 250;
PanelDue baud rate: from 57600 to 115200.

Now I have a pretty good connection for DWC. Still disconnects sometimes but is waaay better and stable then before.

The only side effect being that now the PanelDue now says that it receives malformed responses after around 15 seconds after the M0 at the end of a job files is completed. Even in that case can send command to the board, but not the other way around. Strange thing is that if I hit "print again" either from PanelDue itself or from DWC, comms with it goes to normal. Reverting the baud rate does not make any difference for this behavior.

Solved by 3.6.0-beta.2+4 Thank you Duet3D team!

Hello everyone!

I got a strage issue with my printer, after an 8 hours print, i got this error:

Sadly I cannot get a M122 report for two reasons:
In DWC with 3.6.x I cannot get an M122 report even if other comands works as expected
Over USB, I needed to do an emergency stop wich cleared the relevant report..

My board is a Duet 2 WiFi + Duex5 with MMU3

Anyway, I will upload my config files to google drive and update this post.
All that I have is the gcode and the aproximate layer height when the error occured

By the way, with beta 1 for only one print I got the exact same error, the next day I do a simulation wich completed as expected, printed the exact same gcode without any problems. So, seems to be a random issue wich I can't reproduce myself twice. I started a slightly modified print now to see how it goes

Thank you in advance, and any help is welcomed!

Update:
This is the gcode in question: Jack Case_STEC7_0.2mm_PLA_5h24m.gcode
The error occurred on layer 312 / Z height 62.40 most likely somewhere around line 117292 in that gcode

This is my config/SD card https://drive.google.com/drive/folders/1OcTPiUw0RlYuLT-Skopb6It37nG4u9Io?usp=sharing

Hello everyone! @kingofthegeeks might worth check the cables and mainly the screw terminals between PSU and the main board. I have a Duet 2 WiFi and some time ago got the exact same issues as you described. At power up, random overtemperature on all drivers even if the printer was working as expected. In that case I never got an undervoltage warning. Everything keept goind apart from overtemperatures on basicaly every driver (2wifi + duex5). Turned out that the connector between the psu and the board somehow loosen and got molten

@dc42 It works! And it works flawlessly!
With this build I've done some multihour prints with many tool changes and they worked perfect, no more resets (at least from thar reason).
For the PanelDue, using PanelDueFirmware-3.5.0-rc7-testcomm DWC is more responsive, more fluid, it updates more often and the connection is more consistent.
As a side note - annoying but don't bother me too much - after some time the DWC disappears altogether. I can ping the board, but no DWC. But until that point works flawlessly. By the way, trying to disable and reenable the wifi module (idle or printing) resulting in a stuckinspinloop when trying to enable it again.

Again, thank you very much for your time and help solving this issue!

@dc42 for me seems that made a big difference. Not a single drop in DWC into a 7 hours print so far

@dc42 Thank you very much for your response and for the binaries.
I will download them now and test tomorrow and report back

@dc42 said in Duet 2 WiFi HardFault invState:

Do you still have a copy of the .map file for the version of RRF that generated the M122 report in your original post?

Yes, I attached it here, but I changed the extension jut to have the ability to add it here. The extension is .map not .binDuet2CombinedFirmware_MAP.bin

@dc42 thank you for the answer. Sadly I can't find a good way to ground the V6 heatsink from the cold side. It is possible to use TVS diodes as a workaround? I'm using a PT100 daughterboard. It is possible to add at least one diode to one of the temperature sensor? Or they will affect the sensor/daughterboard functionality?

@Exerqtor that been said.. now I'm thinking about my setup.. I forgot that between the motor and the drive gears for a BMG is the big plastic gear
Seems like I'd grounded only the extruder motor, not the filament path in any way.. Great, another thing to think about

@Exerqtor here I cand give you an ideea about grounding. After I had almost the same issue about one year ago (?) as David said, I've grounded all seven steppers on by printer by a ring connector (if this is how is called) and three washers between sthe motors and the mounting points. The washers should be the same thickness as the ring of the connector. Not the most elegant way, but it does the job. All connections I've done to the ATX PSU and from there on is groundes by the power plug (seems that the duet2wifi is grounded with the PSU by the negative terminal).

Abount grounding the hotend, I'm running an E3D V6 gold edition with the PT100 and the DB but back then I've contacted E3D but they sayd that the heatsink of the hotend is not conductive, so the only grounding for the filament path is by the motor shaft being in contact with it

Hello! I started to have the same symptoms with my board (https://forum.duet3d.com/topic/33857/duet-2-wifi-hardfault-invstate) and I wonder if this tyoe of reset has something to do with the powersupply itself. Can a quick drop in the powersupply output result in this type of crash? A drop that is long enogh to cause a drop in the 3v3 circuit of the processor?
Just an idea..

I can think to an idea about running some code if the current tool is -1 but it will work only if you change tools, something in tpre, not with the current tool but with state.previousTool:

In the tpre file you can start with the statement:
If state.previousTool = -1
else....

But if you unload your tool, i guess that your only option will be via deamon.g and some kind of global variable to indicate if the code from deamon should be executed or not.

This is my ideea, but I dont know if it will or not but anyway:
In daemon.g you can see if a new tool is pending the load and the current tool that is used.

I would combine two statements something like
If state.currentTool = -1 && state.nextTool = -1
Code to execute

Hello! This is my first answer to aomone on the formum, so I apologize if I make any mistake

I have a setup with am MMU2. What I've seen is that the any value in OM is updated after any tool change macro is completed. So, again, if I not mistaken, the T-1 command will update state.CurrentTool after the tfree has completed

As an update, now I've completed the same gcode that in the first post failed. Now the exact file has completed successfully in 7h 49m 40s

The only difference was to disable the write buffer via M122 P500 S0
The diagnostics after this print job is this:

10/20/2023, 7:07:53 PM: M122: === Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.0-rc.1+ (2023-09-27 13:34:46) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917NK-F2MS4-7JKDG-3S06M-9ZSWD
Used output buffers: 4 of 26 (26 max)
=== RTOS ===
Static ram: 23076
Dynamic ram: 79228 of which 52 recycled
Never used RAM 7140, free system stack 110 words
Tasks: NETWORK(2,nWait,191.2%,182) HEAT(3,nWait,1.2%,308) Move(4,nWait,20.6%,261) DUEX(5,nWait,0.0%,26) MAIN(1,running,156.4%,691) IDLE(0,ready,0.6%,29), total 370.1%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 08:12:17 ago, cause: software
Last software reset at 2023-10-20 10:55, reason: User, Gcodes spinning, available RAM 7260, slot 1
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 25.2, current 25.8, max 27.0
Supply voltage: min 11.8, current 12.3, max 12.4, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/23, heap memory allocated/used/recyclable 2048/588/128, gc cycles 138
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min 0
Driver 5: standstill, SG min 0
Driver 6: standstill, SG min 0
Driver 7: standstill, SG min 0
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10: 
Driver 11: 
Date/time: 2023-10-20 19:07:50
Cache data hit count 4294967295
Slowest loop: 215.79ms; fastest: 0.14ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 47.5ms, write time 1.6ms, max retries 0
=== Move ===
DMs created 83, segments created 33, maxWait 12407ms, bed compensation in use: mesh, height map offset 0.009, ebfmin -1.00, ebfmax 1.00
no step interrupt scheduled
Moves shaped first try 15140, on retry 2857, too short 20305, wrong shape 63713, maybepossible 4509
=== DDARing 0 ===
Scheduled moves 294957, completed 294957, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Code queue 0 is empty
=== DueX ===
Read count 1804, 4.40 reads/min
=== Network ===
Slowest loop: 34.03ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1beta5
MAC address b4:e6:2d:52:f5:47
Module reset reason: Power up, Vcc 3.40, flash size 2097152, free heap 43056
WiFi IP address 192.168.0.107
Signal strength -49dBm, channel 11, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
10/20/2023, 7:08:00 PM: M122 P500: Write buffer is disabled

Hello everyone!
Sadly, I have again problems with my board which started to restart itself after many hours during a print

My new reason for the resets is "HardFault invState".
SD card image/configuration is here: https://drive.google.com/drive/u/0/folders/1OcTPiUw0RlYuLT-Skopb6It37nG4u9Io

The resets occured one time after 4 hours into a print and another after 7,5 hours the reason being the same. Both times the WiFi network/DWC page has long gone (maybe after one hour after starting a print)

The response from M122 is:

10/11/2023, 1:57:40 PM: Connected to 192.168.0.107
10/11/2023, 4:19:25 PM: M122: === Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.0-rc.1+ (2023-09-27 13:34:46) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917NK-F2MS4-7JKDG-3S06M-9ZSWD
Used output buffers: 3 of 26 (26 max)
=== RTOS ===
Static ram: 23076
Dynamic ram: 77804 of which 12 recycled
Never used RAM 9396, free system stack 194 words
Tasks: NETWORK(2,nWait,14.0%,218) HEAT(3,nWait,0.0%,329) Move(4,nWait,0.0%,364) DUEX(5,nWait,0.0%,26) MAIN(1,running,85.9%,743) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:21:59 ago, cause: software
Last software reset at 2023-10-11 15:57, reason: HardFault invState, Gcodes spinning, available RAM 6372, slot 0
Software reset code 0x4063 HFSR 0x40000000 CFSR 0x00020000 ICSR 0x0041f803 BFAR 0xe000ed38 SP 0x200022b8 Task MAIN Freestk 995 ok
Stack: 00000001 200012d4 20000150 06000000 00000000 0045ef43 200048dc 000f0000 200048dc 00000003 00000003 00000000 00000003 0000003e 2000239c 00000000 004592f9 00000000 00433ed9 2000239c 0000003e 2000239c 00000003 00000000 200049a5 2000241e 00000001
Error status: 0x04
Aux0 errors 0,0,0
MCU temperature: min 25.1, current 25.1, max 26.2
Supply voltage: min 0.5, current 0.6, max 0.6, under voltage events: 0, over voltage events: 0, power good: no
Heap OK, handles allocated/used 99/23, heap memory allocated/used/recyclable 2048/504/44, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: ok, SG min n/a
Driver 1: ok, SG min n/a
Driver 2: ok, SG min n/a
Driver 3: ok, SG min n/a
Driver 4: ok, SG min n/a
Driver 5: ok, SG min n/a
Driver 6: ok, SG min n/a
Driver 7: ok, SG min n/a
Driver 8: ok, SG min n/a
Driver 9: ok, SG min n/a
Driver 10: 
Driver 11: 
Date/time: 2023-10-11 16:19:26
Cache data hit count 4294967295
Slowest loop: 9.76ms; fastest: 0.15ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 4.9ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Code queue 0 is empty
=== DueX ===
Read count 0, 0.00 reads/min
=== Network ===
Slowest loop: 21.31ms; fastest: 0.07ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1beta4
MAC address b4:e6:2d:52:f5:47
Module reset reason: Power up, Vcc 3.40, flash size 2097152, free heap 42864
WiFi IP address 192.168.0.107
Signal strength -34dBm, channel 11, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

Searching the .map file, I found this codes from the stacktrace:

00000001	 .data.tzinfo   0x20000158       0x58 c:/program files (x86)/arm gnu toolchain arm-none-eabi/12.2 mpacbti-rel1/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc.a(libc_a-gettzinfo.o)
                0x200001b0                        . = ALIGN (0x4)
                0x200001b0                        _erelocate = .
                0x0047f228                        _firmware_end = (_etext + (_erelocate - _srelocate))
                0x0047f228                        _firmware_crc = _firmware_end
                0x00000001                        ASSERT (((_firmware_crc + 0x4) <= (ORIGIN (rom) + LENGTH (rom))), region ROM overflowed)

20000150	.data.uxCriticalNesting
                0x20000150        0x4 C:\Eclipse\Firmware\FreeRTOS\SAM4E\libFreeRTOS.a(port.o)



200048dc	 .bss.Wire      0x200048dc       0x20 ./src/Hardware/SAM4E/Devices.o


200049a5	 .bss._ZN6IoPort15logicalPinModesE
                0x200049a5       0xa6 ./src/Hardware/IoPorts.o
                0x200049a5                IoPort::logicalPinModes

I'm lost because the restarts are random and occur after a while, not at the first execution of a particular macro. I'm pretty sure that the error occured during filament loading, in the middle of a slow move to an endstop: G1 H4 V25 F300 in the macro 0:/sys/MMU Control/loadToBondtech.g

I've read all the topics about this error code and reason so I checked all the power terminals and they are are alright and the WIFi module knows about only one SSID..

Any ideas?

Good morning everyone!

First of all, I would like to apologize to you. This was not an issue with RRF but with my own code... Thank you all for your help and support!

Just in case, @gloomyandy and @AndyE3D you were right about M118 in every file in MMU Control. But I has no chance seeing something unusual until I used logging.
@dc42 I am sorry for tagging you here and wasting your time.. was my fault, not RRF's fault..

The problem was elsewhere, right at the beginning, in tpostn.g.
There, were three simple calls: load the filament in the MMU, then in the extruder and last in the nozzle. If during those macros any error raised, the tool change macro continued showing a dialog (M291). But, it can also call errorAction.g which by itself loads the filament all the way to the nozzle, but being called from a "while" loop in tpostn.g, after errorAction.g the while loop was trying to load it again to the MMU. The log confirmed that:

2023-08-02 12:02:28 [debug] Finish: loadToBondtech.g
2023-08-02 12:02:28 [debug] Begin: idlerMove.g
2023-08-02 12:02:28 [debug] Finish: idlerMove.g
2023-08-02 12:02:28 [debug] Begin: loadToNozzle.g
2023-08-02 12:02:28 [debug] Finish: loadToNozzle.g     < here the duex.e2stop is configured as a filament sensor
2023-08-02 12:02:28 [debug] Begin: loadToFinda.g     < here the duex.e2stop is used to load the filament in the MMU
2023-08-02 12:02:35 [warn] Error: Pin 'duex.e2stop' is not free
2023-08-02 12:02:35 [warn] Error: G1: Failed to enable endstops
2023-08-02 12:02:41 [info] Event logging stopped

In tpostn.g adding a break statement to exit the wile loop solved this problem

Thank you again to all of you for your support!

Good morning everyone
Since I got almost no answer, especially from devs, I have a simple question:

This issue, being a software issue (I assume that I opted to try the beta firmwares) is there any chance that updating the endstops pins configurations between deeply nested macros to be solved before the first release candidate of RRF3.5 becomes available?

No one..?

@AndyE3D said in M574 can't disable pin:

This error Error: G1: Failed to enable endstops can only occur with a G1 H1/3/4 command which is not present in loadToNozzle.g, which implies (at least part of) the issue is in some other macro

That error must come from load or unload to finda. That are only macros that uses exp.e2stop followed by a G1 H4 command. But the strange thing is that those macros behave as they should even with that error in place. Maybe that error cannot show up until any macros are executed, but even then, everything works as it should except for that error wich cancels any print