Is the SCARA algorithm used in marlin correct?

I noticed that the firmware called the kinematic inverse solution of the SCARA robot before calling the plan_buffer_line function, and then assigns the calculated three joint angle values to the plan_buffer_line function.After reading the plan_buffer_line function in detail, I feel that this is wrong.
This is because all the computational algorithmic processes in the function are directed to Cartesian Cartesian coordinate space, for example:

block->millimeters = sqrt(square(delta_mm[X_HEAD]) + square(delta_mm[Y_HEAD]) + square(delta_mm[Z_AXIS]));

This is to calculate the spatial moving distance through the three target coordinates of Cartesian space. If it is replaced by three joint angle values, is this wrong?
The latter algorithm has similar problems, especially the Breasham algorithm in ISR, which is completely an algorithm of Cartesian space. If the value passed to the algorithm is three joint angle values, I think it should be incorrect.
I looked at the code for the marlin 1.1 version and there are similar issues.
I hope that my doubts can be answered, thank you!
My email address: [email protected]

Edited 1 time(s). Last edit at 03/25/2019 04:47AM by dongxuzhou.

hello,
it's been awhile since I have not touched Marlin (1.0) but I remember there are a number of issues:
-pb with manual positioning
-pb of calibration (M-codes + manual pos)
-change to 32bits µC
some explanations here: https://hackaday.io/project/96602-100-high-speed-reprap-3d-printer

I don't understand your problem precisely, I'm not not a programmer and a Marlin specialist, but I remember that all is treated in 3D cartesian plan and then there is a passage in the scara plane (or delta) in the kinematic / inverse kinematic functions (see in in the file Marlin_main.cpp)...

did you make some tests?
how do you notice this problem?

Quote
dongxuzhou
I raised this question after a careful reading of the Marlin and GRBL source code. There is no problem with the kinematics solving algorithm of SCARA. But before applying this algorithm to the Plan_buffer_line function, I feel that there is a problem with the Marlin, so I have been looking for developers to discuss it.
I mainly do desktop manipulator, three degrees of freedom and six degrees of freedom.
This problem does not affect the motion effect of the SCARA type marlin, but it is not correct in microscopic logic, which results in non-Cartesian kinematics in the form of machines that are less accurate than those of the Cartesian coordinate system. Thank you

I have not the level to understand all but that's very interesting; when I started my project there's only one another scara project (morgan) but his creator rapidly stopped developement on Marlin so I was isolated a long time...
it is true that Marlin was developed for cartesian printers and was 'patched' in order to be compatible with other systems that are not optimised for...

I started a development to adapt Marlin on low-cost but high performances STM32 Nucleo Boards; it is not easy task! for now it works with cartesian mode but not with scara config and for now I don't understand why...

Do you think it will be possible to have a true scara-type firmware (Marlin or other) or modify Marlin with specific scara functions (#define) ?

PS: can I put this conversation in the topic forum? (maybe there's Marlin developpers)

Quote
dongxuzhou
I have never been able to contact the main author of marlin. You can of course put the conversation in the forum. I don't know how to contact the original author. I will thank you if you can help me contact the author.smiling smiley
I think it is possible to modify a marlin firmware that is perfectly suited for SCARA or other robotic arm type kinematics. It is mainly to modify the position of the inverse kinematics and the Bresenham algorithm in the ISR to find an algorithm similar to bresenham but suitable for the structure of the manipulator.
Thank you!

a pleasure, thanks to you if we can make progress the scara process...
How did you contact Marlin contributors?
There's several main contributors in the official repositionery (https://github.com/MarlinFirmware/Marlin)
I think that the best way to have answer is to report an "issue" (https://github.com/MarlinFirmware/Marlin/issues)

As I said I don't understand all subtleties of the code but the use of this algorithm in the cartesian plan before move to scara/delta plan seem correct: there's a lot of delta type machines that works fine...?
On my prototypes I didn't notice problems on this point; I maybe have some issues on 'synchronism' at high speed between the 2 motors of the arm because of my specific mechanics but I hope solve that with 32bits computation...

Best regards from France

Edited 1 time(s). Last edit at 03/29/2019 05:55AM by invent2main.

Quote
invent2main
a pleasure, thanks to you if we can make progress the scara process...
How did you contact Marlin contributors?
There's several main contributors in the official repositionery (https://github.com/MarlinFirmware/Marlin)
I think that the best way to have answer is to "pull a request" (https://github.com/MarlinFirmware/Marlin/pulls)

As I said I don't understand all subtleties of the code but the use of this algorithm in the cartesian plan before move to scara/delta plan seem correct: there's a lot of delta type machines that works fine...?
On my prototypes I didn't notice problems on this point; I maybe have some issues on 'synchronism' at high speed between the 2 motors of the arm because of my specific mechanics but I hope solve that with 32bits computation...

Best regards from France

Thank you for your support!
I contacted via GitHub to report the issue, but no one responded,I found the mailbox of one of the managers, but the mailbox did not reply.
I will look at the source code of the delta type machine, I will continue to contact the original author to reflect these questions.
Best regards from China