The Robin series from MKS features the STM32f103vet6 microprocessor, including a FSMC interface. This way the display can directly be driven from the same microprocessor and memory. The typical other TFT screens usually run on their own and are just interfaced via G-Code.
I can just guess the advantages and disadvantages until now, but I always disliked the idea of the standalone displays and also sticked to a classic 128x64 LCD on my other 32bit machine.
My Sapphire Pro already came with an updated firmware version (v1.0.3) and had a basic UI with the most common controls. I won’t be too harsh with this type of printer control, because I think this the right direction, but we are still not where we need to be. Using this UI feels like the first touch screen phones from the early 2000s, than a current development.
Looking a little bit deeper I found the config file, that allows a decent amount of tweaking. If you’re familiar with some printer firmware configuration files, you may recognize something like this here:
(..)
#=============================== Bed Leveling ==============================
>BED_LEVELING_METHOD 0 # 0:NULL_BED_LEVELING; 3:AUTO_BED_LEVELING_BILINEAR; 5:MESH_BED_LEVELING
>GRID_MAX_POINTS_X 3 # the number of grid points per dimension. <= 15
>GRID_MAX_POINTS_Y 3 # the number of grid points per dimension. <= 15
(..)
Robin_nano.cfg
Does this look familiar?
(..)
//#define AUTO_BED_LEVELING_BILINEAR
//#define AUTO_BED_LEVELING_UBL
#define MESH_BED_LEVELING
(..)
#define GRID_MAX_POINTS_X 3
#define GRID_MAX_POINTS_Y GRID_MAX_POINTS_X
vanilla Marlin Configuration.h
Don’t get me wrong, I don’t want to diminish the work some programmer put into this, but IF YOU STEAL FROM THE GPL COMMUNITY AT LEAST HIDE IT PROPERLY or just release the sources.
I recently read a little twitter story from Naomi Wu about this. While in the western (printer) world, we’re making our products outstanding and special by creating and controlling our sources for parts and their quality, because it’s hard and time consuming here, the chinese can source the parts in the quality they need much faster and easier. To keep them ahead in business they try not to disclose their part-sources, but the software.
China OSH Primer:
— Naomi Wu 机械妖姬 (@RealSexyCyborg) September 17, 2019
Western OSH licenses reflect Western business realities and competitive concerns. Ideals and marketing nonsense aside, if the OSH product is being sold, something is almost always retained as "secret sauce" to ensure at least a modest competitive advantage.
read the whole thread on twitter
I can understand this problem and behavior on one hand, but on the other hand let’s be real: most of the chinese printer firmware and software we get currently is default garbage and often outdated. (look at all the old 15.x Cura stuff that’s often included). But two of the leading western printer builders, Prusa and Ultimaker make money, because their firmware, software, support and user experience are gold, not their parts.
Has any other printer on the market, that is not a 1:1 Prusa clone “borrowed” and customized Prusas’ software for their printers? Not that I’m aware of. It’s the opposite, Prusa and other heavy Marlin modders are actually contributing their features back to the main branch to enhance the firmware for everyone, also for the chinese printers.
I don’t know what has to happen in the chinese printer market to realize, what open-source not literally, but actually means and how to embrace it, rather than ignore.
I have the feeling, looking at the MKS github repository they are clueless. If we want to make this whole world a better place, we need more personalities directly in china baptising the idea and workflow of open-source, like Naomi does.
Naomi Wu speaking at COSCon’18
This out of the way, we can all agree, that having the latest Marlin build on your printer, together with reasonable controls, would be great YES and that the current MKS firmware limits this printer to just the printer it came for under 300 Euros, not a base for more experiments. BOO
Like a lot of the 32 bit boards, this one also has a bootloader, that sucks files from the SD card and updates on start-up, no complicated serial STM-Link clamps. With the current MKS firmware you can also throw config files and encoded pictures at it to update the appearance and change the settings with just one reboot.
Since there was no real instruction manual for doing this and the files from the main branch of marlin wouldn’t load I had to research a bit and found the clue: the bootloader looks for Robin_nano35.bin and not Robin_nano.bin like the compiler spits out. So has been customized by MKS/TwoTrees. (with v1.0.3 - Edit: apparently there are different versions out there, some with different bootloaders)
After an evening of digging through github, forums, datasheets, correcting compiler fails and dozens of SD card in-and-outs, I had 2 versions of marlin running on my printer with a decent configuration, that would actually print on the Sapphire Pro:
the pretty old, customized version directly from the MKS repository:
a current marlin built
There once was a time in my life far far away, when I was programming for CNC microscopes and did a lot of machine vision stuff. This knowledge clearly helped to realize, what the problem was and that the solution was just a little hack away.
The u8gdevtft320x240upscalefrom128x64 class, that feeds the display, just did what it’s called: Upscale the ancient 128x64 pixel UI by 2 and shove it in a framebuffer, that’s connected via the FSMC to the TFT. Wow, that’s not only elegant, but also really easy to adjust.
I just have to hope, that the whole framebuffer-FSMC-TFT construct would allow higher resolutions, than the hardcoded 320x240, as the 3.5” TFT actually has 480x320 pixels. (I guess this was coded for a smaller 2.8” TFT, that is also distributed by MKS)
With a little pixel math, a design for the bigger resolution was created
<-- 480 px -->
__________________________
|_| top offset: 32 px |_|
|_|______________________|_| /\
| | Marlin display |_| |
| | 384*192 px |_| |
|_|______________________|_| 320 px
|_| middle spacing 16 px |_| |
|_|______________________|_| |
| | touch UI: 384*64 px |_| \/
| | element Y: 2+60+2 px |_|
|_|______________________|_|
|_| bottom offset: 16 px |_|
|_|______________________|_|
^- left offset: ^- right offset:
48 px 48 px
All we need to do now is to upscale by 3 instead of 2 and hope for the best.
Operation successful, now the touch buttons also needed some treatment and voilà!
To get the old vibes going, we can also let it look like an actual RepRap Full Graphic Smart Controller.
What now had to follow is the typical boring job of adjusting and fine tuning features, values and limits, until it suits the printer.
This will be covered more in detail in a separate post, but here are all the resources you need.
You’ll need platformIO to compile everything. Rename your Robin_nano.bin to Robin_nano35.bin, put it on your microSD and start the printer with it and it should update.
This does not apply to every revision of the Sapphire Pro - some have standard bootloaders, where Robin_nano.bin is right.
please check the commits and if the config suits your printer configuration (eg. if your bowden tube is shorter than mine, the filament change feature may damage your hotend or extruder!) there is no reason to laugh here
And that’s, where the Sapphire Pro is now. With a few evenings of tinkering we have released this printer kit from its MKS chains, just waiting now for all our upgrades and fancy features. Why it had to be delivered with this firmware-chimera abomination, I have no clue.
If someone from any chinese printer manufacturer actually reads this: ask us, ask the community, ask me, if we can help, beta test your stuff, improve and maintain firmware or just give you an idea what features we would like to see - we are willing to help - as long as you are complying to the rules, that come bundled with these pieces of software.
happy printing,
alpine