Job working from DWC but faulty when called from config.g

Yurk_12

Hi,

My gcode job describes a certain motion to drive 5 Nema 8 motors. The job is in the Jobs folder and it is run on startup thanks to a M32 filename.gcode added to config.g.

The following happened: during the job, 2 motors were mechanically stopped for about 30 min. The job was still executing. I turned off the board, fixed the mechanical part, and started again the board: the job is run but commands with low speed are not executed while commands with high speed are executed.

When I run the job by uploading it in DWC and starting it from DWC it still works as expected. It seems that calling the job from config.g or calling the job from DWC is different.

The job looks like below.
Lines #1,#2 are properly executed.
In line #3, only the X-200 is executed. The Y,Z,U,V-5.4 are not executed, and this only when the job is called from the config.g at startup. Diagnostics pasted below.

Any idea what is happening? In general also, how bad is it if a job is mechanically blocked for a long time with mechanically stopped motors?
Thanks a lot

G21 G91 
G1 X-200.0 Y-145.94594594594594 Z-91.89189189189189 U-37.83783783783784 F18500
G1 X-200.0 Y-5.405405 Z-5.405405 U-5.405405 F9250.0 
G1 X-200.0 Y-5.405405 Z-5.405405 U-5.405405 F9250.0 
G1 X-200.0 Y-5.405405 Z-5.405405 U-5.405405 F9250.0 
G1 X-5.405405 Y-5.405405 Z-5.405405 U-5.405405 F500.0 
G1 X-5.405405 Y-5.405405 Z-5.405405 U-5.405405 F500.0 
G1 X-5.405405 Y-5.405405 Z-5.405405 U-5.405405 F500.0

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.3 (2021-06-15 21:46:11) running on Duet 3 Mini5plus Ethernet (standalone mode)
Board ID: 5DNBA-B296U-D65J0-40KM6-2503Z-HSDTT
Used output buffers: 3 of 40 (13 max)
=== RTOS ===
Static ram: 102724
Dynamic ram: 99352 of which 296 recycled
Never used RAM 41332, free system stack 152 words
Tasks: NETWORK(ready,27.7%,240) ETHERNET(notifyWait,0.1%,574) HEAT(delaying,0.0%,415) Move(notifyWait,0.1%,300) CanReceiv(notifyWait,0.0%,941) CanSender(notifyWait,0.0%,371) CanClock(delaying,0.0%,340) TMC(notifyWait,0.7%,115) MAIN(running,70.2%,408) IDLE(ready,0.4%,29) AIN(delaying,0.8%,264), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:02:19 ago, cause: power up
Last software reset at 2021-08-04 21:08, reason: User, GCodes spinning, available RAM 41332, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 139750, completed 139748, timed out 0, errs 0
Step timer max interval 797
MCU temperature: min 24.6, current 31.0, max 31.0
Supply voltage: min 10.5, current 11.0, max 12.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position -203676, standstill, SG min/max 0/24, read errors 0, write errors 0, ifcnt 16, reads 7313, writes 16, timeouts 0, DMA errors 0
Driver 1: position -97297, standstill, SG min/max 0/102, read errors 0, write errors 0, ifcnt 16, reads 7313, writes 16, timeouts 0, DMA errors 0
Driver 2: position -84324, standstill, SG min/max 0/34, read errors 0, write errors 0, ifcnt 16, reads 7312, writes 16, timeouts 0, DMA errors 0
Driver 3: position -24649, standstill, SG min/max 0/88, read errors 0, write errors 0, ifcnt 16, reads 7312, writes 16, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 7320, writes 9, timeouts 0, DMA errors 0
Driver 5: position 0, assumed not present
Driver 6: position 0, assumed not present
Date/time: 2021-08-04 21:16:47
Cache data hit count 230021930
Slowest loop: 210.47ms; fastest: 0.11ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 3.7ms, write time 2.1ms, max retries 0
=== Move ===
DMs created 83, maxWait 19454ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 7, completed moves 7, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], 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 = -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Movement lock 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
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 699, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 17 (min 17), ts 699/0/0
Tx timeouts 0,0,698,0,0,0 last cancelled message type 30 dest 127

=== Network ===
Slowest loop: 1054.23ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- Ethernet -
State: active
Error counts: 0 0 0 0 0
Socket states: 5 2 2 2 2 0 0 0

fcwilt

@yurk_12

Doing anything like that from config.g seems like a very bad idea to me.

Why are you trying to do that?

Frederick

Phaedrux

What was the mechanical issue? Are you sure it's not still a mechanical issue? Like a loose grub screw maybe? Those are small motors, did they get burnt being locked in position while trying to move?

@fcwilt said in Job working from DWC but faulty when called from config.g:

Doing anything like that from config.g seems like a very bad idea to me.

For a printer that has pinch points, certainly, but I get the sense this maybe isn't a typical usage of a Duet.

Yurk_12

Thanks @fcwilt and @phaedrux.

