Scara Problem

JoergS5

We've all focused on the stuff happening along X while Y=0.

None of that explains what happens at 3:10 or so in the video, the move from X90Y220 to X60Y220 also draws an arc. An arc that falls outside the printable area as specified by M208. None of the joints are anywhere near a limit.

That's a valid point. Maybe multiple reasons.

My ideas for things to analyze:

the communication log of Simplify3D
belt connection between steppers and Axes: maybe slipping or other problem. Slipping belt could explain curves at strange positions. => one more idea: maybe acceleration and speed too high, so belt starts slipping. You can test setting speed and acceleration lower

Is it a toothed belt or a non-toothed one? If it doesn't have teeth, you can check whether the belt slips at the stepper pulley when the printer makes a curve. The pulley itself could slip also (pulley on the stepper axis). You use a method which I know as ServoBelt, this produces high tension, needs high torque and may lead to slipping pulley.

@Mauxx which Duet hardware, firmware versions are you using?

Mauxx

Scara give same issue also with Arduino IDE and with RepetierHost draw a Triangle...

I'm sure the belt doesn't slip, i have GT2 toothed Belt

I'm using RRF Lpc on Skr V.1.3 board

When printer draw arc Y motor doesn't move at all

JoergS5

@Mauxx Maybe the scara code is another one than I checked, because I looked into David's code. Where did you download your firmware RRF LPC code? I will check it then.

JoergS5

@Mauxx said in Scara Problem:

Scara give same issue also with Arduino IDE and with RepetierHost draw a Triangle...

I'm sure the belt doesn't slip, i have GT2 toothed Belt

What do you mean with triangle?

Mauxx

When i start print, instead a cube (only in central area) it draw a triangle (half cube)

JoergS5

@Mauxx I don't understand it, do you have an image?

But more important is, which software you are using, so I can check the source. Do you use the sdavi CoreLPC4 port?

Mauxx

@JoergS5 Thank you very much!!!

for the moment I own Skr Board but am willing to buy a Duet
I just wanted to verify that everything worked properly
I practically tried all the firmware (marlin, smoothie) and RRF is the best !!!

Mauxx

@JoergS5 i'm using this https://github.com/sdavi/RepRapFirmware/releases/tag/LPC_RRFv2.04

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.