@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.
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 I have modified my config.g to what you suggested:
;Endstops
M574 X1 S1 P"!xstop" ; X min active low endstop switch
M574 Y1 S1 P"!ystop" ; Y min active low endstop switch
M574 Z1 S0 ; configure Z-probe endstop for low end on Z
;Z-Probe
M558 P1 C"zprobe.in" H18 F200 R.5 T3600 # Z-Probe connected to Z-endstop input
G31 P500 X1 Y1 Z2.41
M557 X150:600 Y-450:450 S50 ; probe from X=10 to 190, Y=10 to 190mm with a mesh spacing of 20mm
I have tested this and the offset is still .7mm even though it is defined as 2.41mm. I have changed the dive height (H) and after homing it is always the dive height (H) +0.7mm instead of H + 2.41mm so the trigger height is definitely being ignored.
Currently the z-probe works and activates, it's just that the defined z offset in the G31 command isn't being used and instead defaults to .7mm. I have looked in the RRF source files and can't see as to why it is defaulting to the .7mm
I think we understood eachother wrong. I have a DuetWifi 1.04 but I'm using firmware version RRF 3.2.1. haha @fcwilt
It seems there was another post regarding link text which has to do with using an IR sensor and a defined offset. @dc42 I don't know if this has been changed or not, but I will look in my RRF source to see what is wrong.
I am running into trouble with my z-probe offset. I have my config.g as follows:
; Printer Settings
M669 K4 P376 D376 A-137:110 B0:172 C-1:0:0 X0 Y0 W2 E-180:180 ; Printer class SCARA, proximal/distal length, proximal min/max angle in relation to x-axis, distal min/max angle in relation to proximal arm, crosstalk factor (depends on mechanical setup)
M584 X0 Y1 Z2 W3 E4
M208 X-752:752 Y-752:752 Z0:1270 W-360:360 ; Set min/max positions for each axis
M201 X400 Y400 Z200 E600 ; Accelerations (mm/s^2)
M203 X6000 Y6000 Z400 E3600 ; Maximum speeds (mm/min)
M566 X300 Y300 Z20 E400 ; Maximum instant speed changes mm/minute
;Motor Settings
M569 P0 S1 ; Drive 0 goes forwards
M569 P1 S0 ; Drive 1 goes backwards
M569 P2 S1 ; Drive 2 goes forwards
M569 P3 S0 ; Drive 3 goes backwards
M569 P4 S1 ; Drive 4 goes forwards
M350 X16 Y16 Z16 E16:16 W16 I1 ; Set 16x microstepping with interpolation
M92 X262.2222 Y262.2222 Z800 E700 W65.55555 ; Set axis steps/degree, steps/mm
M906 X1000 Y1000 Z1000 E400 W500 I60 ; Set motor currents (mA) and increase idle current to 60%
;Endstops
M574 X1 S1 P"!xstop" ; X min active low endstop switch
M574 Y1 S1 P"!ystop" ; Y min active low endstop switch
M574 Z1 S2 ; configure Z-probe endstop for low end on Z
;Z-Probe
M574 Z0 P"nil" ; no Z endstop switch, free up Z endstop input
M558 P1 C"zprobe.in" H18 F200 R.5 T3600 # Z-Probe connected to Z-endstop input
G31 P500 Z2.41
;Mesh Bed Compensation
M557 X150:600 Y-450:450 S50 ; probe from X=10 to 190, Y=10 to 190mm with a mesh spacing of 20mm
;Tool Definition
M308 S1 P"e0temp" Y"thermistor" T110000 B4095 H127
M950 H1 C"e0heat" T1
M950 F0 C"fan0"
M563 P0 S"Hotend" D0 H1 F0
M140 H0
G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C
When I run the G30 command to home the z-axis, it does so but instead of using the 2.41mm as I found while manually calibrating it. It sets the z-height to be 18.70, meaning it's using a z-probe offset of .7mm instead of the 2.41 as I've set. This is in RRF 3.2 so I don't know if there are any differences/something wrong.
Would it be possible to just set the beta angle to equal the machine position?
if (wristMode == (1 or 2))
beta = machinePos[3] = (((float)motorPos[3]/stepsPerMm[3]) - theta - psi);
else
beta = machinePos[3] = ((float)motorPos[3]/stepsPerMm[3])
I also don't know if the inverse for wristMode 1 and 2 would be the same, or if there even is a needed inverse kinematic?
@tony73 Currently with the changes, the wrist joint moves and keeps it's position in relation to the x-axis. There is no homing of the wrist yet but the main movement works.
@dc42 I have modified the Github with the modifications you said to make on line 194, could you see if I implemented them how you said?
That seems to have fixed it, changing between the different wrist modes also works. The only thing that still must be implemented is the wrist axis homing but that can come later.
One slight peculiarity is that the wrist snaps to its position on its first movement but that's because it hasn't been homed so I am going to fix that right now.