How to get DWC to Display what line of Gcode it is on?

Tinman

I was able to run M122 where it stopped. Any thoughts on this?

4/9/2023, 3:29:57 PM M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5beta2 (2023-02-08 17:43:01) running on Duet 3 MB6HC v1.01 (standalone mode)
Board ID: 08DJM-956L2-G43S4-6J9FA-3SJ6J-1B6QG
Used output buffers: 1 of 40 (37 max)
=== RTOS ===
Static ram: 154344
Dynamic ram: 119692 of which 0 recycled
Never used RAM 68364, free system stack 154 words
Tasks: NETWORK(ready,33.2%,194) ETHERNET(notifyWait,0.2%,401) HEAT(notifyWait,0.0%,355) Move(notifyWait,0.2%,239) CanReceiv(notifyWait,0.0%,943) CanSender(notifyWait,0.0%,335) CanClock(delaying,0.0%,334) TMC(notifyWait,8.3%,56) MAIN(running,58.1%,446) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:33:12 ago, cause: power up
Last software reset details not available
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 220
MCU temperature: min 34.9, current 35.1, max 35.6
Supply voltage: min 23.7, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/1860/1832, gc cycles 2
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 968, reads 59035, writes 11 timeouts 0
Driver 1: standstill, SG min 0, mspos 824, reads 59034, writes 11 timeouts 0
Driver 2: standstill, SG min 0, mspos 536, reads 59034, writes 11 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 59045, writes 0 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 59045, writes 0 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 59045, writes 0 timeouts 0
Date/time: 2023-04-09 15:29:56
Slowest loop: 241.56ms; fastest: 0.04ms
=== Storage ===
Free file entries: 18
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 1.2ms, write time 13.3ms, max retries 0
=== Move ===
DMs created 125, segments created 9, maxWait 1342009ms, bed compensation in use: none, comp offset 0.000
next step interrupt due in 285840 ticks, disabled
=== DDARing 0 ===
Scheduled moves 1160, completed 1155, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 16], CDDA state 3
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, File2
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X-6.962 Y2" 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
File2 is doing "M0" in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 1, axes/extruders owned 0x0000007
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 6962, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 6962/0/0
Tx timeouts 0,0,6962,0,0,0 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 227.78ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 2 of 8
= Ethernet =
State: active
Error counts: 0 0 0 0 0 0
Socket states: 5 2 2 2 2 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0

gloomyandy

@Tinman Doesn't look like the firmware has crashed, but for some reason it seems to be stuck trying to process this line:

File is doing "G1 X-6.962 Y2"

Given this line:

Scheduled moves 1160, completed 1155, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 16], CDDA state 3

The problem may be a little bit before the above line, as it looks like for some reason the firmware has not been able to complete all of the scheduled moves. Not really sure why. It would probably help if you can reduce things down to as simple as possible gcode file.

Tinman

@gloomyandy Thanks for looking at this with me. Just ran the file again. It failed in a similar manner but not on exactly the same line.

4/9/2023, 4:07:37 PM M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5beta2 (2023-02-08 17:43:01) running on Duet 3 MB6HC v1.01 (standalone mode)
Board ID: 08DJM-956L2-G43S4-6J9FA-3SJ6J-1B6QG
Used output buffers: 5 of 40 (36 max)
=== RTOS ===
Static ram: 154344
Dynamic ram: 119692 of which 0 recycled
Never used RAM 68364, free system stack 141 words
Tasks: NETWORK(ready,34.2%,194) ETHERNET(notifyWait,0.2%,423) HEAT(notifyWait,0.0%,357) Move(notifyWait,0.3%,239) CanReceiv(notifyWait,0.0%,943) CanSender(notifyWait,0.0%,335) CanClock(delaying,0.0%,334) TMC(notifyWait,8.6%,56) MAIN(running,56.7%,446) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:13:10 ago, cause: power up
Last software reset details not available
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 220
MCU temperature: min 28.3, current 35.4, max 35.7
Supply voltage: min 23.7, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.0, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/528/500, gc cycles 3
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 376, reads 43089, writes 29 timeouts 0
Driver 1: standstill, SG min 0, mspos 984, reads 43092, writes 29 timeouts 0
Driver 2: standstill, SG min 0, mspos 472, reads 43092, writes 29 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 43110, writes 11 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 43110, writes 11 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 43110, writes 11 timeouts 0
Date/time: 2023-04-09 16:07:37
Slowest loop: 242.52ms; fastest: 0.04ms
=== Storage ===
Free file entries: 18
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 0.7ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 9, maxWait 112639ms, bed compensation in use: none, comp offset 0.000
next step interrupt due in 266136 ticks, disabled
=== DDARing 0 ===
Scheduled moves 1130, completed 1127, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 12], CDDA state 3
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, File2
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X5.984 Y2.15" 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
File2 is doing "M0" in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 1, axes/extruders owned 0x0000007
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 3951, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 3951/0/0
Tx timeouts 0,0,3950,0,0,0 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 226.08ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(2) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 2 of 8
= Ethernet =
State: active
Error counts: 0 0 0 1 0 0
Socket states: 5 3 2 2 2 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0
4/9/2023, 4:06:00 PM Stopped at height 47.713 mm
Tool Offset c is Z47.713
Final Tool Offset is Z47.70417
This macro sees global var and the difference between Workpiece Surface and Sexbolt is: -10.2158318m
4/9/2023, 4:05:56 PM Stopped at height 47.693 mm
Tool Offset b is Z47.693
4/9/2023, 4:05:51 PM Stopped at height 47.708 mm
Tool Offset a is Z47.708
4/9/2023, 4:05:48 PM Stopped at height 47.684 mm
4/9/2023, 4:05:21 PM M32 "0:/gcodes/Left Brake Threaded Side v3.nc"
File 0:/gcodes/Left Brake Threaded Side v3.nc selected for printing
4/9/2023, 4:02:42 PM Stopped at height 47.732 mm
Tool Offset c is Z47.732
Final Tool Offset is Z47.72500
This macro sees global var and the difference between Workpiece Surface and Sexbolt is: -10.2158318m
4/9/2023, 4:02:38 PM Stopped at height 47.728 mm
Tool Offset b is Z47.728
4/9/2023, 4:02:34 PM Stopped at height 47.715 mm
Tool Offset a is Z47.715
4/9/2023, 4:02:31 PM Stopped at height 47.702 mm

