Trouble homing

[beikeland]

Firstly this is likely to be several issues, but I'm getting nowhere with isolating any one of the problems.

When homing, X axis will randomly terminate the G1 H1 move, as if it hit the endstop. But it will also reliably work if it reaches the inductive endstop. Initially I thought it coincided with one of the other axes hitting their endstop causing X to also stop, but the behavior persist when homing one axis at the time in homeall.g

After homing X, it will most often get the M208 value, but occasionally a higher number, seemingly only if it did not home properly.

DuetWebControl will hang after 5-10 cycles of homing, jogging and homing again. I.e the home button has a spinning indicator that nevers goes away. Restarting DuetControlServer and reloading the page seems to get it going again.

info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]
      Executing action method DuetWebServer.Controllers.MachineController.DoCode (DuetWebServer) - Validation state: Valid
info: DuetWebServer.Controllers.MachineController[0]
      [DoCode] Executing code 'G28 X'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://10.10.0.193/js/app.492b2e82.js.map
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/js/app.492b2e82.js.map'. Physical path: '/opt/dsf/sd/www/js/app.492b2e82.js.map'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 6568.5538ms 200 text/plain
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[2]
      Executed action method DuetWebServer.Controllers.MachineController.Get (DuetWebServer), returned result Microsoft.AspNetCore.Mvc.EmptyResult in 356428.1503ms.
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[2]
      Executed action method DuetWebServer.Controllers.MachineController.Get (DuetWebServer), returned result Microsoft.AspNetCore.Mvc.EmptyResult in 2968344.1988ms.
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[2]
      Executed action DuetWebServer.Controllers.MachineController.Get (DuetWebServer) in 2968345.7494ms
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
      Executed endpoint 'DuetWebServer.Controllers.MachineController.Get (DuetWebServer)'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 2968360.1028ms 101
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[2]
      Executed action DuetWebServer.Controllers.MachineController.Get (DuetWebServer) in 356430.4367ms
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
      Executed endpoint 'DuetWebServer.Controllers.MachineController.Get (DuetWebServer)'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 356440.4761ms 101

[info] Sent G28 X"", remaining space 484 (996 total), needed 28
[info] Executing nested macro file '/opt/dsf/sd/sys/homex.g' on channel HTTP
[info] Sent G91 ; relative positioning, remaining space 492 (1004 total), needed 20
[info] Sent G1 H1 X3000 F1000 ;fast home x, remaining space 448 (960 total), needed 44
[info] Sent G1 X-1 F1000 ;move off endstops, remaining space 412 (924 total), needed 36
[info] Sent G1 H1 X10 F100, remaining space 368 (880 total), needed 44
[info] Sent G90 ; absolute positioning, remaining space 348 (860 total), needed 20
[info] Completed G91 ; relative positioning
[info] Completed G1 H1 X3000 F1000 ;fast home x
[info] Completed G1 X-1 F1000 ;move off endstops

; config.g
M584 X5 Y1 Z2           ;driver 0 is toast, move X to 5(test whole chain)
;M569 P0 D3 V4000       ;toast
M569 P1 S1 D3 V4000     ;Y
M569 P2 S0 D3 V4000     ;Z
M569 P5 S1 D3 V4000     ;X

M208 X200 Y200 Z90      ;work area
M350 X16 Y16 Z16 I1     ;microsteps w/interpolation
M92 X640 Y640 Z1280     ;steps/mm
M906 X1000 Y1000 Z1000  ;current limits
M201 X200 Y200 Z100     ;acceleration mm/sec^2 (or M204?)
M203 X2000 Y2000 Z1000  ;max feed rate mm/min
M205 X50 Y50 Z25        ;jerk mm/sec

M574 X2 S1 P"io0.in"    ; pnp no x max
M574 Y1 S1 P"io1.in"    ; pnp no y min
M574 Z2 S1 P"io2.in"    ; pnp no z max

; homeall.g
G91
;G1 H1 X3000 Y-4000 Z900 F1500;doesn't work?!
G1 H1 Z900 F1000              ;fast home z
G1 H1 X3000 F1000             ;fast home x
G1 H1 Y-4000 F1000            ;fast home y
G1 H2 X-1 Y1 Z-1 F1000        ;move off endstops
;G1 H1 X10 Y-10 Z10 F100       ;accurately home x/y/z
G1 H1 X10 F100
G1 H1 Y-10 F100
G1 H1 Z10 F100       ;accurately home x/y/z
G90

