Monoprice Mini Marlin 2.0 Support

Thanks to a discussion on Facebook, I've solidified the V3 pinouts. For those of you keeping score at home, the probe is the old Z-Min pin (PB5) and the Z-min moves to PA2 on the Serial2 header. I'll have a code change for this/PR for Marlin soonish. I don't recommend using this on the Pro or V3 yet because the menu for adjusting the Z offset doesn't work - there's a whole new set of commands I need to implement (P:I, S:S, M:[0-998, 999], where S:S is save settings, M:0-998 sets a Z offset, and P:I initiates leveling).  Also, this will require the failsafe EXTUI support, which has to come first.

So, octoprint users were consistently hitting an issue where the printer would switch to relative mode and die from over extrusion protection. Or turn off the heaters. You know, the fun sort of stuff that makes a 3d printer a little more useful than a boat anchor. Solution? A bluepill. I keep a handful around at any time, and they have a couple of great properties:

1. They run on 3.3v logic, meaning I don't need to spend time shifting levels.

2. Two free hardware UARTS. What's not to like about that?

3. USB! A nice, pretty USB Mini connector, which means that all I really need to diagnose protocol issues is a set of jumpers. Wire one Serial to the Mini's mainboard, one to the display, serial + GND and just a scratch of Arduino code, and we have a cheap protocol sniffer. 

As I noted, nothing seemed to repro on my hardware, except for the delta.

And if I had just paid a little more attention to waht my eyes were telling me, I wouldn't have needed to do any protocol sniffing.  See, if you simply watch a late run V2 or delta's screen while issuing a temperature wait command. Go ahead, I'll wait.

Back already?

Yes, it switches to a screen I call the build screen, because the command that takes the mini to it is "{SYS:BUILD}"

This screen does NOT result in a timeout. Without a file call, it won't show you the file being printed, but that doesn't matter - what matters is that it doesn't time out. 

Fixing this required extending the malyan_lcd code to support status prints. We can't possibly display them but we can check to see if they match the heating messages (using their string constant names) and issue the SYS:BUILD command there.

I've pushed a set of changes for this, but there's a few caveats:

It's essential that at least one temperature wait comand be used. M140, M109, whatever wait method you want in your slicer. Don't do that? Prepare for timeouts. Also, thanks to a project contributer, speed adjustment should work better. Note that if you are using an early V1, this may break speed adjustment, as I'm near certain there's a bug in V1 LCDs where it sends the wrong command while adjusting feedrate. If so, this fix breaks that, but I don't have my early V1 LCD anymore. I'll watch reports and see if it crops up. If so, I can make adjustments.

Happy printing...

So...I've been printing on my mini for nearly a couple years using different flavors of Arduino, different branches of Marlin, etc, and had support for the LCD ever since my great ice-meets-two-wheeled-vehicle accident. Most of my prints are from octoprint, but I often use the LCD to tune the temperature and so on. 

All of that meant I thought I had a fairly decent idea of how everything worked. But in the comments of this project, I found not one, but two different people who reported seeing injected (LCD) commands which switched steppers to relative or disabled them, set temperatures to zero, and so on.

Being as this is my code, a bug is more probable than possible, so I went hunting.

And I found nothing.

My wife and I have been binge-watching House, and while the motto there is "Everyone Lies," generally speaking, people only lie when there's something in it for them. There's nothing in it for someone to report a weird bug that affects steppers/hotends, which means these people were telling the truth.

We began to theorize it was a timeout in which the UI was intentionally injecting "shut down commands as some sort of failsafe.

MRozay was kind enough to confirm for me that he'd hit the same thing in his M4MPD project (which uses a variant of my LCD code). To get around it, he switched to the BUILD screen during homing and heating. The build screen doesn't have such a failsafe.

Ok, great. 

I sat down and fired up my UI tracer sketch, which I modified to report the heaters were active and then started \my M200 printers - an original run V2 (STM32F103) and a second run V1 (STM32F103). Both were hooked to their respective LCDs, both set to trace any input from the LCD so I could figure out exactly what the firmware does.

Twenty four hours later, they were holding steady with zero input.

Then I started looking at reports and thinking. The LCD code in the Minis is something I tinkered with but realized was out of my depth, but I did learn there's several major revisions, and each has quirks. On a hunch I pulled the LCD from my Mini delta, and thirty minutes later, it killed the temps (but didn't trace my output, because I don't have a delta version yet).

