CNC Duet 3 DWC Homing button error.
-
homeall.g and g28 x doesn't do the same thing, homeall.g and g28 does.
can you run your homex.g macro without errors?
-
Just ran homex.g macro from the all axes homed position, homex.g ran without error and axis re-homed.
-
@Max3D so what did you do differently than your earlier post at 07:10? as what failed that time seems to have worked this time
-
To try and simplify this... First time I used the Home all button and the homeall.g. Then I used the Home X button followed by the homex.g.
Every time I used the DWC buttons I receive the G28 error dialog box in the lower right of the browser screen with no machine movement.
Every time I use the macros (anyone) the axis homes and the status of the DWC buttons change from yellow to blue or stay blue.
-
Maybe this can help. I recently had to erase the firmware and flash from the RaspPi (mod 4 8gig) with bossac because the new Duet 3 board had some kind of early release bug that would execute the comments in the config,g as code and would not allow the sudo apt get update/upgrade to alter the firmware (currently running latest release downloaded in the last 10 days). I am running the CNC's DWC with monitor and input devices directly connected to the Pi, and not from any laptop connected to my home network.
-
Can you send M122 in the gcode console and post the results here?
Also please check the version of DWC from the settings tab.
Firmware and DWC should both be at 3.1.1
G28 = homeall.g = home all button in dwc
G28 x = homex.g = home x button in dwc
etc, etcWhen you click the button in the DWC it marks the axis as unhommed and then tries to execute the commands in the macro to rehome. If it fails to do that for some reason you get left with an unhomed axis.
-
As I stated in my last reply. I did a sudo apt get update & upgrade from the RaspPi within the last 10 days. This is a new build. The board had a known firmware bug (beta release 12 or something to that affect) from what I have read here in the forum. The board would not detect the endstops when powered by usb during initial setup either, so I erased the board and then did flashed it with the RaspPi. DWC is at 3.1.1. and below are the diags from the M122. IF the board is glitchy then I need to have it replaced. I can't lose any more time on a bad board...
03/09/2020, 12:44:42 Connected to duet3
03/09/2020, 12:45:08 M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DJM-956L2-G43S8-6JTDA-3SJ6T-1B0AH
Used output buffers: 1 of 40 (11 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 161808 of which 52 recycled
Exception stack ram used: 224
Never used ram: 76528
Tasks: NETWORK(ready,1972) HEAT(blocked,1416) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1452) TMC(blocked,204) MAIN(running,5056) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:01:27 ago, cause: power up
Last software reset at 2020-09-02 22:57, reason: User, spinning module LinuxInterface, available RAM 76528 bytes (slot 3)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 25.8, current 33.5, max 33.6
Supply voltage: min 19.5, current 24.1, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Driver 0: standstill, reads 35617, writes 14 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 35617, writes 14 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 35617, writes 14 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 35618, writes 14 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 35621, writes 11 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 35622, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2020-09-03 12:45:07
Slowest loop: 4.42ms; fastest: 0.14ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.5ms, 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 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = -1 -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 ready with "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.
=== Network ===
Slowest loop: 0.97ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 0, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 16ms ago
RX/TX seq numbers: 1822/1823
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 0.04
- Ethernet -
-
Please bare with us while we troubleshoot your issue. If we send you a new board, but the problem is in the configuration, we didn't save you any time at all, because no problem was solved.
Now I'm having some difficulty understanding the issue exactly.
You say the endstops are working fine, but trying to home produces an error. How have you verified that the endstops are working if you can't home?
If you go to the machine specific settings tab in DWC where the endstop status is displayed, does the status change when you manually trigger the endstops by hand?
We need to verify that the endstop config is correct.
; Endstops M574 X2 S1 P"!^io0.in" ; configure active-high endstop for high end on X via pin !^io0.in M574 Y1 S1 P"!^io1.in" ; configure active-high endstop for low end on Y via pin !^io1.in M574 Z2 S1 P"!^io2.in" ; configure active-high endstop for high end on Z via pin !^io2.inWhen you send G28 (or push the home all button in DWC) how much movement do you get? At what point does the error occur?
Also, can you send M98 P"config.g" in the console and report the results here?
-
I am able to home using the macros, All, X, Y, and Z. The steppers start pushing the axes and the homing code executes the bump and rebump in beautiful harmony. When I use the macros the DWC's homing buttons turn from yellow to blue (all is well and dandy).
I can move the spindle around the bed with the buttons on the DWC's dashboard in the "Machine Movement" section using the "(x,y,z)+/-50" on all axes. I can test the soft limits on the axis and will receive an error when I try to go beyond the config.g settings (X=500 Y=400 and Z+70).
Using the macros, I can home an individual axis and then rehome without failure or any error code. When all the axes are homed I can see all the limit switches are lit with a red LED indicating they are triggered. I can go to the "machine specific" section of the DWC and verify that the endstops are triggered. Using the macros, I can rehome all day long without an error and each time the axes will do that beautiful bump and rebump, endstops lit up.
BUT, whenever I try to use the DWC homing buttons (whether they are yellow or blue), I get the cute little pink dialog box with the dreaded "G28 Error: Homing failed" and the button turns yellow; not a peep out of the steppers. I go to the top of the dashboard page and type G28 and hit the send button and I get the same cute little G28 Error: Homing failed; steppers idling. It does not matter which DWC button (or G28 I send from the console) I use, the only thing that happens is the error dialog box (All = G28 Error:, X=G28 X Error:, Y=G28 Y Error:, Z=G28 Z Error:) and the button turns yellow. It is consistent no matter how many times I reboot, power down, or rest the after saving config.g.
-
Sorry... The M98 P"config.g" returns "M98 P"config.g"" in the console.
-
Ok then something is not right, because the "macros" are the same thing that DWC uses when you push the buttons.
Where are the macros you are using to home located? They should be in /sys/homeall.g homex. etc
If you are using homing files located anywhere else, they are not in the right place.
G28 = homeall.g = home all button in DWC.
So if G28 and the buttons don't work, then the homing files in the /sys folder are not correct, and whatever macros you are using to home should be moved into the system folder.
-
Well, this was a unique learning experience. I moved the homing files to the "Macros" under the "File Management" a month ago, while dealing with the firmware issue.
I moved them back to the "System" section in the "File Management" menu in the DWC. All is back to normal, if there is such a thing...
Thanks for your help.