[chrishamm]

Can you check if the problem persists with the latest DSF version? My RRF build can be found here as usual: https://chrishamm.io/Duet3Firmware.bin

[beikeland]

Seems to persist. Updated. Homed (with the machine already being at the home possition). Jogged the axis a bit and re-homed.

X stops some before hitting the endstop, and the axis is homed at X=209 which is outside the defined work area. (I.e. even if the premature stop is hardware related that I fail to spot with the scope, there are gremlins in the code somewhere)

Configs remain as above.

duetcontrolserver=1.0.3.1 duetwebcontrol=2.0.0-3 duet3_firmware=3.0b7-ch@2019-08-07b2

[chrishamm]

Hmm, strange. I tried to reproduce it on my setup but without success so far. I don't have any inductive endstops, though. Can you share your config file and post the output of M122 when it happens again?

[beikeland]

I doubt its purely related to the inductive endstops, that wouldn't end up with a X position different than the M208 config? I can't get the scope to trigger on the endstop signal when the axis stop, and M119 shows the endstop not triggered.

X = 209.0 incorrect Y = 0.0 correct Z = 90.00 correct. M208

Axis limits X0.0:200.0, Y0.0:200.0, Z0.0:90.0

M119

Endstops - X: not stopped, Y: at min stop, Z: at max stop, Z probe: at min stop

M122

=== Diagnostics ===
RepRapFirmware for Duet 3 v0.5 version 3.0b7-ch running on Duet 3 prototype v0.5
Board ID: 08DGM-9T66A-G63SJ-6JKD8-3SD6P-KV0BA
Used output buffers: 1 of 32 (5 max)
=== RTOS ===
Static ram: 65620
Dynamic ram: 132300 of which 24 recycled
Exception stack ram used: 568
Never used ram: 194704
Tasks: NETWORK(ready,2036) HEAT(blocked,1436) CanClock(blocked,1472) CanSender(suspended,1420) TMC(blocked,456) MAIN(running,4512) IDLE(ready,196)
Owned mutexes:
=== Platform ===
Last reset 71:39:21 ago, cause: power up
Last software reset time unknown, reason: Unknown, spinning module Platform, available RAM 199404 bytes (slot 3)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04429000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
Error status: 0
MCU temperature: min 20.3, current 41.0, max 42.3
Supply voltage: min 23.3, current 23.8, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, reads 33794, writes 11 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 33788, writes 19 timeouts 0, SG min/max 0/167
Driver 2: standstill, reads 33789, writes 19 timeouts 0, SG min/max 0/765
Driver 3: standstill, reads 33798, writes 11 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 33799, writes 11 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 33792, writes 19 timeouts 0, SG min/max 0/202
Date/time: 2019-08-12 13:17:43
Slowest loop: 29.94ms; fastest: 0.19ms
=== Move ===
Hiccups: 0, FreeDm: 375, MinFreeDm: 372, MaxWait: 257872608ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 17, completed moves: 17, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon* is ready with "M122" in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
spi is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.74ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8
- Ethernet -
State: 0
Socket states: 0 0 0 0 0 0 0 0
=== Linux interface ===
State: 1, failed transfers: 0
Last transfer: 92ms ago
RX/TX seq numbers: 37695/37695
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v1.0.3.1
Code buffer space: 2048
Configured SPI speed: 1000000 Hz
Full transfers per second: 22.22

;config.g
M584 X5 Y1 Z2           ;driver 0 is toast, move X to 5(test whole chain)
;M569 P0 D3 V4000       ;toast
M569 P1 S1 D3 V4000     ;Y
M569 P2 S0 D3 V4000     ;Z
M569 P5 S1 D3 V4000     ;X

M208 X200 Y200 Z90      ;work area
M350 X16 Y16 Z16 I1     ;microsteps w/interpolation
M92 X640 Y640 Z1280     ;steps/mm
M906 X1000 Y1000 Z1000  ;current limits
M201 X200 Y200 Z100     ;acceleration mm/sec^2 (or M204?)
M203 X2000 Y2000 Z1000  ;max feed rate mm/min
M205 X50 Y50 Z25        ;jerk mm/sec

M574 X2 S1 P"io0.in"    ; pnp no x max
M574 Y1 S1 P"io1.in"    ; pnp no y min
M574 Z2 S1 P"io2.in"    ; pnp no z max

;M564 S0 H0             ;override homing

