No Axis Movement
-
No action with the M564 S0 H0 in either config.g or homedelta g
-
no as i posted thats not allowed on a delta
-
I'll try it. Didn't realize those were links....
-
Movement! Not the correct movement, but all three axes moved From G92 X0 Y0 Z0 with the extruder at the bed, and centered.
-
@1d1 said in No Axis Movement:
M574 X2 Y2 Z2 S0 ; set active high endstops
Have you got active low (normally open, or NO), or active high endstops (normally closed, NC)? See https://duet3d.dozuki.com/Wiki/Connecting_endstop_switches#Section_Microswitch
If you send M117, and the endstop reports triggered already, it may explain lack of movement. Change S0 to S1.If you change anything in config.g, you need to reset the board, or send M98 P"config.g" to use those changes. Or input gcodes (temporarily, until the next reset) in the gcode console/command line.
Ian
-
I've verified the endstops as being NC (changed to S1) and both X and Y move normally. Z isn't moving at all and the endstops are not triggering the axis movements of X and Y. On the board, the endstop lights are on and go off when manually triggering each end stop switch. For M117, the endstops are not triggered until I push them and each one is registering on the proper tower.
I'm going to try Z on a different driver... -
OK. Z works fine on X driver, so I think the Z is bad. Can I run Z from E1 if I change the position in the config?
-
Can you post the results of M122 and send M98 P"config.g" and post any error messages that come up?
-
@1d1 said in No Axis Movement:
Can I run Z from E1 if I change the position in the config?
Yes, you'd change the M574 z to use the driver number you want.
-
-
Closer yet. All axis moving normally now with Z on E1 (4). But the endstops are still not stopping movement or triggering. Yes, I changed the z end stop to E1.
Here is M122:
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DGM-956GU-DJMSN-6JTDA-3S46Q-TUQHH
Used output buffers: 3 of 20 (8 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 95928 of which 16 recycled
Exception stack ram used: 276
Never used ram: 6472
Task NETWORK ready, free stack 324
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3592
=== Platform ===
Last reset 00:01:34 ago, cause: software
Last software reset at 2020-09-15 17:08, reason: User, spinning module GCodes, available RAM 6472 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 32.3, current 32.6, max 32.9
Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2020-09-15 17:09:43
Slowest loop: 4.79ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== 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 idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 72.51ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.21
WiFi MAC address 5c:cf:7f:76:71:a9
WiFi Vcc 3.29, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 13864
WiFi IP address 192.168.1.54
WiFi signal strength -44dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
and M98 "config.g"... nothing comes up
- WiFi -
-
Under machine properties:
X No -99 mm 99 mm 20 mm/s 300 mm/s 2000 mm/s² 800 mA
Y No -99 mm 99 mm 20 mm/s 300 mm/s 2000 mm/s² 800 mA
Z Yes 201 mm 200 mm 20 mm/s 300 mm/s 2000 mm/s² 800 mA
E0 Yes n/a n/a 10 mm/s 13.33 mm/s 2000 mm/s² 600 mAWhich can't be right...
-
The first thing I would suggest you do is update the firmware.
https://github.com/Duet3D/RepRapFirmware/releases/download/2.05.1/Duet2Firmware-2.05.1.zip
Download that zip file, then upload it as is to the /sys folder in DWC. That should prompt it to update everything.
-
Done. Nothing lost but nothing gained. Goes up on all axes, hits endstops and then bangs away until I hit Emergency Stop.
-
M115: FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.05.1 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2020-02-09b1
-
Alright, when you manually trigger the endstops do they register on the LED light on the Duet board?
What kind of endstops are they? Can you post a photo? How are they wired to the board? Does the status change if you send M119 before it's pressed compared to while it's depressed?
https://duet3d.dozuki.com/Wiki/Gcode#Section_M119_Get_Endstop_Status
-
@1d1 identify which motor is X, Y and Z (using G1 H2 X/Y/Z moves) then check that each endstop is connected on the correct axis (it sounds like you may have two swapped), and all are triggering. Despite moving Z to driver 4, the endstop should still be plugged into z endstop pins. Check triggering with
M117M119 or the endstop display in DWC.Ian
Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth
-
-
OK. Motors and endstops all correspond to their identified axes and are mounted in their proper spots. Each endstop light on the board is lit and goes off when manually triggered at the switch. The switches are just buttons pushing in and triggering when the carriage hits. Two wires, black and red, so, open or closed. Placing the Z connector back on the Z driver location gives a "no" when not triggered and" yes" when activated. They do not all trigger at once, only individually. They each behave properly when trying the M119 method as well as the machine properties read out in the UI.
-
The Z endstop should still be on the Z endstop connector even though the Z driver is now the E1 driver. RRF2 is pretty rigid about that.
At this point it's tempting to just upgrade you to RRF3.0 and then 3.1.1 and get a fresh config from the configurator for a delta and go from there.
Upload this zip: https://github.com/Duet3D/RepRapFirmware/releases/download/3.0/Duet2and3Firmware-3.0.zip
Then upload this zip: https://github.com/Duet3D/RepRapFirmware/releases/download/3.1.1/Duet2and3Firmware-3.1.1.zip
Then get a config set from here and upload the resulting zip file as well: https://configtool.reprapfirmware.org/General
