Independently leveled Z axis Issue
-
@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."
-
@3DPrintingWorld I have to disassemble to check that with the set screws, but I am sure everything was tightened well. I will have to disassemble . YEs 3.2.2
Muldex IDEX Duet2+Duex5
Custom CoreXY 600x400 Hemera , Duet3+Toolboard+1HCL closed loop
Sapphire Pro with Duet2, with closed-loop motors
custom high temp E3D tool changer with Duet2+Duex -
Here is video U axis moving
-
@sinned6915 said in Independently leveled Z axis Issue:
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."
Thanks for pointing this out, no one has motioned this so far. I have moved the Z motors to the wifi temporarily but didn't see a difference in leveling so I switched it back. I did not realize this was a issue, I will work on permanently moving X and Y to the Duex and Z to the WIFI.
Hey @Guillaume-G, you might like to know this.
-
@martin7404 said in Independently leveled Z axis Issue:
have to disassemble to check that
You should be able to reach the set screws on the drive pulley to make sure they are tight without disassembling anything.
-
@3DPrintingWorld these sre OK. I am thinking sbout the other 8 in x,y,u system
Muldex IDEX Duet2+Duex5
Custom CoreXY 600x400 Hemera , Duet3+Toolboard+1HCL closed loop
Sapphire Pro with Duet2, with closed-loop motors
custom high temp E3D tool changer with Duet2+Duex -
@3DPrintingWorld said in Independently leveled Z axis Issue:
@sinned6915 said in Independently leveled Z axis Issue:
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."
Thanks for pointing this out, no one has motioned this so far. I have moved the Z motors to the wifi temporarily but didn't see a difference in leveling so I switched it back. I did not realize this was a issue, I will work on permanently moving X and Y to the Duex and Z to the WIFI.
On my three Z stepper printer running 3.2.2 on a Duet 2 WiFi/Duex 5 combo, I have the Z steppers on the Duex 5 and the Z probe with auto bed leveling works fine.
You saw the video and you can clearly see the bed leveling movement after the first pass of Z probing.
Frederick
-
@fcwilt I think we know it can work as it works on yours, mine for six months, and on other builders of the Muldex but according to this documentation its not supported so I would like to eliminate the chance that it could be causing the issue.
