Z Home Strange behavior
-
When I so a Z home
here is my script:
G91
M584 Z10 U11
G1 Z10 U10
G1 S1 Z-500 U-500 F1000
G1 Z5 U5
G1 S1 Z-10 U-10 F100
M584 Z10:11
G92 Z0
G90it works if Z travel to S1 is short – and it behaves correctly, but if the bed fell to the bottom and it needs to travel 200 or more mm, then after it hits the end stops it pauses a long time then does the backoff and does the 2nd slow home. After that it falls off the network and doesn't respond to commands quickly, basically needs to be powered down and back up.
-
So I tried adjusting the Z config
M569 P10 S1 R1 T4 ; Drive 10 goes backwards
M569 P11 S1 R1 T4 ; Drive 11 goes backwardsWith T4 T1 – doesn't make a difference.
If I do G1 Z40 even it gets to 40 then waits for a while until it's no longer busy, then I hit G28 and it goes to the top, the homes, but doesn't perform the backoff routines for a few seconds, then does them, then the web console disconnects and crashes.
Have the Z probe working now so I can now do the lead screw offset computation, but these weird Z moves are driving me nuts. All other axis work fine and if Z doesn't want to cooperate. I tried 1.19 -- stable version, tried 1.20 alpha -- same problem -
With 20.1 beta I am able to get to Z100 and get back home OK, anything more and it starts to get confused. It almost seems that it takes too long to get to the Z value because it's slow, and something times out.
-
Try a speed less than F1000 in your G1 S1 command, or lower microstepping on the Z and U axes if you are using more than x16. I think the product of speed and steps/mm on your printer is probably to high for a homing move.
-
So I tried as low as F300, I'm using 16x microstepping with TB6600 drivers. Just the simple motion of G1 Z200 F300 causes the DWC to disconnect and the printer goes into some slow bogged down state where I have to power it down. I recall this wasn't happening with earlier versions maybe 1.18 – I can try that and see if it works there -- though other things didn't work with earlier versions. I basically can't move Z more than 50-100mm or the duet hangs -- right now Z is at 300 and I can't connect DWC -- it connects then disconnects.
-
1.18 doesn't support some of my config changes…so need to be on 1.19 or higher, so something is broken with Z motion...maybe faster is better?
-
Under machine properties drive 2 and 3 have the settings for Z and U, but that's wrong because Z and U are defined at 10 and 11. Something is not mapped correctly
Also, if my Z an U get out of alignment and I tried to move U independently – X moves along with U for some reason, There is nothing that maps X to U. So this makes no sense.
This is my config.g
; Movement section
M569 P0 S0 ; Drive 0 goes forwards (change to S0 to reverse it)
M569 P1 S0 ; Drive 1 goes backwards
M569 P2 S1 ; Drive 2 goes forwards
M569 P3 S1 ; Drive 3 goes forwards
M569 P4 S1 ; Drive 4 goes forwards
M569 P5 S0 ; Drive 5 goes forwards
M569 P6 S1 ; Drive 6 goes forwards
M569 P7 S1 ; Drive 6 goes forwards
M569 P8 S1 ; Drive 6 goes forwards
M569 P9 S1 ; Drive 6 goes forwards
M569 P10 S1 R1 T2 ; Drive 10 goes backwards
M569 P11 S1 R1 T2 ; Drive 11 goes backwards
M584 X0 Y1 B2 V3 W4 A5 E6:7:8:9 Z10:11 U:11
M671 X-95:705 Y267:267 S5
M557 X10:545 Y10:480 S30M350 X16 Y16 B16 W16 A16 E16:16:16:16 I1 ; Set 16x microstepping with interpolation
M574 X1 Y1 Z1 B2 V2 W2 A1 U1 S1 ; set endstop configuration (X and Y endstops only, at low end, active low)M906 X2000 Y2000 Z2000
M906 B2000 V2000 W2000 A2000
M906 E2000:2000:2000:2000 ; Set motor currents (mA)
M201 X800 Y800
M201 B800 V800
M201 W800 A800
M201 Z15 U15
M201 E1000:1000:1000:1000 ; Accelerations (mm/s^2)
M203 X15000 Y15000 B15000
M203 V15000 W15000 A15000
M203 Z1500 U1500
M302 E3600 ; Maximum speeds (mm/min)
M566 X600 Y600 B600 V600
M566 W600 A600
M566 Z15 U15
M566 E15 ; Minimum speeds mm/minute
M208 X556 Y490 B527 V630 W639 A600 Z600 U600 ; set axis maxima (adjust to suit your machine)
M208 X-32 Y0 B30 V0 W0 A-24 Z-1.5 U-1.5 S1
M92 X53.33 Y53.33
M92 B53.33 V53.33 W53.33 A53.33 Z400 U400 ; Set axis steps/mm
M92 E420:420:420:420 -
1. Please post a screen shot of your machine properties page so that we can see what you mean.
2. Please try firmware 1.20beta1, because 1.20 is what I am working on and that is where any necessary bug fix will go.
3. After a long Z move that causes DWC to lose the connection, please reconnect without rebooting, run M122, and post the report here.
-
-
Note Drive 2 and Drive 3 are saying they're max speed is 25mm/sec, but that's not how 2 and 3 are configured – that's B and V -- and they're configured to 250mm/sec -- same for acceleration. It's showing data for Z and U. Which should be shown for 10 and 11.
Here is M122 before it goes nuts. I'm going to try to get it to home now -- very short set of Z moves (using 1.20b1)
M122
=== Diagnostics ===
Used output buffers: 3 of 32 (9 max)
=== Platform ===
RepRapFirmware for Duet Ethernet version 1.20beta1 running on Duet Ethernet 1.0 + DueX5
Board ID: 08DDM-9FAMU-JW4S4-6JKD8-3SD6J-TMXVS
Static ram used: 11624
Dynamic ram used: 96960
Recycled dynamic ram: 2008
Stack ram used: 1184 current, 4416 maximum
Never used ram: 16064
Last reset 00:00:12 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 16072 bytes (slot 1)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, 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 30.3, current 33.7, max 33.8
Supply voltage: min 24.6, current 24.8, max 24.9, under voltage events: 0, over voltage events: 0
Expansion motor(s) stall indication: no
Driver 0: standstill
Driver 1: standstill
Driver 2: standstill
Driver 3: standstill
Driver 4: standstill
Driver 5: standstill
Driver 6: standstill
Driver 7: standstill
Driver 8: standstill
Driver 9: standstill
Date/time: 2017-10-23 11:38:03
Slowest main loop (seconds): 0.004701; fastest: 0.000041
=== Move ===
MaxReps: 0, StepErrors: 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 heater = 0, chamber heater = -1
Heater 1 is on, I-accum = 0.0
=== 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 ===
State: 5
HTTP sessions: 1 of 8
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) -
I did home – then shortly after Z home DWC dropped off -- was able to capture M122 results before it dropped off:
M122
=== Diagnostics ===
Used output buffers: 3 of 32 (13 max)
=== Platform ===
RepRapFirmware for Duet Ethernet version 1.20beta1 running on Duet Ethernet 1.0 + DueX5
Board ID: 08DDM-9FAMU-JW4S4-6JKD8-3SD6J-TMXVS
Static ram used: 11624
Dynamic ram used: 96984
Recycled dynamic ram: 1984
Stack ram used: 1184 current, 4416 maximum
Never used ram: 16064
Last reset 00:02:26 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 16072 bytes (slot 1)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 31.4, current 31.8, max 34.2
Supply voltage: min 24.5, current 24.6, max 24.9, under voltage events: 0, over voltage events: 0
Expansion motor(s) stall indication: yes
Driver 0: stalled standstill
Driver 1: stalled standstill
Driver 2: stalled standstill
Driver 3: stalled standstill
Driver 4: stalled standstill
Driver 5: stalled standstill
Driver 6: standstill
Driver 7: standstill
Driver 8: standstill
Driver 9: standstill
Date/time: 2017-10-23 11:40:18
Slowest main loop (seconds): 0.441243; fastest: 0.000046
=== Move ===
MaxReps: 6, StepErrors: 0, FreeDm: 240, MinFreeDm 228, MaxWait: 4067ms, Underruns: 0, 1
Scheduled moves: 7, completed moves: 7
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 2 in use
Movement lock held by http
http is idle in state(s) 0 0 3
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 ===
State: 5
HTTP sessions: 1 of 8
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) -
Now I can't reconnect DWC back – basically 1.20b1 doesn't work at all -- 1.19 stable -- I can get Z to do a short home, and was able to calibrate my piezo based z-probes -- so, all that works -- I have piezos in each of the 4 hotends and they all trigger correctly. Piezos are not active at this point as they report below trigger range, and as you can see my home Z is not using Z probe to home since I need to get my lead screws to line up, I have the limit switches set so that the nozzles home off the bed and then G32 runs and aligns the lead screws...that all works, but Z motion is really broken now.
-
1. Please clarify what doesn't work using 1.20b1.
2. Regarding reconnecting DWC, did you also install the correct version of DuetWiFiServer according to whether you installed 1.19.2 or 1.20beta1? If you upgraded from 1.18.2 or earlier, did you go through the new instructions for configuring up your SSID and wifi password?
-
1. Please clarify what doesn't work using 1.20b1.
2. Regarding reconnecting DWC, did you also install the correct version of DuetWiFiServer according to whether you installed 1.19.2 or 1.20beta1? If you upgraded from 1.18.2 or earlier, did you go through the new instructions for configuring up your SSID and wifi password?
So Z motion doesn't work at all with 1.20b1, the bed is basically near the top, it has to do very little to home, the script backs it of slowly and goes back up (see original post with the script) –- I home all -- homeall.g calls homez.g so I don't have to copy it over, and after it homes Z, it is unresponsive, and DWC disconnects and I can't reconnect to it again, more specifically it connects, then disconnects immediately and I can't even capture M122 -- the last M122 results I posted was just before DWC dropped off -- and the machine became unresponsive.
Note with 1.19 -- the short home routine as I just did worked fine -- no issues -- Z only became a problem with 1.19 if it moves 40+mm, which is obviously a problem since my max Z travel is ~450mm.
-- I'm using DuetEthernet and latest version of the Web console -- I don't think the wifi server applies to my board.
Using a static IP -- pre-allocated in my router for the mac address.
-
Hopefully this can be fixed. – my alternative is to run Z and U of the board (from drive 2 and 3 as they go in order) and I have a couple of spare breakouts for TMC2100s which I can wire in for 10 and 11 and use those to run my extruder 3 and 4 -- that way, everything gets mapped in order of letters and numbers -- which seems to me will work, but ideally I want to keep my Z gantry on the TB6600 drivers since they can put out the full 2.8A needed by the nema 23s on the Z/U and I'd rather not ditch the TB6600 since they're already wired up to control the Z/U.
This is actually new behavior -- I originally had Z paired with B -- and the limit switch on the Duex5 -- but that doesn't work at all -- when I did home routine 90% of the time it would not stop when it would hit the B limit switch -- I had been running 1.19 at that point, so swapping B and U -- fixes the homing of Z axis -- basically it appears to me that pairing a limit switch on Duet board and a limit switch on Duex5 isn't fully supported. The Duex5 limit switches work fine now controlling their own axis, but they did not work properly for secondary Z lead screw, but that's a different problem -- I'm fine with mapping different letters as it really inconsequential -- just extra letters are shown on the DWC/Panel -- since U is secondary Z letter now, not B, so I can't hide it from the UI
-
DC42, let me know if you want me to try anything else. Or if you have some ideas as to what's going on. I can have my wife turn the printer on and I can get some information from it remotely during the day (US EST time zone) – otherwise I'm thinking of rewiring it when I get home to use TMC2100 breakboards for the 3rd and 4th extruder, as I said above, which hopefully will work. Plan will be to simply use drivers 0-11 in sequence without remapping things in the middle -- I believe I can run the nema 23s of the duet board at 2.4A -- does it go to 2.8A yet? I saw somewhere there was a plan to allow for 2.8A . I have active cooling setup blowing across the PCBs -- sucks to not be able to use my TB6600 as they're more ideal for the Z axis, but I'd like to finish this build -- and start getting prints of it.
-
I'm sure we can get this fixed, I just need to work out what is going on.
I'm really surprised that using F300 for the speed of your homing move (the G1 S1 Z U command) in homez.g doesn't fix the problem. Please try even lower, e.g. F100, with firmware 1.20b1. You can send the command from the command line to avoid having to edit homez.g all the time.
-
Did the following with 1.20b1
changed my homez.g – just to be sure
G91
M584 Z10 U11
G1 Z10 U10 F100
G1 S1 Z-500 U-500 F100
G1 Z5 U5 F100
G1 S1 Z-10 U-10 F50
M584 Z10:11
G92 Z0
G90super slow -- it homed then DWC disconnected and back in the crashed state, DWC connects -- then promptly disconnects. Note that with 1.19 stable -- small Z homing worked fine -- larger Z moves are the problems there. I can also get DWC to reconnect with 1.19 stable and possibly try to get some debug info if it would help. Essentially any Z moves with 1.20 end up putting the machine in a inoperable state -- basically I can interact with from the LCD panel, but all moves are highly delayed -- as if it's spinning doing something else, and it can't connect with the DWC -- probably for the same reason
Pretty sure it's not speed related. -
Definitely an issue with 1.20b1 –
Changed my homez.g back to :
M584 Z10 U11
G91
G1 Z10 U10 F700
G1 Z-500 U-500 F700 S1
G1 Z5 U5 F700
G1 Z-10 U-10 F100 S1
M584 Z10:11
G92 Z0 U0
G90with 1.19 and homed with the bed near the top and worked fine.
M122
=== Diagnostics ===
Used output buffers: 3 of 32 (14 max)
=== Platform ===
RepRapFirmware for Duet Ethernet version 1.19 running on Duet Ethernet 1.0 + DueX5
Board ID: 08DDM-9FAMU-JW4S4-6JKD8-3SD6J-TMXVS
Static ram used: 17684
Dynamic ram used: 96908
Recycled dynamic ram: 96
Stack ram used: 1136 current, 4400 maximum
Never used ram: 11984
Last reset 00:01:11 ago, cause: software
Last software reset reason: User, spinning module GCodes, available RAM 16072 bytes (slot 1)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, 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: 1.9ms
MCU temperature: min 31.6, current 32.2, max 34.7
Supply voltage: min 24.5, current 24.7, max 24.9, under voltage events: 0, over voltage events: 0
Expansion motor(s) stall indication: yes
Driver 0: stalled standstill
Driver 1: stalled standstill
Driver 2: stalled standstill
Driver 3: stalled standstill
Driver 4: stalled standstill
Driver 5: stalled standstill
Driver 6: standstill
Driver 7: standstill
Driver 8: standstill
Driver 9: standstill
Date/time: 2017-10-23 14:27:00
Slowest main loop (seconds): 0.118866; fastest: 0.000045
=== Move ===
MaxReps: 6, StepErrors: 0, FreeDm: 240, MinFreeDm 228, MaxWait: 4102ms, Underruns: 0, 0
Scheduled moves: 7, completed moves: 7
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 2 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 ===
State: 5
HTTP sessions: 1 of 8
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)However if I try to just move Z even slow 50 or 100 mm/min -- then I get back into that slow molasses state.
Note back before I had dual independent lead screws -- I was running them of the duet Z steppers in series, and F1000 and F2000 speeds worked just fine. Even for homing. So my thinking is this has something to with remapping to external stepper drivers.
-
I may have an idea of what the problem is.
I had the TB6600 drivers connected the following way
3v -> enable -
3v -> pulse +
3v -> dir+
enable pin -> enable +
pulse pin -> pulse -
dir pin -> dir -I had tried tying - pins to ground and then take pins from the duet and send the to + and the steppers don't hold torque – so that's not right. But this seems to be no right either.
So this worked for a while -- now it stopped working.
What I did was take an expansion board I have which simply takes a regular pololu stepper driver and I plugged in a couple of regular alegro drivers and some spare nema 14s...So with just 3v going to the 5v power on that expansion board and Vin and Gnd and then regular enable, step and dir inputs, it worked fine, I can have it move Z without issue - it's not moving Z, but it can operate stepper 10 and 11 via Z control with no problems. So looks like my issues with Z have to do with how the TB6600 is wired.
What is the correct way to wire one of those expansion drivers...I even tried pulling enable pin high/low -- it seems something is not compatible with these drivers.
