Scara Setup

Billhc83

Hello,

I am working on setting up a scara type arm with RRF. I am having a couple problems which I am not sure about at this point and am looking for a little direction.

Firstly when I home, both Proximal, and Distal arms home properly to the endstops, although they put up move errors. The z will not move when I try to home, and no other manual moves will work. I have an opto switch connected to the z probe connection. I have also tried it with the switch at the z endstop position without success. The endstop is triggered by the bottom of the z carriage. I have no attachments or print heads for now just trying to have motion work atm.

G28 Z
Attempt to move the head of a Delta or SCARA printer before homing the towers

Attempt to move the head of a Delta or SCARA printer before homing the towers

G28 Y
Attempt to move the head of a Delta or SCARA printer before homing the towers

Attempt to move the head of a Delta or SCARA printer before homing the towers

G28 X
Attempt to move the head of a Delta or SCARA printer before homing the towers

; File homez.g
G91 ; relative movement
G1 Z4 F200 ; raise head 4mm to ensure it is above the Z probe trigger height
G90 ; back to absolute mode
G30 ; lower head, stop when probe triggered and set Z to trigger height

this is what I have copied and pasted from the wiki for the homez file.

I am also wondering about the c parameter in the m669 command. This is, from what I gather, where I would put factors for amounts that the distal arm moves when the proximal arm moves? I have tried a variety of values here without change in function.

I am trying this on a 0.6 duet I had sitting here. Running FW 1.19 and DWC 1.19. I could not get it to upgrade to the newer beta versions of the FW. It would neither upload via the web interface nor via bossac. This is my config:

; General preferences
M550 scara ; Machine name (can be anything you like)
M551 Preprap ; Machine password (used for FTP)
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0x42 ; MAC Address
;*** Adjust the IP address and gateway in the following 2 lines to suit your network
M552 P192.168.1.118 ; IP address (0 = use DHCP)
M554 P192.168.1.254 ; Gateway
M553 P255.255.255.0 ; Netmask
G21 ;
G90 ;
M208 X0 Y0 Z0 S1 ;
M208 X300 Y300 Z380 S0 ;

; Endstops
M574 X1 Y1 Z1 S1 ;

; Drives - Axis and motor configuration
M569 P0 S0 ; Drive 0 (X) goes forwards
M569 P1 S1 ; Drive 1 (Y) goes forwards
M569 P2 S1 ; Drive 2 (Z) goes forwards
M569 P3 S0 ; Drive 3 (E0) goes forwards
M92 X80 Y50 Z400 E550 ; Set steps per mm
M566 X300 Y300 Z15 E75 ; Set maximum instantaneous speed changes (mm/min)
M203 X1000 Y1000 Z300 E1500 ; Set maximum speeds (mm/min)
M201 X300 Y300 Z250 E800 ; Set accelerations (mm/s^2)
M906 X1200 Y1200 Z1000 E1000 I60 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout
M669 K4 P110 D100 A-0:175 B-0:175 C3:0:0 S150 T0.1 X85.0 Y-150.0;

I am also slightly confused about the m92 values for x and y I have based them on the 10 degree secondary movement in the homeproximal and homedistal files. If I were to calculate what I think they should be the numbers would be of a higher value. But this is of no consequence, whatever works.
Any help would be appreciated.

Edit
After re-reading the wiki in not certain about the p and d parameters one place it says arm length and in another it describes angles for homing?

dc42

Hi Bill,

1. Add parameter S2 to the G1 Z commands in your homing files. This will allow movement (as long as you have used G91 to put it in relative mode) before everything is homed.

2. The P parameter is the proximal arm length (distance between proximal joint and distal joint), and the D parameter is the distance between the distal joint and the nozzle. Thanks for pointing out the errors on the wiki page; I've just corrected them.

3. The C parameter is for machines like the Helios where the proximal motor affects the distal joint angle as well as the proximal joint angle. If the proximal motor doesn't affect the distal joint angle, you don't need it.

4. Which beta firmware did you try to upload? Check that you downloaded the correct file, it should be more than 300kb in size. Github makes it easy to download the web page that describes the binary instead of the binary.

HTH David

Billhc83

Hello David

Thank you for the info.

It was late when I was trying to update the firmware and I was making a mistake in the process. I have successfully updated to beta 6 via bossac.

