Independently leveled Z axis Issue
-
@fcwilt Sorry, I should have said low current.
-
at 20% current you will be at 14% holding torque.
pair the 14% holding torque with microstepping and you there is little chance of holding a specific position accurately. -
@Veti Holding torque is not required, detent torque and inefficiently of the gears will keep the axis from moving.
Feel free to review this calculator I made in reference to these regards.
https://github.com/3dprintingworld/MULDEX/blob/master/Resources/STEPPER HOLDING POWER CALCULATOR.xlsx -
Just out of curiosity what you are changing the motor assignment in your homeall routine?
Frederick
-
@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
-
@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