Doing anything like that from config.g seems like a very bad idea to me.

but I get the sense this maybe isn't a typical usage of a Duet.

It is not a 3D printer. I am actuating motors to achieve a certain function in a mechanical assembly.

Why are you trying to do that?

For a very easy user experience. The user starts the power of the assembly and the desired motion is executed.

What was the mechanical issue?

2 motors were mechanically stuck into one position. No rotation possible during the 30 min of blocking.

Are you sure it's not still a mechanical issue? Like a loose grub screw maybe?

I am sure the mechanical issue has been fixed. The job now works normally when called from DWC. I'm switching back and forth between calling the job from DWC and from config.g and it alternately works and fails.

Those are small motors, did they get burnt being locked in position while trying to move?

Maybe, but everything works as expected when calling the job from DWC.

Job called from DWC: success
Job called from config.g and ethernet cable connected to computer: fail
Job called from config.g and no cable plugged: fail

fcwilt

@yurk_12

Thanks for the info.

It didn't sound like you were talking about a printer.

Just the same the idea of having mechanical motion on power up doesn't seem like a good idea.

A short power outage will lead to possibly unexpected activity.

Hope you get things sorted.

Good luck.

Frederick

Phaedrux

@yurk_12 said in Job working from DWC but faulty when called from config.g:

Job called from DWC: success
Job called from config.g and ethernet cable connected to computer: fail
Job called from config.g and no cable plugged: fail

Can you try adding a delay in your config.g of a few seconds with G4 S4 right before your job is called and move the job call to the end of the file and see if it makes a difference.

Could you share your config.g?

Yurk_12

Thanks @fcwilt.

the idea of having mechanical motion on power up doesn't seem like a good idea

I see your point, but I'd argue that systems that start upon powering up are ubiquitous (a simple room fan starts blowing whenever you turn it on).

Thanks @phaedrux.

Can you try adding a delay in your config.g of a few seconds with G4 S4 right before your job is called and move the job call to the end of the file and see if it makes a difference.

Ah yes, good point. A main difference between running from config and from DWC is the time the board is ON since startup, I should have thought of that. It is now working as expected, I will keep this 4 seconds delay then. The board must go through some initializations at startup I assume.

Could you share your config.g?

Sure, nothing fancy here though I believe.

Thanks a lot for your prompt help

; Configuration file for Duet 3 Mini 5+ (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.3.0 on Tue Aug 03 2021 20:00:32 GMT-0400 (Eastern Daylight Time)

; General preferences
G91                                              ; send absolute coordinates...
M550 P"Tests_v0"                                 ; set printer name

; Network
M552 P169.254.163.66 S1                          ; enable network and acquire dynamic address via DHCP
M586 P0 S1                                       ; enable HTTP
M586 P1 S0                                       ; disable FTP
M586 P2 S0                                       ; disable Telnet

; Drives
M569 P0.0 S0                                     ; physical drive 0.0 goes forwards
M569 P0.1 S0                                     ; physical drive 0.1 goes forwards
M569 P0.2 S0                                     ; physical drive 0.2 goes forwards
M569 P0.3 S0                                     ; physical drive 0.3 goes forwards
M569 P0.4 S1                                     ; physical drive 0.4 goes forwards
M584 X0.0 Y0.1 Z0.2 U0.3 V0.4                    ; set drive mapping
M350 X16 Y16 Z16 U16 V16 I1                      ; configure microstepping with interpolation
M92 X80.00 Y80.00 Z80.00 U80.00 V80.00           ; set steps per mm
M566 X90000.00 Y90000.00 Z90000.00 U90000.00 V90000.00      ; set maximum instantaneous speed changes (mm/min)
M203 X60000.00 Y60000.00 Z60000.00 U60000.00 V60000.00 ; set maximum speeds (mm/min)
M201 X5000.00 Y5000.00 Z5000.00 U5000.00 V5000.00      ; set accelerations (mm/s^2)
M906 X600 Y600 Z600 U600 V600 I30                 ; set motor currents (mA) and motor idle factor in per cent
M84 S30                                          ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z0 U0 V0 S1                                 ; set axis minima
M208 X999999 Y999999 Z999999 U999999 V999999 S0                  ; set axis maxima

; Endstops
; WARNING: No endstops configured

; Heaters
M140 H-1                                         ; disable heated bed (overrides default heater mapping)

; Fans

; Tools

; Custom settings are not defined

M564 S0 H0
M220 S0

;M669 K0 X1:0:0:0:0 Y0:1:0:0:0 Z0:0:1:0:0 U0:0:0:1:0 V0:0:0:0:1
G4 S4
M32 duet_test.gcode

Phaedrux

@yurk_12 said in Job working from DWC but faulty when called from config.g:

I will keep this 4 seconds delay then.

I don't know if it matters for your application but you may be able to reduce that time with a bit of experimentation.

Glad that worked out though. Also I'm not sure why the behaviour would change after the mechanical issue.