Scara Setup
-
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.0I 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
-
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.
-
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?
-
With zero X and Y origin offset in the M669 command, X0 Y0 is the location of the proximal joint, and +X is the direction that the proximal arm points at angle zero. So if both arms home to 90 degrees clockwise, then X= -distal arm length and Y= -proximal arm length sounds right to me. This is assuming that you don't have any other arm movement commands in homeall.g after the homing move, and that you have corrected the crosstalk factor to allow for the different steps/mm as we discussed previously.
Please try the following:
1. With power off, set both arms at 0 degrees. This is the position that the firmware assumes at power on.
2. Power on. The web interface should report the position as X= sum of arm lengths, Y= 0. Does it? M114 should report the step counts as zero.
3. Send G91 followed by G1 S2 Y90 to move the distal arm clockwise 90 degrees. Does the web interface report the correct position?
-
With the arms at 0 the printer turns on and reports x = 210.7 y = 0. Lengths of the arms would be 211.8 as defined in config.
I think this happens on this command
maxRadius *= 0.995; Which gives the 210.741
M669 K4 P111.4 D100.4 A-85:85 B-85:85 C-2.37:0:0 S150 T0.1 X0 Y0;
7:52:36 PM
M114
X:210.741 Y:0.000 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 -365 -41 0 User 210.7 -0.0 0.0Sending g91 followed by g1 s2 y90 rotates the distal arm clockwise 90 degrees. The web interface reports x = 100.3 y=89.3. I would expect x=111.4 y=100.4 or something close to this?
-
I can see what's happened. The original position is outside maxRadius, so the firmware has "corrected" it to be within maxRadius as if it were a position commanded by the user, by assuming the distal arm is rotated clockwise a few degrees (hence the motor step count of -41) and the proximal arm is rotated the same number of degrees clockwise. That's why the reported position doesn't agree exactly with the actual position.
When you home the printer, what is the reported position now?
-
11:18:00 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 E6:0.0 E7:0.0 E8:0.0 Count -5695 -2401 0 User 95.2 -58.4 0.0This is with the printer sitting at the homing switches, same as before.
-
Your config says the homing positions are at -85deg for each arm. So by my calculations the position should be:
X = P * cos(85) + D * cos(85+85) = -89.17mm
Y = P * sin(85) + D * sin(85+85) = -128.41mmDo you agree?
I think I see what is happening. When the distal homing switch is triggered, the firmware is setting the distal motor position without allowing for the effect that the proximal motor has on the distal joint position. I'll fix this in the next beta.
As a temporary workaround, try this in your homeall.g file:
1. G1 S1 X… move to home the proximal joint.
2. G2 S2 X85 move to put the proximal joint at zero degrees.
3. Then home the distal joint.
-
There is a point where the crosstalk parameter starts to cause erratic movement. I will wait till I try your new release for further testing.
-
OK, I've just built the new version, so I'll test it with a view to releasing it shortly.
-
Installed new firmware this is results of M114 which is now right.
8:47:37 PM
M114
X:-89.163 Y:-128.423 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 -8092 0 User -89.2 -128.4 0.0Homing then rotating back to 0 angle results in x211.8 y0 which is right. Sometimes says y0.1 ?
OK David very good. I am able to send coordinates that make sense and it draws lines that are close to accurate. Can I expect the robot to change arm positions when just sending g1 commands or will it only work when running files?
-
Once you have homed all axes, it should respond to normal G1 commands from any source. G1 moves will be in straight lines. G0 moves will generally be curved.
-
I knew that was not clear enough question. If I were to command it to move to a coordinate that would require the use of the opposite distal/proximal arm angle should it switch. Also should I be able to manually command it to go to positions past the min radius.
-
If you give it a G0 command that requires an arm mode switch, then it should switch. A G1 command won't because G1 commands are supposed to be straight line movements. However, my own SCARA printer is only capable of one arm mode, so that is untested.
Positions below the min radius or above the max radius are unreachable, so if you command movement to such a position, the destination coordinate will be changed to an achievable position.
-
Just wanted to thank you again for helping with this David. I was able to get things dialed in fairly well using M579 to scale the y axis by 1.06. Further testing needed but I have confidence that this will work for me. Cross talk seems to be working with a value of -1, anything too far away from -1 get out whack? I have test printed (with a pen) a number of cubes rectangles and other shapes and designs with good results. Thanks again.
-
I'm glad it's working for you. From what I understand of your machine, a crosstalk value of -1 should be exactly right.
It should also work on your Duet 06, although the trig calculations will be somewhat slower so the maximum speed and/or segments/sec you can use may be lower.
-
Ok I will switch it back over to the 0.6 and see what happens
-
David
it was interesting to see your Scara project from robotdiggs. I guess I was thinking along the same line and purchased this Scara from robotdiggs.
I have it all wired up and I purchase a Duet wifi which should arrive tomorrow.https://www.robotdigg.com/product/1193/Closed-loop-Stepper-Motor-SCARA-Robot-Arm
-
David
it was interesting to see your Scara project from robotdiggs. I guess I was thinking along the same line and purchased this Scara from robotdiggs.
I have it all wired up and I purchase a Duet wifi which should arrive tomorrow.https://www.robotdigg.com/product/1193/Closed-loop-Stepper-Motor-SCARA-Robot-Arm
It will be interesting to compare our experiences. You may find that you can get rid of the distal arm backlash just by replacing the distal arm belts with ones from the UK supplier that I used for the proximal arm belt, instead of replacing the belts and pulleys by GT2 ones. I suggest you still replace the 20 tooth pulley by a 16 tooth one, to get a higher steps per degree.
Another upgrade I am considering is to replace the proximal and distal motors by 0.9deg ones.
-
Thanks for your comments about backlash, but this model has virtually zero backlash. I'm using hybrid closed loop stepper motors which should be quite accurate for the scara
Have a look at the photo and you can see some initial setup parameters.
Do you have the config file for your current robotDiggs Scara, this might be helpful.
I'm using external driver signals off of the header, how do you reassign these to x y and z.
thanks Dannyhttps://www.dropbox.com/s/27ekssq1lk9ntzd/scara%20robotdiggs.jpg?dl=0