Regarding the A and B parameters are these angles with reference to the home switches ie/ 0 would be at home and 180 would be at max range if you have 180 degrees of motion? Or is it with reference to the x axis ie / the proximal arm may move from 0 to 180 but the distal will move -90 to 90? ( if you can't tell I am touch confused about this…lol)

The C parameter. On my arm a 90 degree rotation of the proximal arm toward the x axis (clockwise) will rotate my distal arm 90 degrees counter clockwise. Is this giving me a value of -1?

dc42

For the proximal joint, 0 degrees is where the proximal arm points along the direction you want for the the X axis. This would typically about the mid point of the travel of the proximal arm.

For the distal joint, 0 degrees is where the proximal joint, distal joint and nozzle are all in line.

A C factor of -1:0:0 should be correct for the configuration you describe. However, I haven't had access to a SCARA printer that needs any nonzero C factors to test the firmware with, so I won't be surprised if you find bugs in that area.

Billhc83

Thank you David.

I believe I would need values of A -90:90 and B-90:90 if I understand you correctly.

Things are homing correctly now I beleive. Which is great thank you.

The arm I am using has the same mechanics as this one https://www.thingiverse.com/thing:1241491

I am going to try a gcode file of movement and see what happens. Thanks for the help.

Billhc83

So I am at the point where I think there may be a problem with something.

I can home XYZ.

I am homing X and Y all the way to the left (clockwise) then bring the arms back around so they are in line. This is what I am doing in Homeproximal and homedistal files. Firmware reports position x -74.4 and y 163.5

Homez lower till I hit endstop then raise up 10mm. firmware reports z 10mm.

If i do g91 to set relative moves then do G1 S2 X10 f2000 This seems to move the axis 10 degrees as i believe it should, this works with both x and y.

If I go back to absolute with g90, and do G1 S2 X45 f2000 from the home position (when the arms are straight in line) i expect that the proximal joint will rotate 45 degrees counterclockwise which it does, and if i then do G1 S2 X-45 f2000 I rotates the arm back to -45 degree angle (90 degrees of movement).

But now if I rotate the distal arm the firmware does not know where it is as it has rotated when the proximal arm moved. If starting from 0, I were to move the proximal axis +45 degrees G1 S2 X45 f2000 (which would move the distal arm angle to -45 degrees) then try to move to say G1 S2 Y-50 f2000 (which I think should move the distal to 50 degrees) the arm just crashes through the endstop as I think it is actually trying to go to 95 degrees which is not a reachable position.

Billhc83

A couple other things

If i was to home the y axis before the x axis this causes my distal arm to crash into the belts because it is not free to move as the proximal arm homes and is rotating(depends on the position the arms start in). and is locked in place by the holding strength of the motor.

If I use the jog buttons after homing this causes the arms to crash, the proximal moves cw while the distal move ccw (even if i just jog the z the arms decide to crash). Similar thing happens when I try to print a file of moves. I Think there may be some maths somewhere that is not getting done???

dc42

If you delete the homeproximal.g, homedistal.g and homez.g files then it will use homeall.g when you send any homing command. That is what I did on my SCARA printer, because the homing order is critical on that too.

G1 S2 X moves should move both motors if you use the correct C parameter, so that the distal joint angle (not the arm angle) remains constant. For example, if the arms are in line initially, they should remain in line when you do a G1 S2 move. Is that not happening? I'll check the code when I am back in the office.

The XY position when you have both arms in line sounds wrong to me. If you had both joint angles at zero and no X or Y offset in the M669 command, you should have Y=0 and X= sum of the arm lengths.

Billhc83

The arms are not staying inline when I do a x move. I have tried a number of values for c.

My M669 has a xy offset. I will remove that when I get back to it and see what it says.

Billhc83

After removing XY offset the web interface reports x11 y13 when the arm is rotated to the 0 angle( both arms in line in the middle of the movement range)
Here is a video of the behavior of a g1 s2 x move after homing. as you can see the distal angle does not remain the same. I believe the C parameter in the video was set to -1 I have tried a variety of values without any change.
https://youtu.be/vuMC6BDucdE)

Another video showing homing behavior and crash after using jog button
https://youtu.be/8wLSmmAf0dg

dc42

I was wrong about G1 S2 moves. These moves are defined as raw motor moves. So it is correct that the distal joint arm angle changes when you do a G1 S2 X move.

During proximal homing, to avoid the possibility of the distal joint reaching the end of its travel, I suggest you command both motors. For example:

G91 ; relative movement
G1 S1 X300 Y-300 F3000 ; home proximal joint

One possible issue I can see with this is that the distal endstop switch will be active too, so if the distal arm is at the end of its travel against the endstop switch when you start the homing move, then the proximal homing move will not be completed. You could command a small anticlockwise movement of the distal arm first to avoid this possibility.

In the second video, you pressed the Z-10 button. So it tried to move the arm down into the bed. However, any software axis limits you set with M208 ought to be obeyed.

The x11 y13 position reported after homing is obviously wrong, so I think this explains the unwanted distal arm movement in your second video. Please share your config.g file. Also, please can you home all axes, check that the homing buttons are all blue at the end, and report the output of M114.

Billhc83

After homing all buttons do indeed turn blue. This is the positions of the axis when sitting at the endstops after homing:

11:18:24 AM
M114
X:95.221 Y:-58.365 Z:0.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 Count -5695 -2401 0 User 95.2 -58.4 0.0

The second video was not great At the end when I press the z-10 the arms also moved quickly as well and crashed.

Config:

; General preferences
M111 S0 ; S0 Debugging off S1 Debugging on
M550 scara ; Machine name (can be anything you like)
M551 Preprap ; Machine password (used for FTP)
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0x42 ; MAC Address
;*** Adjust the IP address and gateway in the following 2 lines to suit your network
M552 P192.168.1.118 ; IP address (0 = use DHCP)
M554 P192.168.1.254 ; Gateway
M553 P255.255.255.0 ; Netmask
G21 ; Work in millimetres
G90 ; Absolute moves
M83 ; Relative extrusion
;Limits
M208 X0 Y0 Z0 S1 ; Min
M208 X100 Y100 Z150 S0 ; Max

; Endstops
M574 X1 Y1 Z1 S1 ;

; Drives - Axis and motor configuration
M569 P0 S0 ; Drive 0 (X) goes forwards
M569 P1 S1 ; Drive 1 (Y) goes forwards
M569 P2 S0 ; Drive 2 (Z) goes forwards
M569 P3 S0 ; Drive 3 (E0) goes forwards
M92 X67 Y28.25 ;Steps per degree
M92 Z400 E550 ; Steps per mm
M566 X300 Y300 Z15 E75 ; Set maximum instantaneous speed changes (mm/min)
M203 X2000 Y2000 Z300 E1500 ; Set maximum speeds (mm/min)
M201 X300 Y300 Z250 E800 ; Set accelerations (mm/s^2)
M906 X1000 Y1000 Z1000 E1000 I60 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout
M669 K4 P111.4 D100.4 A-85:85 B-85:85 C-1:0:0 S150 T0.1 X0 Y0;

Billhc83

Davis is machinePos the coordinates reported in the web interface? Trying to work through the math….

dc42

Hi Bill,

One problem I have spotted is that the crosstalk factors must currently be specified in motor steps, not amounts of movement. In other words, your proximal to distal crosstalk factor of -1 means that each forward step of the proximal motor needs to be countered by one reverse step of the distal motor. As you are using different steps/mm for your proximal and distal arms, -1 is not correct for your machine. I think the correct value is -67/28.25 instead.

Thinking about it, it would be more logical to make the crosstalk based on amount of movement instead so as to be independent of the steps/mm. I'll make this change in the next 1.20 beta version.

Billhc83

Ok thanks I'll give it a shot

I think I will try this on my duet Wi-Fi just to make sure it is not just a problem with using the 0.6 board

Billhc83

I agree that cross talk based on movement would be better.

I think there may be a issue with the minRadius calculation (I could be wrong of course). When I input my values into the calculation I come up with a number that I do not believe is correct. Since my scara has limited movement (everything forms a right angled triangle at the limits because it can only rotate 90 degrees from 0) it is very easy to calculate some of the values. For instance the minRadius of my arm I believe is just the hypotenuse of the triangle it forms. I have a value of 150 or so for min radius based on this. When i put my numbers into the code I get a value of 211 or so(I may have done this wrong who know's just trying to pick away at things). My max radius is only 210.8. Let me know what you think about this.

dc42

You are right, the minimum radius calculation is wrong. Thanks for pointing this out. I've just corrected it in the source code and the next 1.20 beta will include the fix. I've also changed the way the crosstalk factors work, to relate the distances moved instead of the motor steps - in degrees for the arms and in mm for Z.

Billhc83

So I have switched everything over from the v0.6 to my wifi and I won't say everything works as expected but everything works. So there is definitely something that doesn't work with the v0.6. Jogging buttons on the web interface do not result in crazy movements, but still not the movements I would expect. Are the jog buttons going to arm move angles or coordinates? I still have not been able to get the proper movements I am expecting. Homing coordinates still do not seem right to me. Homing now reports the same numbers as before

2:38:58 PM
M114
X:95.221 Y:-58.365 Z:0.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 E8:0.0 Count -5695 -2401 0 User 95.2 -58.4 0.0

I am running all the latest firmware and web control files. When I try to print a test file I get a bunch of errors from DWC, and cannot connect until the file is finished. Is there a way to see what the errors say? They seem to go away before I can copy them.

I will keep playing with this now that I can get some movements.

Thanks again

dc42

The error messages that pop up in DWC can be viewed on the GCode Console page. You can also configure how long they remain as popups before they time out.

The jog buttons should jog the XY coordinates.

SCARA support is currently working well on at least 2 printers that do not require crosstalk parameters in the M669 command.

As you are now running on a Duet WiFi, I'll make a pre-release 1.20beta7 release available for you to try when I am back in the office.

Billhc83

As my arms only turn 90 degrees i would expect my home position to be something like x -110 (proximal arm length)y -100(distal arm length). Does this make sense to you?