So, there IS a timeout.

I can print from Octoprint to the Delta just fine, meaning the stock firmware must do something different I don't know about. This weekend, I'll set up a pass through bluepill to trace communications and run some test prints on the delta. Also, it can't hurt to actually mail Malyan and ask how they avoid it. Worst case is they refuse to explain.

Fingers crossed.

So many people have had difficulty compiling due to the fluid nature of the ST Arduino core, difficulty installing supported boards, etc, that I took some time out to look into how to make it easier. Arduino supports a concept called "Portable" wherein an install, all of its packages, sketches, temp data, etc, live in a folder, appropriately named "Portable" under the Arduino folder.

One look at this and I knew we had the key to allowing others to compile.

The cost? Some time, some download effort, and being locked onto a single version of ST's arduino core. Obviously the portable install will need to be updated when HardwareTimer libraries are added, etc, but a click-to-compile solution seemed possible.

To do this, I set up a new, clean laptop. My dev machines have git enlistments, half a dozen (really) copies of Marlin in different states, are symlinked together so I can use a git repo as my Arduino Core without copying things over--all the usual stuff.

To simulate someone else building, it had to start from scratch. I had a few problems and wound up downloading an hourly build of Arduino (in a step I no longer think was necessary), but finally got to the point where i could set the options correctly, click, and compile.

It's unlikely Hackaday wants to host a half-gig file for me, so I shared it on OneDrive.

Arduino Portable for Windows: https://1drv.ms/u/s!AjuNQlXUvQuaq-45AF_Nwk7l9XIhag

To use this, download the portable install and unzip it.

Make sure you configure your settings correctly - there's no way I know of to set the IDE options in a project or I would already have done it.

Obviously if you're compiling for a V2, you'd choose V2. Be careful! Some black (early run) V2s use an STM32F103. If your V2 is horrendously loud, uses the 46.5 steps per mm, and has a 103 chip under the hood, choose "V1" in spite of it.

One thing I'm still playing with - on my machine I have an upload option called "copy to file" which copies to a drive, which is what the Mini requires. I may add this in to the portable, with the understanding that since the Arduino IDE doesn't have a good way to enumerate drives as ports, the script expects the drive to be called "PRINTER" under OSX and probably "M:" for windows.

Flashing - First make sure you can easily move between official versions of the firmware. If you can't do it with Malyan's firmware, don't expect Marlin to work. The Malyan Bootloader is picky about SD cards in a way that defies understanding. Smaller is better, the one that came with the printer is best. For V1s, it's called "update.bin," for V2, "firmware.bin." 

Good luck, people. Happy printing.

This began as an answer to the question "Is there any other way to hook up Octoprint that doesn't involve USB?" 

Why? Because the person in question had discovered that if one steps on the usb connector, it will transmit the force upward, outward, and other-wards. In the words of my 2 year old daughter, it "badded" the connector.  

Now, those with nimble fingers and usb-electron-robo-soldering irons will easily repair the port, sometimes even soldering on a different size/type. Not me. Soldering to the debug pads on a V2 is a complex operation for someone as shaky as I am. But there are other options. While I acknowledge that the Raspberry Pi Zero W isn't recommended for octoprint, that's primarily because of slowdowns when streaming video.  On this particular board, I had no LCD, so why not take the opportunity to make an all-in-one?

To do this, you'll need a Raspberry Pi Zero W (if you're going to attempt this with a B, A, or anything else, go ahead and wire up a power supply.

Some form of cable to connect it. - If your LCD works or you ever intend to replace it, a JST kit  in like SPH-001T in either P0.5L or P0.6L depending on whether or not you have a V1 or V2 (V2 uses the narrower pin connection).  See https://mpselectmini.com/parts/wire_connectors for a good breakdown of connectors and sizing. If your LCD is dead and you're never, ever going back, you could cut the display cable (shudder!) and use it.

To plot out our wiring, refer to https://pinout.xyz/pinout/pin1_3v3_power

It turns out, we can power the PI directly, feeding it 3.3v. The PI will report it's underpowered, since the 5v side isn't being supplied, BUT, it behaves fine in my testing, and since the 5v exists to feed the 3.3v regulator, we're probably fine. 

