My quad carriage machine is failing on Tools. AGAIN.

MaracMB

the topic was first opened here:
https://forum.duet3d.com/topic/19312/duet2-axies-and-tools-motor-mapping-mismatch/2?_=1604425183271

MaracMB

11th stepper is external, simple expansion breakout board (just as shown somewhere in the Wikis...) with original watterott tmc2209 until i get something better. Set to 16/256 microsteps and adjusted the jumpers accordingly for configuring it. That, motor 10 runs extruder for T3.

The tools do extrude correctly btw. If that helps. So only definitions/mapping for X carriages have gone crazy.

engikeneer

@MaracMB That is an impressive machine and I can certainly see that debugging it won't be easy!

Might help if you post your config-override too for completeness

In your homeu and homew, you only step back by 4mm before doing the slow home, while everywhere else (homex, v, all) you step back by 10mm. Just wondering if that's not enough and you're getting some failed homings on U and W during your tool changes which is messing them up? Might also explain why it seems intermittent if you're just on the limit?

I've noticed that in your homez file, you don't re-hide your A axis, you only re-assign driver 4 to Z:

M584 Z1:4 P7				; combine Z and V and show only 6 axes in interface

TBH, it could be over-complicating things as you don't need to split the axis to use multiple endstops for multiple motors in RRF3 any more:
https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors#Section_Axis_levelling_using_endstops
Just thinking it will remove one layer of drive mapping/assignments, homing etc from the equation.

Other unrelated thing, in your config, you have set you motor microstepping at 32 with interpolation, but the duet doesn't support this - it's only 16 with interpolation

MaracMB

@engikeneer this project really was just a space/machinecount optimization that went it’s own way... i have much cooler stuff ready for this. But first things first.

On endstops i retreat only 4 mm because of optical endstops. Triggering that is perfect. 4 mm is more than enough. Config is working version so a lot is unfinnished. It still needs a lot work.

Splitting the axes for the Z... yes, i am aware of that possibility to optimize that but didn’t consider it a thing that would needed to be done.

The interpolation on 32 microsteps is on because it makes less whine. Not that i would need 256interpolation... 2660 arent the quietest of tmc’s.

MaracMB

@engikeneer the P7 parameter for axis visibility is there because i, when this thing gets resolved, will hide second Z axis (A). For now, i just set it to all visible, yet left for later change back to P6

MaracMB

RESOLVED

For anyone, that might experience such headache and stumbles upon this:
one maps the axes, not the motors to the tools. and you count the axes, not specify motors...

dc42

I'm glad you solved it! Have you any suggestions on how we can improve the documentation to help others to avoid the same issues?

MaracMB

@dc42 well, it’s still RTFM thing i guess. But it may be nice to just copy paste that section with asigning axes to tools in “Creating a tool that uses just one carriage”.
The instructions later on, when defining ditto tools clearly state
‘’’ Note that axes are mapped in the order XYZUVWABC, where X=0, Y=1, Z=2, U=3 etc, not by driver number, so X0:3 means 'map axis 0 (X) and 3 (U) to X'.’’’

But this is minor. The extent of frustration, optimization and learning one goes through may just be beneficial

So tools definitions solved, and properly understood, i have to check homing reliability now. That may still be an issue.
I am stripping
m120
M84 Prime.g
M121
From my toolchange post scripts to see if that helps with tools homing reliability. That’s the only thing that’s left i guess. If it won’t, i’ll nag on.

MaracMB

i have re-set my toolchange scripts. It worked for a while.
After 2-3 hours, the 4th axies failed to home when tool was deselected.

Error G0/G1
M120
G91
G1 X50 F6000
G90
M121

Where does this come from ? This is not in my homing files, not in my toolchange files, nowhere.

My tfree file now look like :

G1 E-12 F3600 			; retract 12mm
G91 				; relative axis movement
G1 Z2 F360 			; up 2mm
G90 				; absolute axis movement
G28 X				; park the U carriage home - slow
M106 S0         		; turn off print cooling fan

