Scara Problem

JoergS5

@Mauxx Thanks for the code basis. The included ScaraKinematics seems to be the same like in the official code base, so this is propably not the problem.

One possible reason ... (removed, this was not the reason...)

Mauxx

So with a Duet Board i will solve this problem? Great!!!
Which board do you suggest?

JoergS5

@Mauxx I would choose Duet2 Wifi or Ethernet. The new Duet 3 is not needed for the application. The Maestro doesn't have FPU, and floating point algorithms are used in Scara. If you want to experiment a lot in the future, a Duet 3 is an option of course. It is a matter of budget also of course.
I have personally a Duet 2 Wifi and Duet 3+Pi 4 and both are great.

Mauxx

nice!!!
if you tell me that with duet there's no issues, i trust you

JoergS5

@Mauxx I have not tested the Scara, but I give you the following promise: if there is an error in the Scara code, I will help fixing it.

I have created a parallel Scara printer:
https://duet3d.dozuki.com/Guide/Five+Bar+Parallel+SCARA/24?lang=en
and source in
https://github.com/JoergS5/RepRapFirmware
for RRF2, so I have expertise.
Maybe you're interested in building a parallel scara in the future also?

Mauxx

I still don't know if I'll build a parallel scara,
howerver i see @dc42 Scara printer, maybe he can tell us if everything work good?

Mauxx

@JoergS5 Nice work!!!

JoergS5

This post is deleted!

dc42

The SCARA code includes a feature whereby if the start and end points of a non-extruding G1 move are reachable but the move can't be executed because it would pass too close to the proximal axis, the move is silently changed into a G0 move instead. I implemented this feature at the request of another SCARA user. From your video, my guess is that this code is being triggered incorrectly.

What I don't know is whether this problem occurs when running RRF on a Duet, or only in the LPC fork. I've never observed it on my SCARA printer, but I don't use it very much.

The code concerned is in two parts. The most important part is lines 291-304 of https://github.com/dc42/RepRapFirmware/blob/dev/src/Movement/Kinematics/ScaraKinematics.cpp. This determines whether a linear trajectory is possible, by determining whether the closest approach of the trajectory to the proximal axis lies between the start and end points, and if so what that distance is and whether it is smaller than the minimum radius. Perhaps there is an error in this code.

Mauxx

soon I will buy duet wifi or ethernet
thank you all for your support
I really hope you can fix this issue, because the firmware is really cool !!!

@dc42 if you can check it on your Scara, all you have to do is print 3 cubes, one of which must be on the central axis of the print bed

Danal

@dc42 said in Scara Problem:

The SCARA code includes a feature whereby if the start and end points of a non-extruding G1 move are reachable but the move can't be executed because it would pass too close to the proximal axis,

@dc42 Except it also does it when the move is nowhere near the proximal axis. About 3:10 in the video.

Of course, a severe enough error could still cause this behavior. It is interesting to note that all the places that do it (or that I see doing it) fit the "closest approach of the trajectory to the proximal axis lies between the start and end points" case. Hmmm...

@Mauxx I would also highly recommend a genuine Duet 2.

dc42

I think I have found the problem. The calculation of the minimum achievable radius is incorrect. This doesn't show up on my SCARA printer because the distal angle range is B-27:157.5 which results in a calculated minimum radius of 75mm, only a little higher than the true value of 63mm. But you have a distal range that is symmetrical about zero, which results in the minimum radius being calculated as 387mm instead of 107mm. As a result, any line that passes within 387mm of the proximal axis at its closest point will get converted to a G0 movement, unless one of the end points of the line is exactly at the closest point.

I will fix this in the next release. Meanwhile, as a workaround I suggest you use B-149:31 in your M669 command, which will result in the correct minimum radius calculation.

Mauxx

@dc42 Thank you very much David @Danal and @JoergS5 , I followed your advice and set the angles of the Distal B-31: 149 arm (not B-149: 31 because I have Ymax Endstop) and now it works perfectly !!!

Mauxx

@dc42 I was wondering if when you fix the error in the next release, my scara will work like the helios, which manages to reverse the distal arm (like in this video at 0:51 https://www.youtube.com/watch?v=l_FVnIYND4Y ) it would be really cool!!!

dc42

RepRapFirmware does in theory support switching arm modes already, but I can't test it on my SCARA machine because the distal joint doesn't have enough range.

oliof

I believe mine does. How would I test?

dc42

@oliof said in Scara Problem:

I believe mine does. How would I test?

Use a G0 command to command movement to a point that is reachable in the other arm mode but not the current one.