[BUG] Polar Kinematics turntable acceleration and deceleration problem

[Melkiyby]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

Turntable acceleration and deceleration does not always work well. One time it can start rotating with smooth acceleration but stop without slowing down, another time it can start rotating without acceleration but stop smoothly. In continuous operation, this behavior causes the turntable to move error with each change in direction of rotation.

Bug Timeline

This is a new bug

Expected behavior

I was hoping it works fine

Actual behavior

It works but with bugs

Steps to Reproduce

1. X,Y=0 -- Move X-1 -> X0
2. X,Y=0 -- Move X-1 -> X1
3. The problem is unstable. You can move in different directions and the problem will show up

Version of Marlin Firmware

bugfix-2.1.x

Printer model

No response

Electronics

BTT Skr-Pro V1.2

Add-ons

TMC2209

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• [x] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

https://youtu.be/wnduQvC414E

Config.zip

[kadirilkimen]

Hi, As the developer of polar kinematics, I verified the issue by running a test with the following g-code on a babyBear polar 3D printer :

G28 XY
G92 E0 Z0 F5000
G1 X-1
G1 X0
G1 X-1
G1 X1
G1 X-10
G1 X10
G1 X-15
G1 X20
G1 X-25
G1 X30
G1 X-35
G1 X0
G1 X10 Y10
G1 X-15 Y-20; This movement doesn't pass from XY Zero. Accelerations expected to be smooth.
G1 X20 Y-25; This movement doesn't pass from XY Zero. Accelerations expected to be smooth.
G28 XY
G92 E0 Z0

The problem occurs when a path passes exactly through point X0 Y0. Y-axis motion starts smoothly but ends with a sudden stop without slowing down.

However, I personally made tens of prints with a lot of lines passes X0 Y0 constantly just like in this video : https://youtube.com/shorts/hO4HH4sqpeg?feature=share

More testing is needed to understand the exact cause of the problem.

[kadirilkimen]

After a lot of tests, I found that both singularity movements and jerk calculations involve in the problem.

I tried several experimental codes to fix the problems. Here are current solutions that seem working.

Jerking: I focused on a workaround for now and it works. May be later I can dive into the marlin jerking calculations and provide a permanent solution. Here is the current solution:

• Set both DEFAULT_XJERK and DEFAULT_YJERK to a very low value like 0.01
• Set DEFAULT_MAX_ACCELERATION to a higher value for X and Y axis
• Enable S_CURVE_ACCELERATION ( it seems the problem was jerking, not the S_CURVE... )

Singularity problem: I added some codes to check if singularity will be a problem. To determine that, codes follows these steps:

• Checks if the movement near to the singularity.
• If so, check if the movement passes thru the origin
• If so, add a little deflection ( 0.005) to avoid origin.

I will perform more tests to see if this solutions are consistent. Then I can make a pull request.

[Melkiyby]

I tried your solutions. They don't work in my case. Especially if the jerks are made very small, then the simultaneous movements along the X and Y axes become jerky and slow.

[kadirilkimen]

There are several things would be affecting the outcome in your case.

You seem marked that you dont use a host software in the issue explanation, but you are using one in the video. It may create custom accelerations and jerkings to perform jogging.

It would help to understand if I know your reduction ratio on the rotating table.

For Jerking part:

Your rotating table feels very heavy compared to the motor you use. Of course, you can keep it slow and make it work.

But it seems you had to set very very very very slow accelerations to make it work. I noticed you also set quite low jerking for X and Y.

Such low acceleration wouldnt work well for a stepper motor. For low feedrates, it can create single steps take very long time. It is normal to experience jerky moves in this case.

To overcome such problem, I think you need to redesign your rotating axis.

I see 3 different way to do that:

• Reduce the mass of rotating parts significantly.
• or increase the reduction ratio at least 2x or 3x to allow the motor to work in higher accelerations.
• or use a motor with at least 2x or 3x torque.

Also, I would recommend you to use belt reduction instead of a gearbox. If your gearbox not a high end one, backlash will be higher than under load.Clearly you have a good load. It seems there is gear noise when it rotates even in such low speeds. It doesnt feel ok. For such gearbox, I would expect noise on higher speeds. If it doesnt work very smoothly, it can increase the effects of the problem.

In the babyBear design; The rotating mass of the axis is about 300gr. It has 7.5:1 ratio belt drive using 39Ncm stepper motor.

I set the accelerations for X to 20K and Y to 10K.

For singularity part: Since I dont know how you avoided singularity, cant comment on it.

I will continue tests and make sure it works good on babyBear. As long as a rotating axis designed to keep the motor in adequate speed, solution would work for it too.

[Melkiyby]

In the video, I simulated my CNC machine at home (motherboard and drivers are identical) so that more experiments can be carried out. The gear ratio of my turntable is 128:1 (5:1 in home simulation), I use a wave gear with an additional step-down module to achieve good resolution farther from the center. The motherboard of my CNC machine has a Wi-Fi module with Esp3D with which I control the movement. I did not notice the difference between RepeaterHost and Esp3D. I tried to remove the singularity with POLAR_CENTER_OFFSET 0.005f. When I configure the firmware to work with linear kinematics, the turntable can rotate stably with an acceleration of 15mm/s^2 and a speed of 40mm/s.

[kadirilkimen]

POLAR_CENTER_OFFSET calculates a movement with an offset. So, it is still possible that a movement can end up on the same infinite line with the origin after offsetting. If the movement very close to the origin, then it still cause the problem.

I coded a workaround for this. It checks the movement just before converting it to polar coordinates. If it is near to the origin and in the direction of the origin, then it deviates the Y coordinate by 0.005 to avoid the problem before converting it to polar.

By this way, we ensure the movement never cross the origin.

Of course, it is still a test code and I have to doore tests.

That alone doesnt provide an absolute solution.

Still jerks has to be handled carefully. I believe Marlin confuses to calculate jerking because of 180degree rotation without taking any distance. There is no other kinematic method causes this. Therefore, probably the jerk calculation needs a different approach, at least for polars.

However, I cant do it right now. May be soon. But for now, I can say, if you can setup ypur acceleration and jerk settings properly, it will work.

Your accelerations are crazy low. I suggest you to set at least 250mm/s2 and find a way to make your machanics work with it.

So far, babyBear rotations become very smooth. I am happy that you brought up this ☺️

I will make a pull request in a few days for the changes. And can share the changes after tests.

Good luck.

[Melkiyby]

Ok. Thank you. I'm looking forward to. ☺️

[Melkiyby]

Hi. What progress with finding and fixing the bug? Maybe you need a beta tester? ;-)

[kadirilkimen]

Hi, I was working on the codes at night of 6th Feb.

It was the same time a big earthquake hit my homeland. I am a Turkish guy and it will take some time for me to recover and back to work.

Although I live in another country, the disaster was devastating and we all Turks are mentally broken right now.

No worries. Will back to work soon and fix it.

[Melkiyby]

Sorry friend. I couldn't know. It's bad when disasters happen. I'm very upset about what happened.

[Melkiyby]

Maybe someone else can help with the fix of this bug?