Hi guys,
I'm playing with my new extruder and would like to know how much it extrudes in a real print.
Is it possible to display extrusion volume in DWC? Printspeed, layerheight and layerwidth? should be available for calculations.
I extruded in free air to get ballpark numbers, but real life is different.

@gtaman
It's actually the same:

• create a global variable blockDaemon
• set global.blockDaemon = true at the start of the M300 file
• set global.blockDaemon = false at the end

Then anyone using Daemon.g for real can add these lines

while global.blockDaemon = true
          G4 S1000

Had my first simpleFOC project running today. It was an old brushless gimbal controller without encoders and with 8bit mcu.
I was able to control two motors independently and relatively smooth (USB power only)
The atmega328 was also at it's limit, but I'm now confident it will work well with the right mcu.

@m0ck1nj
Check the TB6600 datasheet. If it is OK with 3.3V signals on step, dir, enable you can wire it directly.
If it needs differential signals or 5V you can use the much cheaper expansion breakout board

First print today

Instead of a benchy, I tried the extruder-woodgrain test. Yes there is some, but hardly visible. The corners were sharp and even, that was a relieve. The close loop PID setting are quite soft, so I expected worse...

At the top third, the printspeed got so low, that the filament overheated. 10°C less temp and it was nice and shiny again.

@jbergene

According to this picture

• positive X goes to the right
• positive Y goes to the back
• positive Z goes up

@dc42 said in Smart Effector including toolboard-capabilities?:

It's clear to me that the Orbiter could not be used with a Smart Effector made to the current dimensions. We would need to increase the rod spacing to at least 80mm in order to accommodate the various parts of the extruder. We are looking into this, however it would make it unsuitable for the smaller delta printers.

Hi dc42,
I just stumbled across this thread and wanted to guide you back to 2016 , when we discussed the cycloidal direct drive. (I still have it laying around)
I've made an 45 degree adapter for it, that suited the smart effector pretty well.

Another way to mount it, was the split motor/gearbox idea.

I could try to reuse my motor and design a BMG-drive for the Smart effector?

Hi devs,
based on the "extrusion volume" thread, I also think a back EMF calculator as DWC plugin would be helpful for tuning.
The required parameters are almost completely known for the calculation. It only misses coil resistance and inductivity (AFAIK)

Since my Duet boards run on their own network, I don't have access to the EMF calculator at reprapfirmware.org

If we could integrate it as plugin and use 'live' values from the current object model/gcode file, we'd have a nice tuning tool

@nikscha I like the idea. It's like the tool-change macros.
But there is also a problem when you retract / unretract within a toolchange.
Maybe you can solve your problem by renaming G10/G11 to G10.1 and G11.1 via postprocessing. Then you need only one macro for retraction (which also contains the real G10 move)

One thing not mentioned by anyone is the G31 probe offset. Are you sure it's OK?

@dwuk Seems to work already!
But around 32:00 I saw a potential improvement. Your post processor seems to print some tracks "from the far end" which adds unnessesary travel moves. A small routine that checks for shortest travel move would help here.
Other than that, I think the result will look even better with two tools. It would avoid oozing during travel moves.
Maybe add the option to do the top infill layer in one go?

A bit of concern is the mesh-bed compensation: That printer seems to be aligned badly. Just for fun you could try to print without mesh leveling. It'll give you a good taste of things to come with 2+2 tools. (not being able to use mesh levelling was the major reason I disassembled my hashPrinter)

@moocowsia said in Tevo Little Monster - 80 mm + Direct Drive and Remote Fans:

I couldn't figure out how to assemble it.

You could print an adapter plate that holds the heatsink-nut and fits under the LGX.
Then screw the heatsink in before you mount the hotend/heatbrake.
You might have to rotate the nut in the adapter a few times, before everything is tight and aligned nicely.

@dwuk With a toolchanger the frame is pretty cramped. Imagine you want to replace the left green tool with the right-most parked tool or the other way round....

@moocowsia I guess you had to raise the LGX so much, because of the extruder motor sticking out?
I know these Orbiter and LGX extruders are en vogue but I still prefer my "tall and slim" sherpa mini

@dwuk I'm concerned about the moving mass of the flying gantry. If I'd build such a printer from scratch, I'd choose a moving bed.

And I'd flip the front cross bar, so the green nozzles face the others

@magnets99 The gantry is pretty interesting: They use the smooth rods for linear motion and as rotating shaft.
I wonder how well that works with these linear ball bearings? Especially on pure X or Y moves (i.e. homing) they will suffer.
I'd replace them with IGUS bearings if they seem to be worn out.

@dwuk I'm impressed, you came quite far with simulating all the different splitting algorythms.
But isn't it time to make split versions for one tool head? Just to see the real world output of your mods with inner layers overlapping and tons of retracts...

I can think of several things that can go wrong trying to print the first layer. It's already nerve-wracking with a single object, although print surface and bed-adhesion has improved a lot.
We know from former dual tool printers, how hard it is to find the sweet spot regarding z-height (and without mesh levelling)
Somehow the second tool always scratched off the freshly laid tracks of tool one...

@titusou said in EasyIDEX:

Not exactly "compact" but that's the cost of IDEX.

That was also my first impression, but it's build for better maintenance...
Maybe put the linear rail of the x-axis on top of the extrusion: That way you'd have easy access to the screws that hold the toolheads.

@dwuk It seems the post processor is pretty busy. Munching through GBs of gcode is much harder than splitting an .stl file of several MB.
Do you use an SBC or external CPU? It would be cool, if you could process layer by layer, while already printing.
You don't want the whole processing take longer than reducing printing time ...

PS: Maybe you'll find a ready to use "center of gravity" calculation code? To me this is a close enough approximation for the best coordinate, where to put the cut. Would only work when cutting the .stl file I guess.... But maybe that's the right way of processing:

• decide where to place and cut the object , based on the stl file
• then do the cut in the gcode file

@dwuk said in IDEX BOTH ON CORE XY:

but should be fairly easy to add.

In the meantime, for simulation you can reduce infill to 25% of the actual value when you plan to use double layer thickness and twice the nozzle diameter.