Probably. Proceed at your own risk.

Now, we need four things to power the PI and communicate: 3.3v power, which the display header gives us, Ground, which the display header gives us, TX, and RX, which...the display header gives us.

To begin with, setup OctoPi on your raspberry PI and ssh to it.

We need to enable the mini UART for serial in order to gain access to /dev/ttyS0 (the mini UART). Follow the instructions here:

https://www.raspberrypi.org/documentation/configuration/uart.md

Specifically, you want to run:

sudo raspi-config

Select option 5, Interfacing options, then option P6, Serial, and select No. 

You want login not running on Serial, and Serial enabled.

Exit raspi-config, saving changes, and reboot the pi.

Next, in the octoprint UI, choose the wrench, setting, and add the ttyS0 as an option:

If you are not running Marlin, you can try adding 500000 as a baud rate. There's a decent chance Octo will connect to the /dev/ttyS0 device at 500000, but I am running my own sotware, so I didn't need to do this.

Now, wiring:

If the display connector is closest to you, with the bed/hotend connectors away, power is on the left of the connector, ground on the right, and TX/RX are in between. A picture is worth more though, so see how this is run:

Wtih that done, a quick "connect" and I had Octoprint working straight through the display. And yes, it works perfectly well if I swap it out to the Serial2 connector above the MCU, allowing you to use both the LCD and Octoprint directly. Wifi printing does NOT work in this configuration. Marlin supports two Serial instances, and Wifi printing consumes one with its pass-through serial.

Now with 100% less cat. Not that there's anything wrong with cats, but there are no known great cat film directors for a reason. This is Mesh Bed Leveling running on a Monoprice Mini V2/Malyan M200 V2. This one is using the endstop as a sensor just to test the code. If I had an actual sensor wired to this printer, it would absolutely work.

One of the big features the V3/MP MIni Pro brings to the table is automatic bed leveling, but I've always been of the opinion there's no reason to restrict bed leveling to a new product. Marlin supports it, so why not the mini?  To do this required a couple of changes underlying everything else:

First, eeprom emulation wasn't working. The 103 in the V1 doesn't support SRAM and there's no I2C eeprom (and precious few pins available to wire one up). So EEPROM emulation it is. Here, I was led astray by some of the pre-existing code. the STM32F4 and F7 HAL support EEPROM emulation, and I first attempted to port it, but flash programming is very different between 103, F4 and F7. 

So, instead, I deleted all the existing code and wired together a simple one using the platform's EEPROM library. There's some overhead to this that's not good, but for now it works and lets us save settings using M500...a prereq for bed leveling.

After enabling bed leveling in a fake mode (linear, using z min pin, aka "pretend to level using the z endstop"), I recompiled and immediately failed, overflowing the ROM region by 2k bytes.

But it's actually much worse than that. 

The linker script doesn't (and shouldn't) take into account EEPROM emulation, which takes a full page. THis means that of the 128K available, 8k goes to the bootloader, 4k to the emulation, so we were overflowing by over 6k, and 6k is a LOT in the ARM world.

arm-none-eabi-nm -t d -S --size-sort

gave us the output for where the sizes were going.

