Z Home Strange behavior
-
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. -
I think what's happening is that the TB6600 is not fully compatible with 3.3v logic. I'm going to re-wire the system to use TMC2100 on the 10 and 11 drivers and will use them for extruders as I was planning originally, since I can't find an external driver which is 3.3v compliant which support higher than 2A (I don't want to use DRV8825s), but the TMC2100 with the expansion board is. I'll get the authentic TMC2100s in a couple of days, but I'll re-wire the Z to use the onboard TMC2660 since I can run those at a higher amperage than TMC2100s…
-
Please can you try G1 S2 moves on the Z or Z+U axes. They don't check the endstops but otherwise they behave like G1 S1 moves. If they work then the issue must be connected with reading endstops.
-
Please can you try G1 S2 moves on the Z or Z+U axes. They don't check the endstops but otherwise they behave like G1 S1 moves. If they work then the issue must be connected with reading endstops.
Don't think it's that, I think the TB6600 drivers are causing the duet to freeze up…I'm swapping them for TMC2100. It's curious that with the TB6600 drivers they were always on as soon as powered on, enable pin had to impact. That seems to be the issue.
-
If your drivers have the usual + and - optically isolated inputs for each of step, direction and enable, and you are not using level shifters to connect them, then I suggest you connect +EN to +3.3V and -EN to the EN output on the expansion connector or CONN_LCD. That will ensure that the drivers don't get enabled at power up. With this wiring configuration, don't use R1 in the M569 commands.
-
PS - I've discovered a bug that might possibly explain some of the odd behaviour. Will be fixed in 1.20beta2, which I hope to release later this afternoon.
-
So I re-mapped Z to different on-board drivers and same behavior persists. Shoot…I thought it was the drivers fault. OK. I'll wait for your fix. I am able to home z and move it around fine -- but as soon as I home everything else along with Z -- then the freeze up occurs. I'll keep this wiring setup, the onboard drivers are SO MUCH quieter and smoother motion than the TB6600 -- I thought the lead screws were just noisy.
-
Not sure if this is useful.
I connected via USB and I was able to execute M122 when the machine gets into this state where DWC keeps disconnecting.=== Diagnostics ===
Used output buffers: 1 of 32 (10 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: 3608 current, 4876 maximum
Never used ram: 15604
Last reset 00:06:54 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 11984 bytes (slot 1)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
[ERROR] Error status: 0Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 29.5, current 29.7, max 2
9.9
Supply voltage: min 24.4, current 24.5, max 24.7, 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: stalled standstill
Driver 7: stalled standstill
Driver 8: standstill
Driver 9: standstill
Date/time: 2017-10-24 20:32:25
Slowest main loop (seconds): 1.293327; fastest: 0.430646
=== Move ===
MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 8, completed moves: 8
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 ready with "M122" 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(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) -
One more curios thing. A couple of the end stop lights don't fully turn off after I do the home routine. They do turn off if I manually press the end stops but if homing they stay dimmed for some reason – specifically X and V which are the my 1st gantry X axis limit switches. Didn't notice that before -- wonder why all others turn off fully and these stay dimmed.
-
What type of endstop switches are they? Are you talking about lights on the Duet or on the switches themselves?
