After much trouble I managed to build a large format SCARA printer with modified kinematics to allow for a rotational joint at the end of the effector which can be user defined or keeps a set positional angle. This is the first "successful" full print I've had on it so far.

https://www.youtube.com/watch?v=xejWwHR0aig

Based off of this post, I have attempted to edit/add a new kinematics class called 4axisScaraKinematics which is similar to the regular SCARA kinematics but adds a wrist joint.

As of now (I think), the wrist joint is defined by the "E" parameter and the "W" parameter in the M669 command. The "E" parameter specifies the maximum and minimum beta (or wrist) angles which are only use for homing (I think). The "W" command should change the wrist type which is present. W=0 or no W, wrist is in the same orientation as the distal arm: W=1, the wrist has a definable orientation in relation to the x-axis using motor[3]: W=2, the wrist will keep the same orientation as the x-axis. This is done by using multiple an if/if else/else statement to change the calculation depending on what value "W" is.

The main things I am worried about currently are that the kinematics class is not defined anywhere else because I don't know how I would go about doing that.

I have very limited coding experience, so I do no know if it will work or even compile as of yet. I was hoping to receive feedback on what could be changed or if it would even work in the first place.

Here is where you can find the RRF fork, specifically the kinematics class 4axisScaraKinematics.ccp.

I think we understood eachother wrong. I have a DuetWifi 1.04 but I'm using firmware version RRF 3.2.1. haha @fcwilt

I have been developing and building a 4-axis (I think) SCARA arm/3D printer. It has a linear ball-screw driven Z-axis, and 3 joints (proximal, distal, and wrist).

This is the entire machine minus the wrist joint:

This is the wrist joint:

This wrist joint would add the ability to either have the tool always be pointed in the same direction or allow the wrist angle to be set using a 3rd rotational axis which could either use a U axis or a W axis and would allow for a 45 degree hotend and the ability to use the ZHAW slicer and printing using a 45 degree rotating hotend.

This is a concept of having the tool be able to stay in the same orientation/position:

Currently, the wrist joint uses a NEMA11 motor which is mounted to the joint/distal arm to control the position of the joint.

The problem is that I am terrible at coding and modifying the kinematic systems that are already in place. My current change has it so that the wrist joint will always stay in the same position and modifies the SCARA kinematics class which keeps the joint in the same orientation:

//debugPrintf("psi = %.2f, theta = %.2f\n", psi * RadiansToDegrees, theta * RadiansToDegrees);

 

	motorPos[X_AXIS] = lrintf(theta * stepsPerMm[X_AXIS]);

	motorPos[Y_AXIS] = lrintf((psi - (crosstalk[0] * theta)) * stepsPerMm[Y_AXIS]);

	motorPos[Z_AXIS] = lrintf((machinePos[Z_AXIS] - (crosstalk[1] * theta) - (crosstalk[2] * psi)) * stepsPerMm[Z_AXIS]);

	motorPos[3] = lrintf(-1 * (theta + psi) * stepsPerMm[3])

This works for now, but it does not allow angular control of the wrist to my knowledge.

My idea would be to add some other definition to the SCARA kinematics class (I was thinking "W" for wrist) which would allow for the rotation of the wrist joint. A gcode signal in the M669 command which would include "W0" meaning that the wrist joint would hold its orientation in relation to the x-axis, and the "W1" command which would allow for a gcode defined rotational position in relation to the x-axis using the U or W command like a G1 X50 Y50 Z50 U/W90 which would have the tool 90degrees clockwise to the x-axis I believe. A "W3" command could even be used so the tool stays static and has no movement, so it is always in line with the distal arm. Any of the "W" commands could be changed to make more sense this is just my idea.

From my terrible understanding of code it would be something like:

motorPos[3] = lrintf(((-1 * (theta + psi))  + U-Angle Position) * stepsPerMm[3])

Which would keep the tool in the same orientation and then add or subtract the rotational position value.

