Duet 3 endstops do not working properly
-
are you on firmware 3.1.1?
are you sure you did not get x and y switched?
-
3.2 beta 4
I tried swapping the endstops and still had the same issue.
-
just to be sure, post the output of M119 once without and once with pressing the x endstop
-
m119
Endstops - X: not stopped, Y: not stopped, Z: no endstop, Z probe: not stoppedm119
Endstops - X: at min stop, Y: at min stop, Z: no endstop, Z probe: not stopped -
I also checked and y is y and x is x.
-
it looks ok.
and you are pressing single home actions instead of homeall? as you did not post the homeall.
-
Whoops no I'm doing home all.
M98 P"homex.g"
M98 P"homey.g"
M98 P"homez.g" -
Can you send M98 P"config.g" and report any errors?
Can you send M122 and report the results?
Your homeall calling the other macros is fine.
Something seems amiss though. The endstops are showing as getting triggered when pressed but not stopping homing.
Are you editing the files in the system tab in DWC?
You're sure the X endstop is physically wired to io1.in?
What type of endstop switch is it?
-
I will get you what I can when my bed PID tune is done for some reason it is going on 2 hours now, but it finally seems to be at the last step I hope.
-
-
@Vampora said in Duet 3 endstops do not working properly:
I will get you what I can when my bed PID tune is done for some reason it is going on 2 hours now, but it finally seems to be at the last step I hope.
This would be due to using 3.2 beta 4 and the new tuning algorithm. Do you intend to be doing beta testing? If this is a new build I might suggest sticking to 3.1.1.
-
Never mind I'll just do it. The tuning failed anyways.
The endstop switch is one of these little guys.
https://www.amazon.com/gp/product/B07167R6D1/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
As far as beta I normally do it just to play around. I normally don't have issues honestly. I had issues with the 3.1.1 firmware not installing properly for whatever reason and ended up getting the beta loaded on easy peasy. It has been a long couple of days.
M98 P"config.g"
Error: M550: Machine name must consist of the same letters and digits as configured by the Linux hostnamem122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2-beta4 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6JTD0-3SS6J-1V92V
Used output buffers: 1 of 40 (11 max)
=== RTOS ===
Static ram: 123212
Dynamic ram: 138480 of which 88 recycled
Never used RAM 130412, free system stack 178 words
Tasks: Linux(ready,53) HEAT(blocked,189) CanReceiv(blocked,947) CanSender(blocked,371) CanClock(blocked,352) TMC(blocked,54) MAIN(running,1179) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 02:23:25 ago, cause: software
Last software reset at 2020-11-29 12:32, reason: User, none spinning, available RAM 130476, slot 0
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0xffffffff Task Linu
Error status: 0x00
MCU temperature: min 36.7, current 37.6, max 41.9
Supply voltage: min 24.1, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Driver 0: position 0, standstill, reads 9094, writes 17 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 9094, writes 17 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 9101, writes 11 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 9096, writes 17 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 9097, writes 17 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 9103, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2020-11-29 14:56:09
Slowest loop: 69.54ms; fastest: 0.10ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" 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.
=== Filament sensors ===
Extruder 0 sensor: no data received
=== CAN ===
Messages queued 34390, send timeouts 0, received 14, lost 0, longest wait 1ms for reply type 6018, free buffers 47
=== SBC interface ===
State: 0, failed transfers: 0
Last transfer: 19ms ago
RX/TX seq numbers: 40224/40225
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x20a28
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta4
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 35.17 -
Oh wow.... im sorry for wasting all of your time. I figured it out.
My Y motor was turning the wrong direction. i needed to have the X reversed and the Y forward. It looked just like it should have when homing normally, so i didn't question it.
