Haq XY

Haggan90

@dc42 Huh, it actually move towards me, in the -Y direction!
I tried to push the <Y-10 afterwards and both U and X moved superfast (like 400mm/s) at diffrent direction, around 50mm. X at - and U at +.

Why do you think the matrix is wrong?
It works just as it should work when using the toggle buttons (or what they are called at the "Machine Control")

dc42

@haggan90, I think the matrix may be unconventional, but valid. To make it conventional, you could change S1 to S0 in your M569 P1 line (to reverse Y motor direction), and change the M669 command to:

M669 K0 Y-1:1:0:1

Your X and U axes appear to be affected by the Y motor in opposite directions, so I guess you have one of those carriages attached to the front of the its belt and the other one to the back of its belt, or something like that. But it doesn't matter, as long as all the axes move correctly in response to the jog commands.

I've implemented a fix for the bug that I think I found, however I also want to fix it so that if you try to move X or U, it also energises the Y motor to lock it; and if you do a diagonal homing move then it energises the X and U motors to lock them. So I'll implement that tomorrow, test G29, then make a new binary available.

Meanwhile, I think most things should work if you home the axes individually, doing Y before X and U.

Haggan90

@dc42 I just reversed the Y motor and when I do G1 X10 F1000 S2 the Y axis moves in the right direction (+10).
But I've noticed a new thing when homing.
This is my homeall.g now:

G91 				; relative positioning
G1 Z5 F6000 S2 			; lift Z relative to current position
G1 S1 Y550 U540 X-540 F2500 	; move quickly to Y axis endstops and stop there (first pass)
G1 S1 Y550 F2500		; Home Y seperate
G1 S1 X-540 F2500		; Home X seperate
G1 S1 U540 F2500		; Home U seperate
G1 Y-5 X5 U-5 F2000		; Go back 5mm on all axis
G1 S1 Y550 F600			; slowly home Y
G1 S1 X-100 F600		; Slowly home X
G1 S1 U100 F600			; Slowly home U

G90				; absolute positioning

G1 X300 Y310 F2500        	; go to first bed probe point and home Z
G30                     	; home Z by probing the bed
G91                    		; relative positioning
G1 S2 Z5 F100          		; lift Z relative to current position
G90                    		; absolute positioning

But when it comes to G1 X300 Y310 F2500 the X axis just smashes into it's endstop.
It seems like both U and X looses their position somehow, or that X and U switches...so X becomes U and U becomes X.

If I manually home Y first and then try to home X the U axis moves.
If I manually home U and X first, their postion is X0 U550.
If I then home Y manually X position is X1100.3 and U is U-560.

Does this make any sense at all?

dc42

I've found a bug in the optimisation of the kinematics calculations. I have just fixed this and my initial tests seem OK. I'd like to run more tests, but it's late now so I will continue this tomorrow. If you want to try the latest binary, it's at https://www.dropbox.com/s/fyvibzm0zl92hiy/Duet2CombinedFirmware.bin?dl=0.

Haggan90

@dc42
I can't wait to try this when I get home from work!
Did you test the G29 in your test rig?

dc42

@haggan90 said in Haq XY:

@dc42
I can't wait to try this when I get home from work!
Did you test the G29 in your test rig?

Not yet, but I hope to get the tests completed this afternoon.

The previous firmware got the positions wrong after homing. It was confusing to debug, because your original M669 command results in a matrix whose inverse was identical to itself! So for some time I thought that the matrix inversion code wasn't working.

dc42

I just did some more tests including G29. It looks to me that it is working properly.

Haggan90

@dc42 Great job! It seems to be working now, only updated the firmware and homing + G29 worked straight away!

dc42

@haggan90, thanks for confirming. I'm sorry it took so long to get it right. They say "premature optimisation is the root of all evil!" and I think there is some truth in that.

Haggan90

@dc42 No problem at all, I'm just thankfull for all the help

Visionary

Can Haq XY-kinematics be used with RRF3/6HC mainboard?
I'm planning on changing from 3-axis (x,y,z) Corexy to Haq XY (x,u,y,z) but I need to be sure there is a working firmware for it. I use 6HC mainboard in my machine so I assume I cannot use binary posted several post above.

dc42

Yes, RepRapFirmware supports any kinematics for which the movement of each axis is a linear combination of the movement of the motors.

RootCNC

Hi everyone,

