#- (hash) printer with super simple gantry

[fcwilt]

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

My main intention is to demonstrate the functionality of the dual roller constrain vs extended motor shaft & dual belts of the original design.
It saves me 8 extended shafts and tons of idler rollers.

Do you have a picture of this "original design" with the parts you are trying to not use?

Thanks.

Frederick

[o_lampe]

@fcwilt
No, you'd have to watch the video in slowMotion.
TBH, I'm not sure if there are 8 shaft-extenders in total, but it's definitely a complex setup.

//edit after watching it again, I'm sure you could get away with 4 extended shafts, when you put the idler bearings next to the drive pulleys of the other axis (or on their own shaft)

[fcwilt]

@o_lampe

Thanks for the link - I see what you mean.

Interesting but way too complicated to my way of thinking. It would be a pain to get the nozzles exactly in the same plane.

My approach to a cross-gantry system (just a single tool) uses two steppers per X and Y axis. That would not lend itself to the multi-tool approach as seen in the video.

Good luck and keep us up to date.

Frederick

[o_lampe]

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

It would be a pain to get the nozzles exactly in the same plane.

My idea is to have all idle tooholders parking outside of the bed and adjust nozzle height in the toolchanging macros.
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)
I'd go for a N20 motor with M3 leadscrew on my sliding E3D clamp.

Mockup N20 on e3d slider :

[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.