My tpost look like:

M106 R2         	; restore print cooling fan speed
M116 P0 		; wait for tool 0 heaters to reach operating temperature
G91
G1 X1 H2
G90
G28 X
G1 E12 F1200 		; extrude 12mm

I thought it worked. But then it didn't.

Also, when i homeall , all tools home normaly.
But when i homeall via gcode file (G28), second tool does not home correctly.

homeu.g :

G91              ; relative positioning
G1 Z2 F360 H2    ; lift Z relative to current position
G1 U320 F3600 H1 ; move quickly to X axis endstop and stop there (first pass)
G1 U-2 F600 H2    ; go back a few mm
G1 U4 F360 H1 	 ; move slowly to X axis endstop once more (second pass)
G1 Z-2 F360 H2   ; lower Z again
G90               ; absolute positioning

Homeall.g :

G91                     	; relative positioning
G1 Z2 F360 H2           	; lift Z relative to current position
G1 X-400 Y-450 U400 V-400 W400 F3600 H1	; move quickly to X and Y axis endstops and stop there (first pass)
G1 X5 Y5 U-5 V5 W-5 F3600 H2         	; go back a 5 mm
G1 Y-10 X-10 U10 V-10 W10 F360 H1 			; second pass
M98 Phomez.g			; call homing script for Z axes
G90

MaracMB

dc42

Is it the U and/or W axes that failed to home? If so, it is just one of those, or both of them?

Those endstop switches are the ones connected to the DueX5 board. Keeping those switches up to date relies on I2C communications between the Duet and the DueX along with an interrupt. A M122 report taken when this happens will provide data on the status of the I2C interface.

Phaedrux

@MaracMB said in My quad carriage machine is failing on Tools. AGAIN.:

Also, when i homeall , all tools home normaly.
But when i homeall via gcode file (G28), second tool does not home correctly.

What do you mean by this? G28 is homeall.g. How else are you homing all?

MaracMB

@dc42 would it help if i shorten the IDE cable in between them?
I do have to get the wiring in orderly lenghts and routes... it’s A LOT of wiring...

So it’s basically just latency issue?

Can ,i in time i do wiring, insert some pauses into homing? Half a second here and there wouldn’t hurt for realiability.

Phaedrux

Can you post a photo of how you have the Duet and Duex wired together? Particularly the power?

See the description and photo here for how it should be done.

https://duet3d.dozuki.com/Wiki/Duex2_and_Duex5_Features#Section_Wiring

MaracMB

@Phaedrux exactly.
I think it’s latency as i interpret dc42’s explanation...
And i thought off adding 5th and 6th carriage. Silly me.

@dc42 would it help if i put all X carriages on one board and extruders on the other?

MaracMB

@Phaedrux that i can do in the morning (machine in the cave...)
It’s powered from a 350w meanwell, AC bed. The VIN from PSU is 1.5mm i guess.. stock. And “the bridge” between the Duet and Duex is with 2.5mm2 high grade copper wires. Ferulle crimped.

MaracMB

@Phaedrux , @dc42
I have rewired.
Put all the X motors and Y on the Duet board, and Duex now holds both Z motors and all E motors.

I have rewired the VIN. Just in case.

I have reset the configs accordingly.

State of art:
Machine seems to home the X carriages reliably now, same goes for Y
But now it fails on almost every or every second Z homing.
If i home Z, it will probably home correct. If i go and commit home all, it will most definetly not home Z axes correctly.

Machine needs independant Z motors to level the X gantries every single time, or this is just a very, very, very large paperweight.

As suggested by @engikeneer, i have joint the Z axes. Is this now a problem?

homez.g :

G91               		; relative positioning
G1 H2 Z5 F600
G1 Z-405 F900 H1
G1 Z2 F900 H2
G1 Z-5 F360 H1 
G1 Z3 F900				; lift both Zs to 3
G90					; absolute positioning

homeall.g

