#- (hash) printer with super simple gantry

[o_lampe]

@o_lampe said in #- (hash) printer with super simple gantry:

With multi-stream gcode coming up, I hope the Duet team will also introduce multi z motors (mini z-axis on the tool to adjust z for each nozzle individually)

@dc42 and duet team
I just had an idea how to split z-axis adjustment (mesh levelling) from regular z- moves (layer change) for the soon_to_come mini Z-axis:

A gcode line that doesn't have a Z-move applies mesh levelling to the mini-Z motor
A gcode line with z-move applies the motion to the regular Z-motor(s)

[o_lampe]

I designed a new carrier, now with two small V-wheels and the dual roller in between. It's also closer to the smooth rod and supported from both sides (always practice what you preach)
I think it will not bend under tension as before.

Printer is still busy spitting out all the carriers, I decided to use 0.2 nozzle against 0.8 for finer details.

[o_lampe]

1st. sign of life today
I've finished printing parts, assembled the top frame and installed the first stepper. Did some slowmo and superfast (500mm/s) moves without seeing any issues.

Even the belt has got some 'aramid'

I will only have two endstops for all the axes, they are IR beam brakers and home to the center of the bed.

Next step: install all steppers and make some basic toolholders.

[mrehorstdmd]

@o_lampe How are you handling the cable at the motors? I tried a corexy mechanism with cable drive and eventually gave up on it as too difficult to maintain. Part of the problem was getting sufficient tension in the cable to have adequate friction with the drive pulleys. You can't just let the cable wind on top of itself as that will get noisy and lead to imprecision in the mechanism. In order to get precision and quiet operation you have to ensure that the cable doesn't wind on top of itself or walk across the drive pulley as the motor turns. I used motor mounts like this:

The steering pulleys prevent the cable from overlapping on the motor pulley and provide a consistent location for the cable that doesn't change with position of the carriage.

The crappy little pulleys I used clattered loudly in operation, but the biggest problem I ran into was maintenance. Once you let tension off the cable so you can take things apart or make adjustments, the cable comes off all the pulleys. It's quite difficult to get it back onto all the pulleys at once without a second or even third set of hands to move the cable around.

I also found that cable stretches quite a bit, especially compared to a belt- that may be a problem for achieving precise motion.

[o_lampe]

@mrehorstdmd
I remember we had the same discussion a few years back, which resulted in my 'cloverleaf drive" tests.

But this time I only replaced the unused belt-part with aramid line. Truth be told, I had a few pieces of GT2 belt, but they were too short, so...

[mrehorstdmd]

@o_lampe oh yeah, I remember now. Never mind...

[o_lampe]

First Toolholder for an E3D heatsink. I can add a sherpa mini or bowden extruder.

[o_lampe]

I've installed two beam braker endstops and wrote homing files.
They work fine, when called independently, but using homeall throws an error. "Failed to enable endstops"
Here's a homing file (check out, how I define/invert and delete the endstop)

; homeU.g
M574 U2 S1 P"Xmax"   ; change endstop
M400
G91              ; relative positioning
;G1 H2 Z5 F6000   ; lift Z relative to current position
G1 H1 U295 F6000 ; move quickly to X axis endstop and stop there (first pass)
M574 U2 S1 P"!Xmax"   ; change endstop
M400
G1 H1 U29 F360  ; move slowly to x axis endstop once more (second pass)
G92 U0

;G1 H2 Z-5 F6000  ; lower Z again
G90              ; absolute positioning
M574 U2 S1 P"Nil"   ; delete endstop
M400
G1 U-130 F24000

Homeall just calles all macros one by one, so where's my mistake?

; homeall.g
; called to home all axes
;
m98 p"homeX.g"
m98 p"homeY.g"
m98 p"homeU.g"
m98 p"homeV.g"
;G1 Z5 F100           ; lift Z relative to current position
G90                  ; absolute positioning

RRF3.3.0_6 on a F407ZG controller

Here's a pic of the endstop with the extra cutout

[cosmowave]

@o_lampe what's in your other home macros? Can you please post them?

[o_lampe]

@cosmowave they're almost the same, except the specific parking positions and neg/pos signs of the homing moves.

; homeV.g
M574 V2 S1 P"ymax"   ; define endstop
M400
G91              ; relative positioning
;G1 H2 Z5 F6000   ; lift Z relative to current position
G1 H1 V-295 F6000 ; move quickly to Y axis endstop and stop there (first pass)
M574 V2 S1 P"!ymax"   ; invert endstop
M400
G1 H1 V-29 F360  ; move slowly to Y axis endstop once more (second pass)
G92 V0

;G1 H2 Z-5 F6000  ; lower Z again
G90              ; absolute positioning
M574 V2 S1 P"nil"   ; delete endstop
M400
G1 V170 F24000

