In case anybody else is having this issue and their Duet is buried inside their printer where the SD card isn't accessible, you can create the directory from the Web UI by navigating to this URL: (Replace <DuetIP> with the IP address of your duet)
http://<DuetIP>/rr_mkdir?dir=0%3A%2Ffilaments
@richardmckenna To me it looks like a stand. If you rotate the wire part 180 degrees, put the screw through the narrow part and into the hold on the bar, you end up with a sort of tuning fork shape.
That's my guess anyway. Did it not come with a manual or some pictures of it in its assembled state?
Edit:
Just found this which shows it assembled:
Not sure what it's for though, maybe it's for poking people who interrupt your soldering session?
RC5 is working fine so it looks like that bug was the issue.
Thank you all for your time and help.
@Phaedrux said in Homing issue when homey.g:
@yngndrw said in Homing issue when homey.g:
it is sufficient to move the axis as it was working like this previously and the M913 documentation does suggest that this can be used to protect your endstops so that's why I left it in.
Yes reducing the current is a good idea, but you must ensure that it's still set high enough to guarantee reliable movement. So you'll need to experiment. Try 30% or 40%.
Okay I'll increase it a little to be safe.
@yngndrw said in Homing issue when homey.g:
It appears to be hanging on the G1 H1 Y-2 F300line for some reason.
try increasing the movement distance. 2mm should be enough based on the distance of the previous move, but setting it higher still just to be safe.
RC6 seems to have some issues of it's own at the moment and RC7 appears to be right around the corner, so maybe hold out for that.
I just tried 10mm but that didn't resolve it - It doesn't even try to move for that line.
I did notice in the release notes for RepRapFirmware 3.01-RC3:
Bug fixes:
* When homing switches were already triggered at the start of a homing move, sometimes the move queue got stuck, requiring a reboot
... so this looks to be the issue that I'm seeing. I've still not finished reading through the release notes but it looks like I shouldn't have to change anything in order to upgrade. If RC6 is having issues, I might upgrade to RC5 for the time being.
@aidar said in Homing issue when homey.g:
For some reason you lowered you motors current to 20%. With endstop switches you dont have to do so, leave it to 100% and test then.
@Phaedrux said in Homing issue when homey.g:
Agree with Aidar about the 20% current. That may be too low to reliably ensure movement.
This was left over from the old stall-detection setup, it is sufficient to move the axis as it was working like this previously and the M913 documentation does suggest that this can be used to protect your endstops so that's why I left it in. I've just tried it without (Also removed the related M400's) but sadly it didn't make a difference.
@Phaedrux said in Homing issue when homey.g:
@yngndrw said in Homing issue when homey.g:
Sadly as H2 moved individual motors instead of axes I have to manually coordinate the CoreXY move but I've changed that now:
If the axis is already homed you don't need an H at all.
In this case the X axis may not have been homed (Even for a "home all", I home the Y axis before the X axis) as the X endstop switch is mounted on the fixed frame and touches the carriage. This move is to make sure that the carriage is out of the way so that I don't smash into the X endstop while homing the Y axis. This is another reason for the reduction in current while homing, this particular line may bump the carriage into the other side of the machine - Thinking about it I should probably back it off a tiny amount so that it can't scrape along the frame!
@Phaedrux said in Homing issue when homey.g:
@yngndrw said in Homing issue when homey.g:
Duet Web Control 2.0.4 Board: Duet WiFi 1.0 or 1.01 + DueX5 Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.0 (2020-01-03b3) Duet WiFi Server Version: 1.23At this point if you are planning on sticking with RRF3 you should consider upgrading to 3.01 RC6 and DWC 2.1.1
I had avoided 3.01 as it's an RC, but I've just realised that the version I'm on is a beta version anyway so I might as well upgrade. I'll have to work out the configuration changes I need to make in order to upgrade and then give it another go.
While looking over the configurations in relation to your suggestions I did just find the line which is causing the issue. Looking at the actual homing section for the Y axis: (I've changed some of the speeds here)
G1 H1 Y-400 F3000 ; move to the front 400mm, stopping at the endstop
G1 Y1 F10000 ; move away from end
G1 H1 Y-2 F300 ; fine home, stopping at the endstop
I coarsely home the axis once at a high(er) speed, then step back and re-home at a lower speed. It appears to be hanging on the G1 H1 Y-2 F300 line for some reason. I've double checked that the 1mm back-off is enough to clear the endstop so it must be a bug in this version. I also tried setting it to absolute mode and back to relative mode between the two homing commands in case the coordinates were getting messed up but it doesn't seem to be the case.
@aidar said in Homing issue when homey.g:
@yngndrw said in Homing issue when homey.g:
G1 H1 X3 F5000 ; move X 3mm
H1 means stop at endstop. I assume you have already homed x, so most likely you cant hit x endstop with move x3. Should that H1 be H2 instead?
Good catch, you're absolutely right. Sadly as H2 moved individual motors instead of axes I have to manually coordinate the CoreXY move but I've changed that now:
G1 H2 X3 Y3 F5000 ; move X 3mm (adjusted for CoreXY movement)
Sadly it doesn't seem to have resolved my main issue though, it still seems to hang within the routine for some reason.
Hello,
I have an E3D tool changer (CoreXY) and it was initially using stall detection for the X / Y axis endstops.
I've just upgraded to physical endstops but I'm now having an issue where running the homey.g file performs the actual homing moves, but then seems to hang the printer. It shows as "idle" and the axis shows as homed, but it ignores any input when trying to jog the file and running homey.g again hangs the printer. (State changes to "busy" and the homing moves do not occur)
If I run each line from homey.g manually in the console, it works and I can cycle through these numerous times without issue.
; homey.g
; called to home the Y axis
; DC42 reduced stall sensitivity from 3 to 2
; DC42 replaced G1 S parameters by H
; DC42 removed redundant G4 and M574 commands
; AY updated to use physical endstops
G91 ; use relative positioning
G1 H2 X0.5 Y-0.5 F10000 ; energise motors to ensure they are not stalled
M400 ; make sure everything has stopped before we change the motor currents
M913 X20 Y20 ; drop motor currents to 20%
;M915 H200 X Y S3 R0 F0 ; set X and Y to sensitivity 3, do nothing when stall, unfiltered
G1 H2 Z3 F5000 ; lift Z 3mm
G1 H1 X3 F5000 ; move X 3mm
G1 H1 Y-400 F3000 ; move to the front 400mm, stopping at the endstop
G1 Y1 F2000 ; move away from end
G1 H1 Y-2 F500 ; fine home, stopping at the endstop
G1 Y2 F2000 ; move away from end
G1 H2 Z-3 F1200 ; lower Z
G90 ; back to absolute positioning
M400 ; make sure everything has stopped before we reset the motor currents
M913 X100 Y100 ; motor currents back to 100%
What can I do to debug this?
Duet Web Control 2.0.4
Board: Duet WiFi 1.0 or 1.01 + DueX5
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.0 (2020-01-03b3)
Duet WiFi Server Version: 1.23
Diagnostic output while it's in its "hung" state:
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.0 running on Duet WiFi 1.0 or 1.01 + DueX5
Board ID: 08D6M-91AST-L23S4-7JTD6-3S86L-TNXFK
Used output buffers: 3 of 24 (14 max)
=== RTOS ===
Static ram: 30516
Dynamic ram: 92924 of which 28 recycled
Exception stack ram used: 536
Never used ram: 7068
Tasks: NETWORK(ready,688) HEAT(blocked,1240) DUEX(suspended,160) MAIN(running,3676) IDLE(ready,156)
Owned mutexes:
=== Platform ===
Last reset 00:02:38 ago, cause: software
Last software reset at 2020-04-08 12:22, reason: User, spinning module GCodes, available RAM 7052 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 42.8, current 44.5, max 45.0
Supply voltage: min 24.1, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/350
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/225
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-04-08 12:25:09
Cache data hit count 439170185
Slowest loop: 4.00ms; fastest: 0.09ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 165, MaxWait: 15498ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 21, completed moves: 14, 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 -1 -1
=== GCodes ===
Segments left: 1
Stack records: 1 allocated, 1 in use
Movement lock held by http
http is idle in state(s) 1 8, running macro
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: 81.61ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(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.23
WiFi MAC address a0:20:a6:16:ee:92
WiFi Vcc 3.35, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24360
WiFi IP address 192.168.1.189
WiFi signal strength -44dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
@TLAS It's surrounded by aluminium extrusion (It's a Core XY machine with the board mounted at the back) and the printer is sitting on top of a metal box, but it isn't fully enclosed. I guess the environment / background noise might also have its part to play.
@TLAS I wonder if the Wifi module has changed between different versions of the Duet2 Wifi.
I have v1.03 of the Duet2 Wifi and my Wifi module is only very slightly warm - The connection has also been rock solid for me, even with lots of metal nearby and the AP being located through both a wall and a ceiling.
@richardmckenna To me it looks like a stand. If you rotate the wire part 180 degrees, put the screw through the narrow part and into the hold on the bar, you end up with a sort of tuning fork shape.
That's my guess anyway. Did it not come with a manual or some pictures of it in its assembled state?
Edit:
Just found this which shows it assembled:
Not sure what it's for though, maybe it's for poking people who interrupt your soldering session?
@dc42 Ah I see, that makes sense! Does that mean that the tool distribution board is missing the second termination jumper that the expansion board has, or is that an old design in the documentation, or is it intended that the splitter would always come before the tool distribution board?
@Danal Yes in CAN any board could send a message at any time and therefore act as a master, with the message ID allowing for prioritisation / arbitration. (Lowest ID wins) I think you're right in that it would probably make life easier in there was a BUS in each direction so that's a fair theory.
The buffering of moves makes a lot of sense in this setup and that probably rules out the different prioritisations.
Maybe there simply isn't enough bandwidth over one bus for the number of expansion boards they'd like to support?