Our biggest culprits? We expect dtoa and strtod (a couple of large functions we need and you don't expect to vary much - the whole subject of decimal conversion and representation is intricate and fasinating, and a lot of the value in these two is that they do things the same way everywhere, all the time).

34263024 00000940 T _ZN14MarlinSettings4saveEv
134309128 00000984 T HAL_RCC_OscConfig
134336292 00001104 T __gethex
134277628 00001128 T _Z8probe_ptRKfS0_12ProbePtRaisehb
134307920 00001156 T HAL_PCD_IRQHandler
134326604 00001182 W _printf_float
134252048 00001204 T _ZN10GcodeSuite22process_parsed_commandEv
134234936 00001296 T __aeabi_dmul
536873824 00001344 B _ZN7Planner12block_bufferE
134285852 00001368 T _ZN11Temperature12PID_autotuneERKfaab
134232892 00001516 T __aeabi_ddiv
134246040 00001524 T _ZN10GcodeSuite3G29Ev
134280316 00001552 T _ZN7Stepper23stepper_block_phase_isrEv
134264188 00001596 T _ZN14MarlinSettings6reportEb
134231120 00001772 T __aeabi_dadd
134236232 00001840 T __aeabi_dsub
536877664 00002048 b eeprom_buffer
134274192 00002312 T _ZN7Planner15_populate_blockEP7block_tbRA4_KlfhRKf
134265784 00002724 T _ZN14MarlinSettings5_loadEv
134333160 00002984 T _dtoa_r
134328968 00003132 T _strtod_l

The problem with this output is pretty much everything here, we need (there may be some optimizations available by removing PID autotune, but that's re-arranging deck chairs on the Titanic to slow the sinking. We need big savings, and the first thing we have to do is find out if it's using function sections.

Unfortunately, that flag is already on. 

However...a quick check shows that Link Time Optimization is NOT on. A quick change, and we get:

Sketch uses 100392 bytes (81%) of program storage space. Maximum is 122880 bytes.
Global variables use 9724 bytes (47%) of dynamic memory, leaving 10756 bytes for local variables. Maximum is 20480 bytes.

That is totally acceptable. A quick check, and G29 works flawlessly.

Next up, time to fix the Z homing speeds to be something normal. Right now it homes very slowly because I'm looking at how the ISR services pulses. I'll try something more rational soon, and then homing should behave normally, and hooking up leveling probes to the mini will be straightforward.

Last night I was able to successfully do a few test prints of the lucky cat and butterfly using the V2 (STM32F070) MCU. This means this project is drawing to a close, of sorts. Marlin main now supports the printer, V1 and V2 both click-compile for the most part. The sample config will work if I update the documented settings on how to compile, or I may update the sample config. 

V3 (with auto-level) is a matter of defining the probe pin (I believe it's PA3) and configuring ABL, but to do that, I'd need to re-enable EEPROM emulation. It doesn't currently work under ST's core using the unified HAL. It's really one of the last things to be needed, and once it's done, short of adding WIFI printing to Marlin Main, and Malyan's custom GCODE, there's not much left.

I created a config for the Malyan M300 delta /MPMD and may do a test with it as an extension of this, but the delta more or less just works. We'll see once I draw the V2 work to a close.

V3 is a possibility, enabling ABL, except I don't have a V3 - I'll need to use my V1 + probe or the bl-touch I wired to a V2. 

Delta is a possibility.

Soon I'll get back to the Lerdge project.

I have been experimenting with a number of different probes, and returned to something I'd only gotten tangentally working - a BL touch sensor on the V2. Why the V2? Because nice, new V2 motherboards have a handy JP socket exposing Serial2. Older boards all the way back to original V1s have solder pads or through board vias you can put a header on, but the V2 came ready. So I built a little adapter to let me test it.

In short, there's a lead from the 12V input which runs to a buck converter, providing 5v for the BL-touch and powering the 5v side of a 5->3v level shifter. Power and Ground from Serial2 plus PA3 go to the low side of the 5->3v level shifter, and the rest of the wiring is pretty much standard bl-touch. 

Does it work? It does. It probes just fine, though it's not clear to me why the bl-touch can't be at an agle. There's probably a reason. 

The MalyanM200/Monoprice Mini has an interesting feature in that it supports wifi printing - the ability to connect Cura or something similar via wifi and print directly that way. This is accomplished via  combination of features, starting with the ESP8266 which drives the LCD. By default the ESP bridges telnet to serial.

The Malyan firmware also supports a sort of dual host support, in which bytes with the high bit set from the UI are UI commands, and bytes with the high bit off are channeled commands.

Marlin 2.x has multihost support in which you can have multiple serial outputs, but what is missing is a simple bit of glue: A ring buffer Serial implementation which can be fed the channel bytes, while the UI code consumes the encoded ones. Fortunately, both the ESP and Linux HALs have a sort of fake Serial, which I quickly adapted to MemorySerial, and plugged into the LCD code.  There's a new feature in configuration.h, WIFI_PRINTING, which enables this. 

I'll be testing this once I can get my mini joined to the WIFI network. Malyan's firmware supports custom GCODE commands to set the SSID and password. Marlin does not. I'll need to figure out a way to get it set up.

The last missing chunk only really works on Windows. MalyanLink uses the opensource Com0Com virtual com port driver to link a host and port to a virtual com port. I'm not sure what I'll use, yet, since OSX doesn't let me symlink using netcat to create a virtual modem.