[C] Marlin M165 improvements

A project log for Coaxial8or [gd0144]

Full-colour FFF? Multi-materials with unparalleled interlayer bond strength? Abrasives without abrasion?

kelvinakelvinA 02/25/2024 at 15:110 Comments

I have just finished creating a PR for MarlinFirmware for improvements that I needed so that I could realistically test this project whilst not having "Marlin Mode" on the TFT. This PR is my second one ever. I tried to avoid it, but I needed to merge the first PR into the second so that all 8 extruders were supported. 

Disconnected fork

The first thing I did was the fix to allow 8 mixing extruders. That was simple and straightforward because I had already done it and just made a new branch in Github and manually copy-pasted the change. Then I went to try and submit the PR:

It turns out that my Marlin fork didn't actually show up as a fork of the main repo, and research suggested that there was no feature to "retroactively fork". I had to make a new fork and then do things like

git remote add lc-old [url]     -- Backup repo
git rebase common
git push lc [branches I wanted]

 and a few other things 

Multiple potential solutions

Here's a list of the inital things I could learn from reading the codebase:

In my university studies, I've always kind of wondered why having more than 1 solution is a problem. Well I found out first hand when I was coming up with a solution to how to go about getting mixing extruder support on the touchscreen.

I had found out that there are many Mxxx_report() commands and so started looking into trying to emulate those.


I finally had something that should output the values. I just needed the values themselves. My first idea for getting them wasn't going to work:

I saw that "collector" was accessible so I was about to make an entire vtool [ i ][ j ] array and function, but I remembered what the Marlin Coding Standards mentioned about trying to cut down on duplication. That's when I had the simple idea:

Soon after this snip, I decided that it would be faster to see and type in percentages than normalized values, thus I normalised the collector to show 100.0 instead of 1.000.

I made a new branch before I did all the 8-extruder stuff in cr600s and compiled the code and this is what I got:

There were only 2 issues. T0 and T15 was missing. T15 was an easy fix.

T0? Well I was trying a few different things and looking in the code to make sure I'm doing the same serial commands as the other _report() functions. When starting one of the flashes, the OctPro almost immediately sounded its siren to signify that the 5V regulator couldn't sustain 5V before the system turned off as soon as it turned on.

Me: Hm? That's odd. *Turns off mains power*. *Looks around for anything that shouldn't be somewhere* *Turns on mains power*.

And then my PSU popped!

So after screaming "WOAUGH!!", smelling the classic pop smell in the air and checking to see if my SD card still read (as if it didn't would suggest that my electronics got fried along with the PSU), I couldn't see anything from the exposed-electronics side that could've done anything (the PSU side is enclosed). 

Considering that I was actually expecting that pre-2019, old-school PSU (not the modern, thin and fanless kind, but the PSUs that had built-in fans and a 110-220V switch) to fry my circuitry the very first time I powered it on, I had hope that it was an isolated event (and not that something metallic found its way someplace detrimental).

I unplugged everything except the TFT24, which seemed to power on fine. I wasn't getting a connection with the OctPro, but that was fixed by flashing the firmware I was trying to flash in the first place.

So now I need to buy a new PSU, which will also change how the electronics box is modelled and how the OctPro is mounted. I think it's going to be very close with 1 metre extruder cables.

Fixing the missing T0

As it turns out, this was never missing:

As you can see, however, there's a lot of "T:" stuff that usually goes through the serial window, so I hypothesised that the touchscreen firmware was just ignoring the first line because it was "T0:". After some testing, it was actually the substring that was the issue, thus "VT0:" wouldn't work but "V0:" would:

Future work

So to get here took 12 hours total. I can see why Me In The Past has left "repair CR600S" on the todo-list for years.

The next part of this saga is now going to have to be getting the TFT24 to use this in a useful way. My main strat is to get some kind of new printing menu that shows the mix of the currently selected v-tool. While I'm at it, I'd like to implement the large 2-digit, estimated time remaining display idea I have. Like I've already mentioned in #SecSavr Soapavr [gd0146], if everything is working reliably, all I care about is the time until the print is done (or the time until a user action is required) and if there's an error.