Tinman

@gloomyandy Something I noticed is it is milling at Z-4 and then suddenly the machine freezes and simultaneously DWC displays Z0.886 which is not accurate- it's still at Z-4 position.

gloomyandy

@Tinman As I said I think the next step is to try and get a small reproducible case that DC42 can take a look at. Ideally you want a very simple config.g file and a short gcode file.

Tinman

@gloomyandy will do

Tinman

@gloomyandy

Here’s a video of the behaviour

https://youtu.be/7BHlPzQdbNg

Tinman

@gloomyandy The problem goes away if I separate the toolpath steps. I've been working hard to enable toolchanges etc so that I can put in a workpiece, run the file and get a finished part. Having to run 8 separate files to mill a part is not ideal.

Tinman

@gloomyandy You may find it interesting that I can take a file that consistently fails at around 2% of completion, delete the last 90% of the file so that the part where it fails is still intact, re-run the file and it sails right past the place it failed before.

Are there issues related to file size when doing CNC files?

dc42

@Tinman I see you are running firmware 3.5beta2. Please upgrade to 3.5beta3 and see whether the issue still occurs.

Tinman

@dc42 Thanks for looking into this. I have just upgraded to beta 3 and still having this problem. I'd be happy to send you a file to look at.

Tinman

@Tinman Until then I need to break CNC jobs into 4 to 8 multiple parts to get the machine to run them without needing to do a hard reset. Problem with a hard reset is that it results in the loss of WCS which is almost always probed on a surface that has now been milled away.

dc42

@Tinman I think the issue may be related to the multiple motion systems in RRF 3.5 and the code in your stop.g file. Does the problem go away if you remove the M0 command from the end of the job file? What commands do you have in stop.g?

Tinman

@dc42 I opened this topic because I wanted to be able to run a full job with multiple toolchanges from a single gcode file. Perhaps I will start a separate thread about recovering WCS from an e-stop.

For now though, would you take a look at one of my multi toolchange files that fails on beta 2 and beta 3?

dc42

@Tinman as I said in my previous post, I think the issue is related to the contents of your stop.g file. So I need to see the contents of that file.

I can think of a way to save and restore the WCS offsets, so please start a separate thread on that topic.

Tinman

@dc42 There's not a single line of active code in my stop.g just a few disabled lines:

; stop.g
; called when M0 (Stop) is run (e.g. when a print from SD card is cancelled)
;
; generated by RepRapFirmware Configuration Tool v3.3.15 on Thu Dec 01 2022 17:27:42 GMT-0500 (Eastern Standard Time)

dc42

@Tinman thanks. Please make the file available. I am away from the office so I won't be able to try it for a few days.

Tinman

@dc42 I had to change extension from .nc to .gc for site to allow upload.

Thanks again for looking at this. It gets about halfway through the initial face milling process before it freezes. Roughly (very roughly) around line 500.

Axle Insert Flat Side Complete Job.gc

Tinman

@dc42 The behaviour of this file is even more troubling:

Tall Axle Insert Whole Job.gc

The Z axis randomly climbed by about 70mm during the facing operation and then froze. There is nothing unusual in that section of the file. This kind of behaviour is dangerous in a cnc machine. The latest RRF updates have been great however as our mill becomes more mature and our users want to run real jobs this is going to be a serious obstacle.

OwenD

@Tinman
Based on @dc42's comments above about the problem possibly being related to the multiple motion systems have you tried

Removing M0 from the file (if a second motion system is getting ahead it may be stopping the job)
If the above is true, it may also turn off the spindle when it reaches M5, so maybe remove as well
Liberally sprinkle M400 in the code (say every 100 lines). Do this especially before your tool change.

Can't explain the lifting by 70mm unless that was part of another file that's activated by M0, Tnnn or a trigger

What's in "ManualToolChange.g" ?