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:

• V-Tools are not preserved / saved in EEPROM and are reset on boot
• Marlin makes use of a copious amount of macros, making the code more readable.

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 found out rather quick that there's currently no way for the TFT to even get the information it needs because nothing in marlin reports the v-tool mixes.
• Then i was thinking things like:
  • Should it be its own GCODE command or a report of something else?
  • What GCODE command do I pick? M162? M167?
    • Chose M167
  • Do I add a '#define' so that reporting can be turned on of off?
  • Do I make a new file called M167.cpp or append it to a pre-existing one to make M163-M165_M167.cpp?
    • Decided that github would see the latter as an entirely new file, which could make the PR harder.
  • How verbose should the output be? 'M165 A.. B.. C..'  or perhaps 'V-tool 0 [ 1.0, 0.0, 0.0... ]"
• In all that, I found out that my 8-extruder code might fail if GRADIENT_MIX is enabled, so I went back to push a fix.
• Back to the thought dilema after I slept and woke up:

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

Output

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:

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.

• Seconds 01 - 59 in lime green (to alert that it's almost done)
• Minutes 01 - 59 - white
• Hours 01 - 71 - bottle green (same as CR600S and most likely to be)
• Days 03 - 99 - Probably blue? It needs to be a colour that is visible but unobtrusive as it'll be visible for a while.
  • Surely there's not a single print that takes over 99 days.