; homeall.g
G91
;G1 H1 X3000 Y-4000 Z900 F1500 ;doesn't work?!
G1 H1 Z900 F1000              ;fast home z
G1 H1 X3000 F1000             ;fast home x
G1 H1 Y-4000 F1000            ;fast home y
G1 H2 X-1 Y1 Z-1 F1000        ;move off endstops
;G1 H1 X10 Y-10 Z10 F100       ;accurately home x/y/z
G1 H1 X10 F100
G1 H1 Y-10 F100
G1 H1 Z10 F100       ;accurately home x/y/z
G90

[dc42]

PNP inductive endstops are a bad choice. NPN ones would be much more suitable. PNP ones might work if you add a pulldown resistor between the endstop input and ground.

[beikeland]

Fair enough, I have since learned that NPN would be preferable, and they've been sat in a box pending adapters to be made for longer than i'd care to admit. Endstops all have the same value pull down to ground, and Y and Z have not shown any signs of trouble with the Duet. On X I can't spot a rising edge when the axis stop incorrectly with the scope, and all three worked for years with the Gecko G540.

And even if it was a hardware issue causing a signal only the Duet sees it should set X=200 and not X=209 as it does when it gets it wrong, so there is something fishy going on. It homes X=200 when it gets it right. Re-homing after it stops incorrectly makes it home correctly, to the endstop, and to X=200.

I'll work through the combinations of available input and stepper drivers to see if any combination that has less gremlins

On Mon, Aug 12, 2019 at 4:37 PM dc42 notifications@github.com wrote:

PNP inductive endstops are a bad choice. NPN ones would be much more suitable. PNP ones might work if you add a pulldown resistor between the endstop input and ground.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/chrishamm/DuetSoftwareFramework/issues/42?email_source=notifications&email_token=AAUTS3SQPISWSIO2ZYBX64LQEFYTRA5CNFSM4IHRPYPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4CXQXI#issuecomment-520452189, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUTS3QCZYMAZ6OCDXTBBPDQEFYTRANCNFSM4IHRPYPA .

[dc42]

What value pulldown resistors are you using?

[beikeland]

I'd wager 10k, but will have to check later in the week, away for a few days. I seem to recall around 10us fall time and 200us rise time with 24v.

On Mon, Aug 12, 2019 at 10:35 PM dc42 notifications@github.com wrote:

What value pulldown resistors are you using?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/chrishamm/DuetSoftwareFramework/issues/42?email_source=notifications&email_token=AAUTS3TMBK67XHSUWERH2Q3QEHCQZA5CNFSM4IHRPYPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4DX3AI#issuecomment-520584577, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUTS3USUV56R5B3MBKXAYDQEHCQZANCNFSM4IHRPYPA .

[dc42]

10K would be marginal because the Duet3 uses a 27K pullup resistor to +3.3V. Try 2k2 or 4K7.

[beikeland]

Sure I'll try, but a weak pulldown shouldn't cause the axis to be homed to a value greater than the max travel defined in M208 when incorrectly triggering prematurely?

I think I used 2v for the trigger on the scope and it only triggers when the axis hits the endstop, odd stuff.

On Mon, Aug 12, 2019 at 10:46 PM dc42 notifications@github.com wrote:

10K would be marginal. Try 2k2 or 4K7.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/chrishamm/DuetSoftwareFramework/issues/42?email_source=notifications&email_token=AAUTS3SOT2IEEBBJYOLWGR3QEHD3JA5CNFSM4IHRPYPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4DY3JA#issuecomment-520588708, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUTS3QMEQQPJWAFQXVJ77TQEHD3JANCNFSM4IHRPYPA .

[dc42]

Correct, if homing succeeds then the axis position should be set from the corresponding M208 limit. However, if your homing file has the usual fast-backoff-slow homing commands, then it could be that the fast homing command succeeded but the slow one didn't, leaving the axis beyond the homing position. I can't say more without seeing your homing file.

[beikeland]

in the top post, and at the bottom this comment https://github.com/chrishamm/DuetSoftwareFramework/issues/42#issuecomment-520404218

(The work area is actually bigger than config.g indicates, should be just shy of 300x400, g1 moves in homeall.g are 10x longer than needed for desperate measures, will change to more sensible values as progress is made)

[beikeland]

Was 10k. 2k2 didn't seem to make a difference. Seems to work on all of the remaining inputs however. Guess I'm supergluing an empty dupont header on io0 input and move on.