Loose Ends

The Future?

I think the mpmd_marlin_1.1.x firmware has reached a fairly stable state. The Monoprice MP Mini Delta's main board has limited I/O and limited program space, so it is challenging to add more of anything in the way of features or capabilities to the firmware. Still, along with bug fixes, there are "loose ends" that could be pursued in the future:

• Better Documentation. Hopefully, as the firmware gets onto more printers and more people report their experiences, the wiki documentation will improve and generally become more useful.

• Long file name (LFN) support is incomplete with the firmware's inability to create a file with a long file name or to properly delete a file with a long file name. True LFN support is a thorny issue -- there are character set problems and file name length considerations that are unresolved in the firmware, and are probably not worth addressing. Also as it stands, the delete command (M30) will delete a file, but the command only removes the DOS8.3 name leaving behind the long file name (if it exists) and creating a mild kind of disk corruption. In the spirit of "do no harm", though, the M30 command should be fixed to properly delete a file with a long file name. The fix is not likely, though, as it would be quite a chore to squeeze such a fix into the existing code. Better would be to replace the SD code with something specifically designed to support long file names.

• The __HAL_SystemReset() function does not seem to work. The function allows the firmware to force the CPU to reset, but when called, the printer resets and hangs. I've been quietly grousing about the HAL libraries, blaming HAL for this issue, but it occurs to me that the real issue is perhaps with the printer's bootloader. That is the bootloader, by design, detects the system reset and halts the machine. As a work-around, the firmware currently resets the CPU by executing a tight loop and waiting for the CPU's watchdog timer to reset the machine. Here again, though, the bootloader seems to detect this type of reset and deviates from its power-on reset behavior. After a watchdog reset, the bootloader will flash the firmware.bin file (if found) regardless on the existence of the fcupdate.flg file -- not the intended behavior whenever we need to restart the Marlin firmware. A proper fix would avoid involving the bootloader by jumping to early initialization code instead of resetting the CPU. MAYBE FIX   Fixed in 119R11.

• Marlin's linear advance feature (LIN_ADVANCE) does not work. When this is feature is compiled into the firmware, the printer generates a hardware fault (reboots) immediately as the printer goes into motion -- regardless of whether linear advance is enabled or not. It would be nice to get this feature to work, or at least figure out why it doesn't.   Added in 119R11.

• The Octoprint plugin and Pronterface script that offer faster uploads to the printer's micro SD card are early, proof of concept works. The idea was to get something out in the field to gauge the interest in a faster upload feature, and to help steer the subsequent development effort.

• WIFI. Though the firmware supports the WIFI that's built into the printer's display board, the connection is not reliable. Short commands could work, but the machine often dropped characters during any lengthy command output. Plus, I never did figure out how the file upload worked. So for the most part, the connection over WIFI was not very useful. It's disabled for now in the firmware. Perhaps with better understanding and insight, something useful can be done with the WIFI in the future.

• When I started the project, the Malyan LCD (the printer's graphical display and three buttons) seemed more than adequate for a user interface. Turns out, the display has so many limitations and issues that it can do very little than it is doing with the stock firmware. As a work-around, I used the printer's LED/push-button switch as a "bare minimum" of user interface to support G/M-codes that expect input from the user. I think a much better approach would be to reprogram the display to function more like a simple terminal -- an idea I toyed with, but without some good technical documentation for the display board, I wasn't up to the challenge.

• There should be some way to configure temperature sensors without having to rebuild the firmware. One possibility is to locate the two lookup tables used by Marlin to compute the nozzle and bed temperatures in the same flash block as the user settings. There would then be some kind of "out-of-band" mechanism to modify these tables to support different temperature sensors. The scheme would require modifying Marlin's use of lookup tables to convert an A/D reading into a temperature value; finding a way to conveniently specify and compile temperature lookup tables into a sensors.bin file; and combining a firmware.bin with a sensors.bin to make a new firmware.bin to be programmed into the printer. Of course, the Makefile and LinkerScript.ld files need changes to locate the lookup tables in the proper flash block during the link phase of the build process.