Independently leveled Z axis Issue
-
@fcwilt Two motors for Y axis, one belt at each end of the gantry. I split the axis up so I can home to each endstop independently. This is so I can square the gantry up to the frame.
My original plan was to run the y axis into the frame, then run it back to a single switch but I was having a hard time getting the senseless homing to work reliably. Another user has sensorless homing working good so I plan on switching to that.
-
@3DPrintingWorld 3.2.2 will home both at same time stopping each at the end stop. There should be no need to do it as you are. At least it works for me.
-
@fcwilt Ok, I'll look into it.
-
@3DPrintingWorld It's the same as described here, except instead of Z, it's X or Y.
-
@3DPrintingWorld said in Independently leveled Z axis Issue:
@fcwilt Ok, I'll look into it.
He is a quick and dirty video I made showing homing of my three Z steppers - I pushed them way out of level first to clearly show the independent axis homing.
My Three Z Steppers Homing Independently
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@fcwilt & @Phaedrux, sorry I forgot that I already tried this but it did not work. Here was the explication from DC.
"On a CoreXY printer, if either the X or the Y endstop switch triggers, all motors must be stopped. Your printer isn't CoreXY, but it has a matrix for which some motors affect more than one axis. If I remember correctly, on MarkForged kinematics, movement of the Y motor causes X (and U) movement too. So when one Y endstop switch triggers, if the other Y motor were to continue moving, it's not clear whether the X and U motors should continue to move if the firmware moves just the other one. That's why the firmware stops all motors when an endstop switch is triggered."
-
@fcwilt said in Independently leveled Z axis Issue:
He is a quick and dirty video
That is really slick looking! What are the sensors for, just to get it close before probing the bed?
-
@3DPrintingWorld said in Independently leveled Z axis Issue:
@fcwilt said in Independently leveled Z axis Issue:
He is a quick and dirty video
That is really slick looking! What are the sensors for, just to get it close before probing the bed?
Exactly.
The best probing speed is quite slow compared to the homing speed.
So I use the endstop sensors for homing to quickly get the bed close to level.
Then before printing I use G32 to level the bed using the probe.
Frederick
-
@3DPrintingWorld said in Independently leveled Z axis Issue:
@fcwilt & @Phaedrux, sorry I forgot that I already tried this but it did not work. Here was the explication from DC.
"On a CoreXY printer, if either the X or the Y endstop switch triggers, all motors must be stopped. Your printer isn't CoreXY, but it has a matrix for which some motors affect more than one axis. If I remember correctly, on MarkForged kinematics, movement of the Y motor causes X (and U) movement too. So when one Y endstop switch triggers, if the other Y motor were to continue moving, it's not clear whether the X and U motors should continue to move if the firmware moves just the other one. That's why the firmware stops all motors when an endstop switch is triggered."
That's good to know.
The fact that by splitting the motors you can achieve your goal suggests that the firmware should be able to do the same when homing using both steppers/endstops.
I may post a firmware request to make this possible.
Frederick
-
@fcwilt Logically, you would think that it would be possible but when I ask DC this was the response.
"It's undefined whether the X and/or U motors should also be moved when moving just one of the Y motors.
The code that decides whether to stop all motors or just one in this instance is the same code that decides whether to stop all motors or just one when you are homing several axes simultaneously. If you were to home e.g. X, U and Y all at the same time, it would still be necessary to stop all motors when any endstop switch is triggered."I you would like to see the entire thread, you can find it here.
https://forum.duet3d.com/topic/17408/dual-y-axis-endstop-homing/20?_=1614738863955 -
@3DPrintingWorld said in Independently leveled Z axis Issue:
@fcwilt Logically, you would think that it would be possible but when I ask DC this was the response.
"It's undefined whether the X and/or U motors should also be moved when moving just one of the Y motors.
The code that decides whether to stop all motors or just one in this instance is the same code that decides whether to stop all motors or just one when you are homing several axes simultaneously. If you were to home e.g. X, U and Y all at the same time, it would still be necessary to stop all motors when any endstop switch is triggered."I you would like to see the entire thread, you can find it here.
https://forum.duet3d.com/topic/17408/dual-y-axis-endstop-homing/20?_=1614738863955Thanks for that link.
When you split out each Y stepper and home again over that very short distance does the X axis continue to move?
Frederick
-
@fcwilt
Yes! Since I'm homing Y+, both the X and the U move in the positive direction as well.Thats why I home X and U first so I can move them away from the endstops so U does not crash.
-
@3DPrintingWorld said in Independently leveled Z axis Issue:
@fcwilt
Yes! Since I'm homing Y+, both the X and the U move in the positive direction as well.Thats why I home X and U first so I can move them away from the endstops so U does not crash.
Thanks. That is what I needed to know.
Frederick
-
I am runinng the same design. I did recently rebuild my X rail with slight preload blocks from hiwin and during test I had strange observation:
During print when Y changes direction U head that is parked performs very tiny small moves. I do not think there is mechanical issue here, and I do not remember that I have seen this month ago when I first comisioned the machine.prf 3.0 -
@martin7404 I tested this, but it was a while back. Maybe still on RRF 2, but it was excellent.
https://youtu.be/BjzmFBKh2jQYou wouldn’t think a preloaded bearing would have a impact since there is only one on the carriage so it shouldn’t be causing any type of bind.
-
@3DPrintingWorld no I do not think it is because of new block, I just noticed it and do not remember it before disasembly. I might be have some binding in belt way where U and Y cross
-
P.s. the only thing I did change in software was the matrix Y1,1,0,1 and the Y mototors direction switched. Still not sure if it was there before
-
@3DPrintingWorld I made the same test. So The dial indicator play about 0.05 mm wen changing Y direction If you do not change Y direction it is dead on 0. When I print with the left cariage the U moves maybe 1 , maybe half a mm left to right and back, just like there is some delay in stepper reaction to counter Y movement
-
@martin7404 Oh wow, I didn't take my test far enough as to look for error as the Y direction changes but if it was that far off you can see it visually.
Are you sure your set screws for that pulley didn't loosen up?
Have updated to 3.2.2? -
Did you double check your motor assignments against the known bug list?
it looks like you have your Y motors on the duex, z on the mainboard and endstops & probe on the main board.
i have same setup and all the gremlins went away once i put all the Z motors on the main board and extruders on the duex.
Most notable caveats are-
"Endstop switches and Z probes connected to the main board cannot control motors on an expansion board. This is planned to be fixed in release 3.4.If you use a Z probe then the Z motors must be connected to the main board. This is planned to be fixed in release 3.4."