Are you able to share how you set this up? I'm currently knew to RepRap Firmware, as I'm a long time user of Marlin but due to the fact Marlin doesn't support this type of configuration. I'm currently looking to move over to RepRap Firmware and purchase a Duet 3 6HC board.

I've actually already built this printer, photos attached. Its still got a little bit of work todo and due to the nature of Duet, Reprap and the open source community I intend to share this project among my other projects (Root CNC).

I would much appreciate any help on configuring this type of kinematics as it looks like I'll be taking a big leap into the world of duet and RepRap firmware and I hope it'll soften the blow.

appreciate the help!

Thanks in advance! Pete from Root CNC

Haggan90

@RootCNC Hi,

Sure I can share how to set it up.
But I'm having a hard time understanding how you route your belts to make it a Haq-XY kinematics?

RootCNC

@Haggan90

Ah sorry about that - Please see this photo.

I currently have two motors driving the Y axis - these shall be configured in a series configuration.

then two independent carriages driven from independent steppers.

Does that help?

Thanks

Haggan90

@RootCNC Aha I see!
I routed my 2 X belts on the same route but at different heights instead
And I used one stepper for the Y axis but with a rod connecting both sides of the Y axis.

But the kinematics are exactly the same.

Btw, are you stepper mounted in the bottom with rods going to the top?

RootCNC

@Haggan90

Yeah, to keep its low profile and symmetrical I went this way with the belts.

I plan in the future to try a heated chamber, so keeping the motors below the 6mm plate seemed a good idea.

I just purchased my Duet 3 and LCD, hopefully it'll turn up soon and then we can get this printer moving!

Was the setup difficult?

MaxGyver

@Haggan90 said in Haq XY:

@dc42 I just reversed the Y motor and when I do G1 X10 F1000 S2 the Y axis moves in the right direction (+10).
But I've noticed a new thing when homing.
This is my homeall.g now:
G91 				; relative positioning
G1 Z5 F6000 S2 			; lift Z relative to current position
G1 S1 Y550 U540 X-540 F2500 	; move quickly to Y axis endstops and stop there (first pass)
G1 S1 Y550 F2500		; Home Y seperate
G1 S1 X-540 F2500		; Home X seperate
G1 S1 U540 F2500		; Home U seperate
G1 Y-5 X5 U-5 F2000		; Go back 5mm on all axis
G1 S1 Y550 F600			; slowly home Y
G1 S1 X-100 F600		; Slowly home X
G1 S1 U100 F600			; Slowly home U

G90				; absolute positioning

G1 X300 Y310 F2500        	; go to first bed probe point and home Z
G30                     	; home Z by probing the bed
G91                    		; relative positioning
G1 S2 Z5 F100          		; lift Z relative to current position
G90                    		; absolute positioning
But when it comes to G1 X300 Y310 F2500 the X axis just smashes into it's endstop.
It seems like both U and X looses their position somehow, or that X and U switches...so X becomes U and U becomes X.

If I manually home Y first and then try to home X the U axis moves.
If I manually home U and X first, their postion is X0 U550.
If I then home Y manually X position is X1100.3 and U is U-560.

Does this make any sense at all?

@dc42

I am still having this bug, even after updating from the latest beta to 3.2 stable.
When I home one axis, the other two lose their position. Although I think the correct axis are moving when they are homing.

Visionary

@MaxGyver

I had problem where when doing homing U and X axes lost position during all axis homing. Those axes moved against endstops and lost steps/belt skipped.
This was because homeall.g included wrong move type: 1 motor move -type move (H2-command)
I switched it to H0. I think that you are also suppose to use H-command instead of S-commands.

check: https://duet3d.dozuki.com/Wiki/Gcode#Section_G0_G1_Move

My corrected homeall.g

; Haq xy homing, U and X axes concurrently, Y axis after that and Z axis last
G91
G1 H2 Z7 F200 					; raise head 7mm to keep it clear of the bed
G1 H1 X-405 U405 F3000 			 ; coarse home X and U
G1 H2 X5 U-5 F600              ; move 4mm away from the homing switches
G1 H1 X-10 U10 F600           			; fine home X and U
G1 H1 Y-420 F2000
G1 H0 Y5 F600
G1 H0 Y-5.5 F600
G1 H1 Z-380 F360                ; move Z down stopping at the endstop
G90

MaxGyver

@Visionary
Would you do me a favour and post your config file? I think with my setup there is more wrong than just the homing file.

-Cheers
Max