; homeX.g
M574 X2 S1 P"Xmax"   ; change endstop
M400
G91              ; relative positioning
;G1 H2 Z5 F6000   ; lift Z relative to current position
G1 H1 X295 F6000 ; move quickly to x axis endstop and stop there (first pass)
M574 X2 S1 P"!Xmax"   ; change endstop
M400
G1 H1 X29 F360  ; move slowly to x axis endstop once more (second pass)
G92 X0

;G1 H2 Z-5 F6000  ; lower Z again
G90              ; absolute positioning
M574 X2 S1 P"Nil"   ; delete endstop
M400
G1 X-185 F24000

; homey.g
M574 Y2 S1 P"ymax"   ; change endstop
M400
G91              ; relative positioning
;G1 H2 Z5 F6000   ; lift Z relative to current position
G1 H1 Y295 F6000 ; move quickly to Y axis endstop and stop there (first pass)
M574 Y2 S1 P"!ymax"   ; change endstop
M400
G1 H1 Y29 F360  ; move slowly to Y axis endstop once more (second pass)
G92 Y0

;G1 H2 Z-5 F6000  ; lower Z again
G90              ; absolute positioning
M574 Y2 S1 P"Nil"   ; delete endstop
M400
G1 Y-174 F24000

[cosmowave]

@o_lampe I'm not sure if the command M400 after setting/deleting the endstop will work correctly!? Perhaps it helps to change it to a short delay with G4?

[o_lampe]

that's funny: I send m98 P"homeall.g" and no error pops up, I reset the printer and send "G28" and the error is back.

@cosmowave m400 or g4 p100 made no difference, G4 only slows things down

[fcwilt]

@o_lampe

Just out of curiosity why do you need to change the way the endstop works between the first and second pass?

Frederick

[o_lampe]

@fcwilt
there's a cutout at the center of the tongue that triggers the endstop during the slow pass.
The first pass detects the left or right edge of the tongue, then I invert the logic of the endstop and do the second pass. That way both tools set their homing point to the center of their tongue.
It's not mandatory to do it that way. Later, I have to fine tune the 0,0 position of every tool anyway.

[fcwilt]

@o_lampe said in #- (hash) printer with super simple gantry:

@fcwilt
there's a cutout at the center of the tongue that triggers the endstop during the slow pass.
The first pass detects the left or right edge of the tongue, then I invert the logic of the endstop and do the second pass. That way both tools set their homing point to the center of their tongue.
It's not mandatory to do it that way. Later, I have to fine tune the 0,0 position of every tool anyway.

Could you arrange homing so that the sensor was not triggered after homing was complete?

If so it would seem you could connect the sensor to two different inputs and not have to deal with changing the endstop settings.

Frederick

[o_lampe]

@fcwilt said in #- (hash) printer with super simple gantry:

connect the sensor to two different inputs and not have to deal with changing the endstop settings.

Sounds, like it would provoke false triggers to the not_homed axis or raising a endstop hit flag ?
The correct way seems to be to completely undefine the endstop to make it usable for the next tool.

[fcwilt]

@o_lampe said in #- (hash) printer with super simple gantry:

@fcwilt said in #- (hash) printer with super simple gantry:

connect the sensor to two different inputs and not have to deal with changing the endstop settings.

Sounds, like it would provoke false triggers to the not_homed axis or raising a endstop hit flag ?
The correct way seems to be to completely undefine the endstop to make it usable for the next tool.

Well unless there is a G1 H1 move underway for a given axis I've never seen endstop activation have any effect.

Though I think I will do some tests just for fun.

Frederick

[o_lampe]

Another update.
I thought the triple Z-axis/bed frame would be a piece of cake to build, but it was tricky to find a place for steppers and belt-idlers.
It ended up in an ugly mess, but I'd have to redesign almost the whole printer to get it right. It's working, so I keep it as is until I find a real reason to rebuild it.
Pretty compact carrier

Top view. All tools are outside of the bed, which will be mounted above the frame. The 500x500 outside dimension shrinks to 300x300 working area, but that was expected.

The third Z-stepper needs an appendix to clear the tool path and still stabilize the far end of the cantilevered bed frame.

[o_lampe]

I want to design a tripod bed mount where the bed rests on three ballstuds sliding on dowel-pins to allow temp-expansion.
I"ve seen this on other printers, but I'm unsure about the angles of the dowel pins?

Q: Should they aim to the bed-center, or should I place them at equal angles?
Here's a sketch of the angles in question

[o_lampe]

I went for Maxwell temp-expansion layout, simply because I couldn't make up a way to fix one side without melting the bracket.
Now I've used Haydn's ballstuds and 4mm PTFE tube as dowel pins. I guess that PTFE keeps the heat away from the brackets, better than (stainless) steel dowel pins.

I also filled the PTFE tube with pieces of wooden toothpicks to avoid sinking balls (pun intended)

PS: magnets will arrive monday, I hope they fit in their pocket.