Im 100% certain the the rotation distance is correct (matches to cad and real life measurement) - changing these just the tiniest amount into either direction results in either step losses due to too much tension or loose cables when moving.
The anchor points are derived from this here (and also counter measured)
Motors A and B, aswell as C and D connect to a single point on the motion platform.
In my previous configuration the motors were mounted symetrically to the motion axis (±45°).
However, after changing it to the layout in the pictures above, I cant seem to find the issue for the mismatch.
I did change anchor points ± a bit but cant seem to make any sense out of it.
Hi Jan,
what type if winch system do you use? In your layout I can see that the angles of the different motors is not perpendicular to the winch direction in all cases!
Depending on the type of winch system, and the situation of how the cable is rolled or unrolled, it could cause one cable to roll up onto another cable. This would instantly cause a mismatch, but not knowing more about your system it is hard to say from only this drawing. Post some photos please, and even if you think the klippy will not help in solving it, still post your klippy.
Yes, there is no perpendicularity between the axis. Still, the cables are at constant tension through all of the motion range and moves in X result in only X movement and vise versa.
The cables are being “rolled” onto a bigger pulley, it is designed to not overlap on the whole range ov movement (right now im only doing Benchy sized prints on it)
I suspect the answer is simple, current winch kinematic expect slightly different setup.
Hmmm..
You did offset all the anchors from the actual center, so the calculations are screwed now.
The basic fix is to get the mount point on the carriage zero offset and subtract it from the anchor position.
So, the possible fix would look like:
(totally untested)
Hope that helps.
Hmmm.. well, seems like you are already accounting for that offset.
Magic. I doubt that it is a calculation issue.
At least I was unable to find any errors on the paper.
Just WOW, I was not expecting that at all (reaction to that video).
So when you measure your x and y offset. Is this induvidually one at a time or is this in some other situation?
Is there some interaction going on between x and y when you measure this difference ?
I am expecting those axis to have to work together since they are not perpendicular, is that assumption correct?
If you are asking if there is something in the software that would cause that, then I don’t know of anything like that. The calculations for the “winch” kinematics are pretty simple - internally we determine xyz coordinate during moves and then translate them to motor positions using the formulas dx = anchor_x - requested_x; dy = anchor_y - requested_y; dz = anchor_z - requested_z ; motor_position = sqrt(dx*dx + dy*dy + dz*dz). This is done independently for every motor. So, I don’t know of anything in the code that would skew the Y axis.
If you are asking about why the machine hardware may be skewing the Y axis then I guess my first question would be are you sure the Y is actually stretched ~7% more, or is it possible that the Y is just less accurate in general? That is, if you were to print something with a coarse checker board pattern that spanned much of the bed plate, is it possible the Y has some places squished and other places stretched? If the Y is stretched throughout the build plate, is the amount of stretch consistent?
I noticed that your stepper motors have a rotation_distance of 157.1, are 200 steps per rotation (1.8 degree steppers), and you are using 32 microsteps. That is going to be ~24.5 microns per microstep. The error you are reporting is thus in the range of around 28 microsteps. I don’t know if that precision could be related to your issue.
Not a lot of people run the “winch” kinematics, so I haven’t seen a lot of feedback in this area.
So the whole thing of Y doing more than X is across all commands, I’ll attach a picture of a Benchy here. You can see the mismatch best if you look at the roof’s top surface:
But I cant find that Y is just more inaccurate. All commands are beeing completed with the same precision, there is just a scaling factor overlayed.
I tried messing with the anchor points. I can get Y to move as commanded by changing the anchor_Y values. But it is also influencing X movement, which is then all over the place instead.
I cant find values that fit for both axis at the same time. The interesting finding here is that pretty much whatever values I put in, the cables are always perfectly tensioned.
The 32 microstep is due to the MC beeing overloaded. I started my journey with 256 microstepping, and every once in a while I reached a new milestone where the system couldnt keep up with the dataflow. I got a Kraken with H723 processor. A sub 2 minute run in this config is not possible with 64 microstepping, it will crash the software. The eventual sub 1 minute run will be with 16th microstepping for sure. The error will get bigger and bigger but for right now, I cant seem to notice any quality loss in the print due to it. But to answer the question: Im pretty sure microstepping is NOT the cause of this issue here.
In the case of the picture above I did measure it with calippers, the initial measurements were done with a dial indicator pointing at the carriage.
Right now im using a non symetrical layout of the motors. This is grown historically because I have a fixed bolt pattern on the granite of my CMM which im using. In my first iteration all motors were at a 90° pattern - I didnt have the issues there. I plugged the anchor values from cad in and it worked perfectly, resulting in exactly the amount of movement i commanded.
Okay. For what it is worth though, I suspect it will be difficult to track down the root cause with a benchy. If you want my “2 cents”, I’d try printing a large checker board pattern across a large portion of the bed area, and print it at a slow speed. The goal is not to stress the machine, but to see if there is a pattern to the distortion that can give a hint to its source.
FYI, there have been several significant processing improvements to the stm32h7 code in the last couple of months. If you were running into any past performance issues I suggest you update to the latest code and reflash your micro-controller. (I can’t say these improvements will allow you to go up to 256 microsteps, but the recent improvements are significant and there should be no harm in utilizing them.)
My gut feeling as a machine engineer is that the non perpendicularity is not accounted for correctly in the code and is causing the offset.
Can you compare the two setups in your cad and do some angle measurements on it? Then see if Pythagoras had the answer all along? if the length differences at certain positions are approximating your y offset that you measure I think that could be a red flag!
For what it is worth, some things I might look at:
Is it possible that you are hitting the limits of torque on the motors that is showing up as a distortion on Y? Since there is an asymmetric motor pattern, it seems the motors would have more leverage to position the bed at an X position then a Y position. That is, I’d guess the motors would need more torque to hold position (0, 10) than (10, 0). If so, that might cause a distortion along the Y if moving at high speeds/acceleration. One thing I might look for in this case is if lower velocities/acceleration results in less distortion.
Is it possible that the bed is twisting in a way that is causing a distortion in the Y? If I’m understanding your diagram correctly, there is effectively only two “control points” on the bed platform (the strings attach to the bed at effectively just two points). Just thinking out loud - if the bed is moving to a positive Y position that would result in the two “north” steppers pulling string in while the two “south” steppers let string out. If the bed is moving in an arc in a positive X and positive Y direction could a possible difference in motor leverage cause the bed to twist about in a way that has a reproducible distortion? (As different motors are letting string out and pulling string in, could the momentum of the bed want to twist more than it wants to move in XY.) If that were the case, some of the things I’d look for would be a different distortion at low speeds/acceleration, different distortions based on whether layers are applied clockwise or counterclockwise, different distortions at different parts of the bed.
Anyway, just some random guesses. Maybe that sparks some other ideas. I readily admit I do not know what the root cause is.
That is interesting, also since the roof of the measured benchy is at a certain height. Could it be that the change in center point of gravity is causing a twist?
Very insightful observation! We assume the bed is in a fixed plane but riding on strings floating on an airbed this is perhaps not the case!