I don't know how to implement the configuration of the "W" command using code but that is my best attempt at it. How would I/someone go about trying to configure or even make a new kinematics class for this? Help would be appreciated.

@mintytrebor That sounds cool, I'll check it out. Is there anything I should know beforehand and/or a good way to implement the queue system.

@o_lampe The plan was to use the G92 command to "recenter" or home the printer after it had moved to the next position, so it would be something like G1 H2 X(however many degrees you want the offset to be) and then G92 H2 X0.

@nhof That Ultimaker queue feature sounds almost exactly like what I need, the only difference being that I wouldn't have to manually tell the printer to go.

The cool thing about how the arm would rotate is that it could move to a completely unique position where it is impossible for it to interfere with the previous print (depending on the arm and previous print it could be 10-15° away from the previous print). The printer would print in zones to the left or right of the previous one so there really is not need to keep track of zones due to the nature of the machine.

I have recently embarked on a printer SCARA printer which can print in a full circle/donut, meaning that it would be possible to print files one after the other as the arm moves around the circle. I was looking for a way to create a print queue where one print would finish and then another print would start automatically in a different zone of the print area.

As of now I have done some research about the HTML responses that RRF uses to tell DWC what the current status of the printer is. I was thinking that it may be possible to either have some external server which polls the status of the printer, and if the printer is not actually printing, it would send a command to begin the next print in the queue and so forth.

I was also looking at MultiDuetWebMonitor to see if some sort of print queue could be added to that. Has anyone ever attempted something like this and/or is it even possible?

I understand what you mean, I think the problem with the larger hotends is that the thermal mass is larger so there is a bigger delay to the heating so you get the heater error. If there was a way to add some form of time delay after heating starts until the safety mechanism kicks in, it would be possible to fix it.

From my experience, the error happens when the hotend is just starting to heat up (around 30-40C) but after that I do not get the errors (by manually bypassing them)

After much trouble I managed to build a large format SCARA printer with modified kinematics to allow for a rotational joint at the end of the effector which can be user defined or keeps a set positional angle. This is the first "successful" full print I've had on it so far.

https://www.youtube.com/watch?v=xejWwHR0aig

Hello there,
I actually ran into this issue today and managed to fix it. Because it's a larger wattage hotend you have to change the auto PID tune parameters. I used a supervolcano 70-80W and used my auto-tuning as M303 H1 P.6 (the P parameter lowers the PWM signal so it heats up slower during the tune I believe) and it worked well. You may be able to increase the P value to something like .7 or .8 too.

It would be something like:
M303 H1 P.6 or M303 T0 P.6

The W axis is a wrist joint and is irrelevant for this. I'm going to give it a break for tonight and see whats up tomorrow. It could be something to due with mesh bed leveling but I'm unsure. @fcwilt

The G31 command yielded this before and after homing:

G31
Z probe 0: current reading 487, threshold 500, trigger height 2.410, offsets X1.0 Y1.0

but still reports 18.7mm z height after homing when it should be 20.41. @fcwilt

I do need the H2 parameters because it's a SCARA machine. Everything has been tuned and works properly for what I need except the z offset. Also, I don't have to measure it because that's what the firmware says, and when I move to Z0, the hotend is always the same distance above the bed no matter the z-offset so it is being ignored. @fcwilt

I do not have a home.z files as it is impossible for my printer to only home the Z-axis as it is dependent on the other axis being homed. My homeall.g is as follows:

G91							;Relative positioning
M561					;Remove any mesh leveling
G92 W0					;Set Z to 0 (temporary no z stop yet)

G1 H2 Z30 F400
G0 H1 Y-300 X-300 F800		;Move both distal and proximal to home positions
G0 H2 X5 F200				;Slowly turn proximal away from home position
G0 H1 X-10 F200				;Slowly home proximal
G0 H2 Y5 F200				;Slowly turn distal away from home position
G0 H1 Y-10 F200				;Slowly home distal

G90							;Absolute positioning

G0 H2 X-60 Y60 W0 F800			;Move arm to center of range
G30

@fcwilt