My quad carriage machine is failing on Tools. AGAIN.
-
@dc42 just to be clear, this was working until saturday. Worked as, it was working, quad was working, tools T1 and T3 needed to have swapped motors mapped for it to work correctly but it did work. It was showcased on E3D facebook page god damnit. It is not that i am making this stuff up. The multicolored prints were showcased on my private Facebook group where 110 people follow and see it. Btw, MarX group. Welcome.
The problem was unreliable homing of tools in between multicolor prints, that resulted incrappyfailed prints. And the events of unreliable homing got increasingly more frequent until it came to a point where it failed so much it stopped the print.So today i reverted to firmware 2.05, then to 3.0, then to 3.1, then to 3.2b1, then to 3.2b2, then reset the config to remap the axes....
NOTHING helped. it is just messed up in different patterns regarding tools. Axes home and work as should. But tools don't.
-
this is only a not so distant memory. The time i miss
-
the topic was first opened here:
https://forum.duet3d.com/topic/19312/duet2-axies-and-tools-motor-mapping-mismatch/2?_=1604425183271 -
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.
-
@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
-
@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.
-
@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
-
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... -
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?
-
@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. -
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
M121Where 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
-
-
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.
-
@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?
-
@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.
-
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
-
-
@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. -
@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...
-
@Phaedrux
rats nest:
https://drive.google.com/file/d/1XQcPBchHubw7k9XG6YlcQA89s1ovAu4-/view?usp=sharingnew VIN
https://drive.google.com/file/d/1PnsclKfqTyVa3TaVUyYYShSjggaT2_Y3/view?usp=sharingthe 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...