I was skimming through Marlin PRs and found this pull request on implementing a differential extruder:

This reminds me of when I had a similar belt idea for a cleaning roller in the SecSavr Suspense (which is currently named #SlimeSaver [gd0105]).

I'm thinking that this could allow for direct-drive extrusion for 3+ input hotends without the drawbacks of other methods such as a semi-stiff stick or mounting many heavy motors on the end effector.

If I understand correctly, I think this would even be Core XZ compatible, allowing all steppers to be in the base of machine like the Ender-3 V3.

So after spending some days wondering what to print (and finding out Orca will throw out all my settings if I open a .3MF with some,) I decided that I was going to tune scarf seams and M592. 

Seams

I started off by learning the research posted in this guide on Printables and its comment section and applying it to a tesseract 3D model because "what point is a test print if you have confidence it'll print fine?".

I changed the z-seam location from random to aligned because some layers would try and start on an overhang.

I tested things like Inner/Outer vs Inner/Outer/Inner and, even with the latter looking questionable in the 90-degree overhang section (see below), I watched the print and came to the same conclusion that it's better.

I also set the bridge acceleration to 150mm/s2 which greatly improved the bridge actually anchoring to already-printed sections. I'll need to test more on a dedicated .STL in the future, but looking at the string left at the end of every print (as the hotend moves to the upper left corner over 20cm away), I think the strategy is low extrusion multiplier and low acceleration.

I tried a ripple cube STL I downloaded probably a dozen of years ago to see my current results on an easier print, and I had to turn off "Detect narrow internal solid infill" because it would try and bridge in midair:

I enabled Mesh Bed Levelling to help mitigate the first layer issues I had been having. I should've tried MBL out way earlier. A fade height of 3mm looked to be fine, considering my bed is only warped by 0.4mm.

I then moved onto this model to better see what the seams were doing:

I tested:

• Wipe retract percent of 100% and 0%
  • I was going to try 50%, but 0% was miles better than 100% that I didn't even bother. I believe it's because the printer has to momentarily pause to do the retraction, causing a secondary "seam" (shown in white in the image above)
• Scarf start height of 12.5%, 0% and 25%
  • I've got staggered seams enabled, and 25% looked the neatest.
• Seam gap 6%, 50%, 0%
  • 50% just spaced out the seams.
  • 0% was slightly more compact than 6%
• Wipe before external loop
  • I didn't have it enabled and the seam stuck out a lot less when it was.
• Wipe length 3, 6, 1.5mm
  • 6 slightly better than 3 which was notably better than 1.5.
  • I remained on 3mm.

M592

As I was printing, I noticed that my infill line wasn't starting all that well, and thought of an idea to test M592 Nonlinear Extrusion.

The yellow line is fullspeed, which should be 15mm3/s. This seemed to correspond to around 72mm/s, so I went up in units of 12mm/s for the other 5. For some reason, the slicer decided to print in the following order:

The fastest one was the only one that didn't quite start the extrusion right, but all of them had varying line widths from the start (blue dot) to the end of the line.

• 12mm/s would start at 1.2mm and end at around .9
• 60mm/s would start at 0.6mm and end at around .7

A bunch of trail and testing later and the results were inconclusive. I decided to rotate the pieces to give more time for the extrusion to equalise:

I just knew that I needed to do something about improving linear advance. One idea was a lower max e-speed in exchange for higher e-acceleration. When going into the tests, I had 120mm/s and 600mm/s2. I guesstimate to try 90mm/s, which was confirmed by using a calculator I found:

Dropping to 90mm/s, I used 0.9 k-factor to induce many E-movements and found that 3000mm/s2 worked but 3600mm/s2 had a slew of skipped steps. I then tried 0.45 and 0.6 and the latter was the best. This seems to agree with the setting found by an Ender 3 owner:

I was holding the filament during the print (to gather data on how the k-factor affected the movement) and the haptics of the 24mm/s line was quite nice. I hope to implement the feeling into #Tetrinsic [gd0041] in the future. I was also able to feel retractions, and I think 90/30 mm/s for 3mm retract/deretract respectively are good settings.

I've been tuning M592 and the amount of leaking is dramatically reduced. With more experience on how the leak propagates, I now feel that it's possible to minimise the shielding of the grub screw and make it look more streamlined. Fusion complained about my fillets so this simple change took multitudes longer than it should've.

The updated files are on PCBWay / Github.

It took much longer than expected, but the new clamp and coupler plates are installed.

Removing the old plates

I guess the reason why it took longer was because of all the oozed material, which was notably less in previous revisions. It meant that the filaments didn't pop out of the heatbreaks like I've been able to do in the past. Additionally, the threads were tight in so I had to dip in hot water and then use a large wrench to hold them. I used bolts to prop them up from the table so that I could get the smaller wrench on the heatbreaks:

This is also the first time I've had to install them without unblocking them all, since I wasn't able to get the filament out and the best way really was just clamping them back to the c8or heatblock. The job was made harder because I only have 1pcs needle nose pliers, but because of the gaps in the design, I was able to use it to hold the heatblock while I installed and tightened the heatbreaks in the new stainless steel plates while at 140C. 

I first tried 160C but that caused the material still inside the block to expand. Thus, I took the plate off and had to remove material from one channel that had stuck to the underside of the not-yet-tightened heatbreak.

Tightening the heatbrakes to these new stainless clamps feel much stiffer and confidence-inducing.

The coupler plates didn't work due to the FrontBack tabs

I spent about an hour trying various ways of installing the hotend into the holder before realising that the reason I couldn't was because of the top tabs that don't need to extend all the way. Thus I measured and tried to take about 1 - 2mm off one and then using it as a template for the other:

I then put the hotend together and it was much easier (except that I should've probably put the grub screws in before assembly). 

As you can see below, I've added offsets to the CAD as well as changed the grubs to M4 mainly so that I can use a larger hex tool:

Trivia

It takes ages (maybe 2 - 3x longer) for the Coaxial8or to cool down when the heatsinks aren't attached, suggesting that they are dissipating the bulk of the heat power and that a heatblock sock wouldn't help much.

I got 100% initial-filament-load-in success rate for the first time, meaning that the strategies I've been learning during this project are working to streamline the user experience. I think access to E6 is the only main pain point (other than the leaks).

I bought a £5 bar of 330x25x5mm SS304 and got it watercut along with the new hotend holder design:

The edges of the stainless parts have an almost perfectly matte satin finish and looks quite nice.

Tapping was tough, but that was mainly me learning the best ways to coat the tap in cutting grease, the importance to align the tap and strongly tighten the clamp and how to apply torque to the tap holder. 

It felt like:

• Starting the tapped hole was very easy.
• Ramp up of torque required until it reached "MaxT".
  • (coined from MaxQ I hear in SpaceX launches)
  • I just had to grow the confidence that the tap wasn't going to snap, especially when the material itself makes "something snapped"-sounding squeaks every so often.
• Lastly, the torque falls off, leaving me with a very smooth-feeling thread.

The offset in the CAD was -0.075mm and I've now doubled it to -0.15mm in an attempt to reduce the torque requirements.

Speaking of hole offsets, when I was tapping the hotend holder top plate, the M3 holes seemed kinda small. Turned out I accidentally applied threads to them in Fusion, but a technician just happened to have a 3.2mm drill bit and a drill press:

It may have taken 4 hours, but I've open-sourced the Coaxial8or r3.1 heatblock so that I could participate in PCBWay's 7th Design Contest. 

R3.1 is essentially R3 with all the post-print alterations, but since I haven't reprinted, it's not the 4th revision. 

To get things ready to go IPO, I just did a few small tweaks today, such as 

• finding a better texture
• filleting the grub shield walls
• changing the leak paths to 
  • decrease the chance of leaks near the heater cartridge
  • increase the chance that material can be pulled out of the channels when the hotend is heated to around 100C (for PETG)
  • increase the speed at which a leak could be detected

I also tried my hand at the "configuration" feature that Fusion has had for a few months now:

Some of the limitations I found was that you can't edit in place, nor do things like change checkboxes (Eg. "Keep Tools" in a combine feature). But now, I can quickly toggle visibility of certain components:

I've also exported the .step of the hotend holder, partially because the odds that I need to continue revising it are not insignificant. Additionally, it's tangled in the rest of the "Coaxial Hotend" file and trying to "Save a copy" gave me an exploded file:

I've also rendered the latest heatblock and holder:

I read the Open-Source Hardware FAQ and confirmed my choice to use the CERN hardware license. I'm not sure if it matters much compared to Creative Commons in the grand scheme of things.

I'm currently getting great results with the compressed HSVA colour system workflow using coolors.co:

The above is the Mint PETG I have, and my workflow is to:

• Use smartphone flash as a white light source to shine through the filament
  • My reference is:
    • 50% - Max transparency whilst still retaining 100% saturation
    • 100% - Effectively opaque for 1.75mm filament
• Get an offcut of filament (or 3d print)
• Place it next to a white reference
  • I'm using my white spacebar
• Max out saturation and brightness sliders
• Shine flash on filament sample
• Move hue to nearest 5 degrees
• Move brightness to nearest 10 percent
• Move saturation to nearest 10 percent
  • I find this to be the least confidence-imbuing slider since colours look more similar, particularly at medium-low brightness values

With this, I can get a confident compressed-HSVA mentioned in this log, but I still move the sliders around by 1 step to make sure I've got the right colour:

Confident YES:

Confident NO:

Confident NO:

There was no shine-through for the mint, thus the colour for this not-quite-cyan is 35.a9a.

Surprisingly, my pink is so much further away from the ideal magenta. The hue of the mint is only out by 5 degrees, yet the pink is out 25 degrees and admittedly desaturated:

It also has a bit of a glow when the filament is lit from behind, so its value could be 70.6a9.

One possibility for the hue is screen colour reproduction, and I know that pinks have always been questionable on various IPS panels. On my OLED phone, this same colours looks much more vibrant... oversaturated even. On my 9th gen iPad I happen to have, the hue is 315 and other values are unchanged. This is part of the reason for the compressed colour space; there are so many variables that the precise value isn't that meaningful. 

Considering a substantial amount of people have an unmodified iPad, touted with "TrueTone" technology, I will use it as the hue reference.

After looking at the colours I obtained trying to print the gift box, and remembering about the dithering log I wrote, I used this gradient generator to discover the issue:

Expectation:

Reality:

CMY and RYB

This highlights one of the reasons for the Coaxial8or project in the first place. It's one issue if you have to wait days or pay for an entire kilogram of material for a colour, and it's another issue if that colour isn't even commercially available.

Looking at the below, it sounds like one would still be able to get a decent gamut:

Another thought: maybe that's all that is needed? Maybe magenta, the innermost of the 3 hues, can stay opaque while cyan and yellow can tint it. Opacity wouldn't be very stable, however.

The alternative is dismissing transparency entirely and using 3-bit colour: White, Black, Red, Yellow, Green, Cyan, Blue, Magenta. For FFF 3d printers, transparent filaments are more like a visual effect, similar to matte, marble, silk, sparkle and glow. 

On the 25th of December 2016, I got into 3D printing for the first time with a CR-10.

I woke up on the 24th of December 2024 and I had an idea: Since the Coaxial8or kinda works and tomorrow marks 8 years since I first printed on "the CR-10 now known as the CR600S", I should try and print a two tone gift box.

Designing the box was simple

Obviously, to celebrate years worth of calibration cubes, I modelled a ribbon-wrapped 20mm cube with an 8-sided flower-bow on top. I also added a little pillar so that I could mark orientation (because this is still a calibration cube at the end of the day). I joined the pillar with a very narrow (0.001mm) extrusion so that it and the ribbon counts as a single body:

It should also be of no surprise that the ribbon has filleted chamfers.

Setting up in PrusaSlicer

So I was doing things like setting up a decent purge volume and looking at the (failing) prints to see that I really needed to work on retraction settings. What I found that it seems best to

• retract ASAP - prevents a blob forming at the end of the track
• deretract slowly - allows a small blob to anchor at the new location before the toolhead zooms off

At this moment, my purge volume was 300mm3 and it seemed like it needed to be more. For context, 100mm of filament = 240mm3, so it's somewhat expected. I designed the Coaxial8or more for having a digital library of filaments than a multicolour modification (e.g. like the diamond nozzle).

Setting up OrcaSlicer

In search for "coasting" for PrusaSlicer, I found out that OrcaSlicer has a "wipe distance" option, which doesn't exist in PrusaSlicer.

Earlier in the year, I didn't use this slicer because it only supported single-extruder-multimaterial options. I can now report that it now supports multiple extruders! The only caveat is that, to duplicate settings across all extruders, I have to temporarily set Extruders = 1 and then back to = 16. This also resets the filaments loaded to whatever was in the first extruder.

The main, exciting thing I was able to (convolutedly) set up was a "master" material, which actually updates other materials inherited by it. This makes things SOOO much more manageable.

I also think it's easier to see what is loaded in OrcaSlicer:

It's possible to do by creating a new material by clicking "Add/remove filament" and then "Add new":

It insists that some "@MyMarlin" thing is added to the end. I went to the presets path, removed "@MyMarlin 0.4 nozzle" from the filenames and then search and replaced (with nothing) the string in other files:

As you can see, I decided to name the block colours with a 4-bit number. So instead of hex of RGBA being FFFF for opaque white, it's 1111, since the block colours are either entirely on or off anyway.

It was a bit tough (because I kept opening the same .3mf instead of importing it into a new project, causing settings to linger around) but I was able to do the same thing with the printer preset! All I needed to do is put my master in a "base" folder and set 

"inherits" : ""

Then I could make another profile and tell it to inherit the master. 

Finally, I can have an easily editable master profile! I've been wanting this feature ever since I got into 3D printing. What makes it special is that, if I changed a value in the child preset and I want it to follow the master again, I just need to change the value to whatever it was in master. It's not like Cura where I'd have to open the config file in VSCode and delete the entry.

Redefining colour

Do you see much of a difference in these colours? I don't, but the blue value is quite a bit different. I then remembered that all these virtual materials are going to be sorted in alphabetical order. If I continued to use RGBA, it'll be all over the place!

There are other ways of defining colour, such as HSB/HSV and HSL (seen above), and they have alpha-channel variants too:

Still though, I want a nice, easy, good enough scale that doesn't take up to much space. There's no way I'll be able to tell if something is 99% or 98% of something. FDM isn't really going to be doing "truecolour" gradients unless I want to purge a spool every layer. It seemed that I could "round to the nearest 10" for everything, so I asked Gemini what that would look like and it, to my surprise, Gemini actually coded up a "Hue Color Ramp":

I then used Coolors to mess around with both HSB and HSL, of which their differences are shown in this article.

I played a guessing game of "the eyedropper of my eye", looking at different colours in the room and trying to get its value with the sliders. It was soon apparent that HSB was much more fluid to find the colour and be confident it's good enough. First I max out SB, move H to where I can see the brightness of the colour I need, and then finally see across the saturation slider for the closest colour:

After a few tries, I realised that the hue needed to be more granular, rounding to the nearest 5 degrees instead of 10:

As of writing, below is the format I've decided on which encodes the above "spanish orange" as 05.a9a. There doesn't seem to be a HSBA colour system, only HSVA. Allegedly, HSB and HSV are equivalent:

So it's "Base10.Base11" in a way, but makes it easy to convert between the standard and compressed notation without taking up extra character space. Even still, this compressed colour system encodes over 5,000 opaque colours. Below are some virtual filaments I've already taken out of the oven earlier:

Some images of attempts

Conclusions

The good news is that the Coaxial8or R3 managed to last an entire calibration cube print. The drawback is that "fade height" for the yellow to completely flush out is maybe 8mm or so. It's quite a lot better than R0, but still mostly in the use-case-camp of "I don't need to spend £15 and order an entire spool online and wait 1-3 days just because I want to print this one object in a specific colour I don't have already".

I've added a leak shielding to the thermistor grub screw. I've also removed some leak channels and made the remaining ones deeper in depth so that leaks:

• can be detected faster
• have less "crosstalk", potentially making it harder to determine leak origin if 2 filaments are of similar colour
• don't pose a threat to the thermistor
• can more easily flow out the sides instead of squeezing through the small gap between the coaxial8or and clamp plates