Z Home Strange behavior
-
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?
-
Just regular mechanical end switches. Yes lights on the duet which are on when end stop is not triggered and off when they are.
-
If the lights on the Duet are dimming, that sounds like the voltage on the 3.3V rail could be dropping, perhaps du to an overload. That would also cause the motor drivers to be shut down.
Do any of the blue 12V, red 5V or green 3.3V LEDs on the edge of the Duet dim too?
-
If the lights on the Duet are dimming, that sounds like the voltage on the 3.3V rail could be dropping, perhaps du to an overload. That would also cause the motor drivers to be shut down.
Do any of the blue 12V, red 5V or green 3.3V LEDs on the edge of the Duet dim too?
Nope – what I'm saying the lights should be off, but they're not full off, they're very dim
So the behavior is as follows.
When machine is moving and everything is powered -- the red limit switch LEDs are nice and bright -- then when I home, all of the limit switch lights, except the X and V limit switches turn off, those are almost off -- I'd say 20% of full brightness. Like something is not pulling them to ground all the way.
I checked the 3v rail with a volt meter and it's rock solid 3.3v -- was just verifying some things on the LCD headers. -
Oh, and when not homing, if I power the machine on and have it moving and such – so that means all the stepper drivers are active. If I press those limit switches with my finger -- the lights turn off completely -- the 20% dim behavior only happens when machine homes.
-
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.
Any update on when you expect this released, I can't use 1.20b1 as it freezes on homing routines, 1.19 is better but repeated homing gets it to freeze also – and longer Z moves are a problem in both versions. I thought I had found one of the reasons for the issues was a faulty ethernet cable, and 1.19 became more stable, didn't help 1.20b1 --still can't home.
-
1.20beta2 is now released.
-
1.20beta2 is now released.
I saw – leaving work in a few minutes. Will be able to try it in a couple of hours. Kinda glad I ditched the noisy TB6600 drivers -- will put them in a draw for a future CNC build
-
I found something which appears to make my Duet behave.
At the end of config.g I added the following
Now homing works reliably, I no longer have B (2nd Z axis fail to home, basically fixed the glitchiness I was seeing)
I don't really know why toggling Z 1 micron fixes things, but it does.
Can you implement M17 gcode command, then I wouldn't need to do that weird micron move
T0
G91
G1 Z0.01
G4 S5
G90
M300 S300 P2000
M18
