Posts made by o_lampe

@dwuk said in Sovol SV08 Multiple Motion System Upgrade.:

I think I will try putting them at the front

"Goodby toolchanger" then? Isn't there a way to distribute the steppers to the left and right, keeping the front available for extra tools? Steppers aren't exactly lightweight and you'll need some beefy motors to overcome the friction of the idler pulley-orgy.

I mentioned it before, but my hashPrinter only needed 4 motors for 4 semi-independent toolheads. The super simple gantry was the reason why I built it.

@dwuk One thing I noticed in an earlier picture was some scratching belts:

I thought it was just temporary, but it still seems a problem.

@droftarts said in MMU - Single nozzle, multi material (filament):

it still outputs tool commands (T0, T1, T2 etc) in Gcode, even if you select 'Single Extruder Multi Material'. Not sure, but this might be a PrusaSlicer bug.

I guess the toolchange commands are required for different filament temps, diameter etc...
One can leave the macros empty, if not needed.

@dwuk said in Sovol SV08 Multiple Motion System Upgrade.:

will use sensorless just for testing purposes

Mirror or copy mode should work OK, but optical sensors are the best.

@dwuk Sensorless homing will do for now, but with more and more toolheads involved you'll need perfect homing positions relative to each other.
Otherwise it'll look like that:

@dc42 I lately printed funnel-like adapters for my woodworking machines. Many machines needed wood chip/dust extraction of a different diameter.

@dwuk said in Sovol SV08 Multiple Motion System Upgrade.:

interesting to see whether parallel printing is practical.

I'm sure there is a niche for it, same as for tool changers or MMU-printers. Each system has some drawbacks, here:
Building/commissioning/homing and maintaining perfect z-height will be a nightmare.

My understanding of the dual gcode stream is: you can open two gcode files at the same time and have a daemon.g running in the background?
At the same time you'd have to split the config.g into two portions.
Maybe put the U-axis specific lines in the startcode of the second stream?

@dwuk Having a bowden extruder in the mix makes sense if you want to print infill_every_nth_layer with a bigger nozzle.

@titusou Your extruders are quite short, which was perfect for your first design.
Now, with the XY-frame on top, I'm afraid the nozzles won't reach the bed?

@dwuk Equal belt tension is a critical part for a CoreXY. I hope you are still able to adjust all belts individually.

@dwuk said in Sovol SV08 Multiple Motion System Upgrade.:

about the excenter bearings

They aren't available off the shelf, you just have to use regular bearings and make an offcenter shaft for it.
When the shaft rotates (max 180°) , the bearings translate the offset to the housing where they are pressed in.
That's a much easier task than to overcome the stiktion of linear bearings.

I have a vision of a planetary gear with three planets and a rotating orbit. This would give you a compact, yet powerful setup with a NEMA14 pancake stepper (they often come with a pinion, like the orbiter motors)

@dwuk Whenever I need toothed idlers or gears I choose @droftarts 's openScad pulley library. (don't have the actual link RN)
When I print them on a resin printer (fudge factor settings to 0 ) they are spot on. and with "Anycubic's tough resin" they last very long (almost like nylon gears)

Regarding z-hop: I think you should put it under or on the far side of the 2020 beam. Everything not-toolchanger-related could go there for better balance.
Don't forget an endstop for those hoppers.
The NEMA08 motors are quite weak, they'd definitely need gear reduction. What's the pitch of the mini leadscrews?
The smallest steppers I've used were salvaged from old DVD drives. You can still find them on Aliexpress for pennies, I guess.
The whole lift and bearing thing could probably be done with excenter bearings. (two flys with one clap)

@dwuk said in IDEX BOTH ON CORE XY:

SV08 arrived yesterday and working well.

Next stage now is to swap its normal single extruder operation over to a Duet3 6hc

Maybe now is the right time to start your own build thread? There you can reference your first entry from this thread, for people who want to read the whole prequel

@dwuk Seems you've reached the end of the Duet3 galaxy...
AFAIK there is no toolchanging system which keeps the extruder motor and only replaces the extruder.
Although you can use a MMU like enraged rabbit.

My hashprinter was happy with 11 stepper drivers on a Duet2 (5+2) with DUEX5.
But Duet2 isn't ready for dual g-code streams. Maybe a post processor can make it happen, if it puts all moves in one file.

Hi guys,
I'm not sure if the headline describes the real question, because it's not only related to SCARA.
I want to 2D-probe original parts with an "arm" and read position sensors with SPI interface (a SCARA would have two angle sensors where the motors would be)
Preferably these sensor values would then control a second SCARA arm with a laser diode or plasma torch instead of the probe finger. Sort of like a remote copy machine.
A macro would have to be able to adjust the output, because the probe finger would be thicker than the actual laser/torch dot.
I wouldn't mind if the sensor data would be collected in a file before processing, to achieve constant motion speed.
The probe would have two push buttons: one to indicate external contour, one for internal. So the macro would know how to calculate the offset.

Has the probing part been done before with a Duet controller or should I use another controller ( like RPi pico)

@dwuk said in IDEX BOTH ON CORE XY:

It looks like the Voron Tap might be a possible solution - although it might not be accurate enough to take into account mesh adjustments if it just uses a servo.

Yes, a servo wouldn't be the best option for mesh levelling. But there is another problem: You'd have to calculate the z-adjustment of the "mini-z axis" based on the current XY position of the other tool (which uses the classic mesh leveling) or have a mini-z axis on every tool.
Unfortunately RRF allows only one z-plane and it doesn't provide "realtime" XY coordinates.
You could direct the real z-motion to the main steppers (during layer change, homing etc.) and redirect the z-adjustments to the mini-z axes.
Your post processor can easily detect, which is which:
If there's no E(xtrusion) value in the gcode line it's a real z-move
If you see a retraction/unretraction gcode with z-hop or a gcode line with extrusion, it's a mini-z thing.

@dwuk There are two different methods:
G32 = calibrating the bed tilt, by probing next to the leadscrews
G29 = using a probing grid or continuous probing to create a mesh

@dwuk Regarding Z-hop: I made a dovetail(ish) hotend mount for a different project and it was meant to adjust z-height for each toolhead individually. A motorized version with a small geared N20 motor was in the making, but the FW didn't have means to poll the heightmap for dual head printing (2021). Also driving dc motors with encoder was experimental, now it would be much easier with the step/dir interface of simpleFOC.

@dwuk said in IDEX BOTH ON CORE XY:

I usually only enable bed levelling very occasionally - and didn't for those test prints

The camera gave a different impression? I could clearly see the edge of the bed moving up/down. But maybe it's the cameramount moving....