G91                     	; relative positioning
G1 Z2 F360 H2           	; lift Z relative to current position
G1 X-400 Y-450 U400 V-400 W400 F3600 H1	; move quickly to X and Y axis endstops and stop there (first pass)
G1 X5 Y5 U-5 V5 W-5 F3600 H2         	; go back a 5 mm
G1 Y-10 X-10 U10 V-10 W10 F360 H1 			; second pass
M98 Phomez.g			; call homing script for Z axes
G90

Mapping Z

M584 X0 Y2 Z5:6 U1 V3 W4

Endstops for Z:

M574 Z1 S1 P"!duex.e2stop+!duex.e3stop"

I have set the voltages for the Z motors as:

M906 X950 Y1050 Z950:950 U950 V950 W950 I30

Is this ok? not sure how else i can do it if two motors, same axis, two endstops...

MaracMB

@Phaedrux
rats nest:
https://drive.google.com/file/d/1XQcPBchHubw7k9XG6YlcQA89s1ovAu4-/view?usp=sharing

new VIN
https://drive.google.com/file/d/1PnsclKfqTyVa3TaVUyYYShSjggaT2_Y3/view?usp=sharing

the IDE is already as short as possible. in given circumstances.

is this just too much for Duet and will i have to use some other platform?

if you notice that Duex is not as it should be, it's because i fried two of them already and i am NOT frying another original until this is done. Money does not grow on trees. I am a landscape architect, i would know such tree...

MaracMB

@dc42

even with split Z axes, it fails.

G91               		; relative positioning
G1 H2 Z5 F600
M584 Z5 A6 P7				;split
G1 Z-405 A-405 F900 H1
M584 Z5:6 P6
G1 Z3 F900				; lift both Zs to 3
G90					; absolute positioning

this is M122 after Z homing fails:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2-beta2 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3SN-6J9F6-3SN6L-KUWVG
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 24028
Dynamic ram: 103532 of which 64 recycled
Exception stack ram used: 560
Never used ram: 2888
Tasks: NETWORK(ready,123) HEAT(blocked,294) DUEX(blocked,36) MAIN(running,451) IDLE(ready,19)
Owned mutexes:
=== Platform ===
Last reset 00:04:22 ago, cause: software
Last software reset at 2020-11-05 11:22, reason: User, GCodes spinning, available RAM 2880, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0x04
MCU temperature: min 38.3, current 38.6, max 39.1
Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 0, standstill, SG min/max not available
Driver 1: position 0, standstill, SG min/max not available
Driver 2: position 4800, standstill, SG min/max not available
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0, standstill, SG min/max 0/178
Driver 6: position 0, standstill, SG min/max 0/118
Driver 7: position 0, standstill, SG min/max not available
Driver 8: position 0, standstill, SG min/max not available
Driver 9: position 0, standstill, SG min/max not available
Driver 10: position 0
Driver 11: position 0
Date/time: 2020-11-05 11:27:01
Cache data hit count 412734709
Slowest loop: 17.58ms; fastest: 0.19ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 1.3ms, write time 3.1ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 167, MaxWait: 251856ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 6, completed moves: 6, 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 = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
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
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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 201.99ms; fastest: 0.11ms
Responder states: HTTP(2) HTTP(1) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8

WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 1
WiFi firmware version 1.24beta2-05b1
WiFi MAC address 84:f3:eb:83:45:0d
WiFi Vcc 3.43, reset reason Power up
WiFi flash size 4194304, free heap 23288
WiFi IP address 192.168.0.125
WiFi signal strength -44dBm, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 4 2 0 0 0 0 0 0
=== DueX ===
Read count 3, 1.85 reads/min

MaracMB

this is repeating on sending Home Z.
Sometimes it works, sometimes it does not.

I will leave this here.
https://drive.google.com/file/d/1bWrnUszf52sSI6WxNkiBHYnSRBgFj5J1/view?usp=sharing

I hope you now understand what the problem is. It is the same problem from the start. Now i just isolated it to Z axes.