119r13

I saw there were placeholder "load / unload filament" files in the setup_gcode folder and it prompted me to make my own. It seemed to have worked at first: It would do things slowly as I didn't dial in the feed rate or not move enough of the filament. But it still worked. Now it doesn't even move the extruder before it 'finishes'.

Here is what I put:
"FILAMENT_LOAD"
G21
M109 S200
G28
G1 Z10 F2500
M83
G92 E0
G1 E450 F2000
G1 E80 F250
G1 E-3 F250
G28
M118 {TQ\:100}{SYS\:STARTED}#
M118 {E\:Filament Loaded!}#

"FILAMENT_UNLOAD"
G21
M109 S200
G28
G1 Z10 F2500
M83
G92 E0
G1 E-560 F2000
G28
M118 {TQ\:100}{SYS\:STARTED}#
M118 {E\:Filament Unloaded!}#

I liked how the M118s flashed text on the screen so I kept it in.

@cscott points out in issue #4 that the firmware's default settings are not suitable for printers that use 1/8 micro-stepping motors. I completely failed to mention this fact anywhere in the source code or the documentation -- I appreciate @cscott calling attention to the omission.

In order to use mpmd_marlin_1.1.x firmware with these printers, a few of the settings need to be adjusted BEFORE peforming the auto-calibration steps on the printer. As of release 119r09, the contents of the micro SD card include the command, M92_XYZ57_E48.gcode, to assist. Using the /gcode_setup commands on micro SD card, the initial calibration becomes:

M502_FACTORY.gcode
M92_XYZ57_E48.gcode
AUTO_CALIBRATE.gcode
M500_SAVE.gcode

More information can be found in the wiki, Calibrating the Printer.

I've been running your 119r09 for quite a while, decided to upgrade to the latest 119r14. I downloaded and flashed the correct firmware bin file for my printer (0001 AC FAN 10A).

When I run the AUTO_CALIBRATE.gcode, the printer correctly homes itself twice, then the back axis goes all the way up, while the other two axes go all the way down, causing the extruder platform to crash into the back axis rails. I figured out that the issue was resolved by running M502 before AUTO_CALIBRATE.gcode. Evidently something in the saved settings from 119r09 was messing with 119r14's ability to correctly calibrate. I recommend adding this to your setup instructions, or including an M502 in the AUTO_CALIBRATE.gcode script (or manually changing whatever particular geometry settings are the problem).

Adjusting M665 R or M665 L individually will change both the X,Y dimension scaling and the bowl/cup amount. However, dimensional scaling can be decoupled from the bowl/cup adjustments by adjusting both R and L at the same time. For a stock MPMD, the formula are (where K = 1.5):
L(new) = L(old) + K(R(new) - R(old)) ;for adjusting R

I have only measured K for a stock MPMD. Other delta geometries may have a different K value.

If K were a parameter, then default of K=0 would not change current L values

FYI: R(new) = R(old) + (L(new) - L(old))/K ;for adjusting L, but not used by me to date

I believe that the L (length of the arm), is the easiest to measure, so the average arm length of 6 arms is the number I would start with. Then determine the R number that brings the dimensional accuracy across X,Y (or tower X,Y,Z), to 100mm. Once that is done, you don't want to lose the dimensional accuracy while doing the G33 to get the bowl/cup flattened out across the bed.

I would expect that M665 A,B,C should be preloaded with the difference in arm lengths per tower. M665 D,E,F could start out with zero. If a bowl/cup adjustment needed to be made on a per tower basis, then the above formula can be also used with the D,E,F values. This probably needs to be done externally to the FW, because it is too involved and the program space is too small.

In theory, the L,A,B,C values would be measured and never change. The R,D,E,F values could be measured or found by trial and error iteration. The bed should come out flat and dimensionally accurate. However, in practice this does not seem to be the case due to imperfect geometries in the printer construction. Both L and R values need to be adjusted a little from their measured values to get the best dimensional and flatness results in practice. There is only one best answer for L,R that gives a flat, dimensionally accurate bed level.

I have encountered hesitation with the printer motion printing from SD card whenever the USB cable is physically attached to laptop and no software on laptop has the port open. Normal operation is resumed by unplugging the cable or opening the serial connection on the laptop. While recording video to post, a reboot was encountered and maybe similar to #47. This behavior was repeatable.

Troubleshooting consisted of trying different usb cables, different port on laptop, and different computers.

Easy work around for this issue but not the expected behavior.

I have a few suggestions for updating the Quick-Start Documentation based on some recurring questions in the Facebook Group and my experience making/updating tutorials to make them more noob-friendly. I would do the changes myself, but the Wiki is not open for editing and it appears that I cannot do a pull request for wiki updates (???).

-Add more direct links in the Quick-Start Guide to point to relevant topics.
Some users had trouble finding mpmd_marlin_1.1.x-uSDCard.zip, which I can understand. A note that it can be found near the bottom of the latest release page (hyperlinked), could be helpful here.
I realize that "Configuring a Print" is already linked, but I think adding a direct link to the Start/End Gcode could help drive the point home. I.E., 95% of the time anyone started to ask any questions about flashing MPMD Marlin 1.1.X or its predecessor, this would come up.
A reference to this issue within the "Calibrating the Printer" section may also be helpful.

-Firmware Flashing Details (including alternate method):
Here is a quick Google Doc I slapped together, which contains a method to flash the firmware via STLink. Feel free to link the document directly or extract the information as you see fit.
https://drive.google.com/file/d/1qK-VuOvtXk0OAKperCJYZGfuytqHtzNo/view?usp=sharing

-More emphasis on Start/End Gcode: I saw a lot of people simply using the same gcode from the built-in Cura definition. I'll copy-paste some suggested notes to add to the Start Gcode page.

Start Gcode Notes:

There are a few small, but notable, differences between the recommended Start Gcode for stock firmware versus MPMD Marlin 1.1.X

1. You should delete any configuration lines (M92, M665, M666, M301, M304, M500, etc.) from your Start Gcode, because they could interfere with other values calibrated earlier in the Quick-Start Guide. I.E., it is recommended that you store your configuration values to EEPROM.

2. Your z-offset was set earlier using M851 in the "Calibrating the Printer" section of the Quick-Start Guide. Return to that section if you need to adjust it.

3. G29 does not work the same way as stock firmware. Your MPMD Marlin 1.1.X G29 line should just read "G29 P0" (see the examples) to do a single probe using the stored mesh from the "Calibrating the Printer" section of the Quick-Start Guide. Just running "G29" will redo the entire 7x7 bed at the default 55 mm probe radius.

The 7x7 G29 probe pattern is not ideal for the MPMD delta printer. The first image shows a photo of a carbon paper imprint of the G29 pattern (round boxes), and a more ideal pattern (square boxes). A more ideal pattern is radial and puts 12 probes around close to the outside diameter (50-55mm). The red arrows show where the maximum errors will take place between an ideal pattern and the current G29 pattern. This is because there is a non-linear error near the outside edges -- a pattern that repeats 3 times around the diameter.

A radial probe pattern would be best, but even a square pattern may be improved with a 7x7 matrix. The second figure shows 8 more probe points near the outside diameter. The pattern would have to be shrunk to fit those 8 new points within the 55mm radius. If it easy to do, the error between the G29 (2 versions), can be compared to the radial probe points to experimentally determine the improvement.

I noticed that in my previous M4MPMD FW the M205 had a B20000 parameter. The Marlin doc says this is the min segment time. When I do a M530 with 1.1.x, it shows M205 Q20000 parameter. Marlin doc does not mention this parameter. Is this a new code or a typo?

It looks like the firmware has some checking for completely ridiculous G29 results caused by one of the switches getting stuck down and/or the switches being so finely balanced that just moving the print head around closes them, and will abort the G29 procedure if it detects this. When that happens, the LCD will show an error message and the indicator LED will flash red. Pressing the button on the front panel will return the LCD to normal operation, but the LED keeps flashing red and the printer won't respond to serial commands until you power cycle it. Since I'm calibrating it via serial rather than using the gcode files on the SD, this is annoying.

Here is a video showing what happens. The crash happens at 1:50.

Here is my serial log.

11:22:27.707 : N15 G29 V3*99
11:22:27.707 : G29 Auto Bed Leveling
11:22:29.804 : echo:busy: processing
11:22:31.801 : echo:busy: processing
11:22:33.807 : echo:busy: processing
11:22:35.804 : echo:busy: processing
11:22:36.299 : Bed X: 0.000 Y: -55.000 Z: 0.104
11:22:37.805 : echo:busy: processing
11:22:39.801 : echo:busy: processing
11:22:39.917 : Bed X: 37.000 Y: -37.000 Z: 0.548
11:22:41.806 : echo:busy: processing
11:22:43.189 : Bed X: 18.000 Y: -37.000 Z: -0.075
11:22:43.803 : echo:busy: processing
11:22:45.806 : echo:busy: processing
11:22:46.288 : Bed X: 0.000 Y: -37.000 Z: 0.135
11:22:47.803 : echo:busy: processing
11:22:49.376 : Bed X: -18.000 Y: -37.000 Z: 0.169
11:22:49.802 : echo:busy: processing
11:22:51.804 : echo:busy: processing
11:22:52.546 : Bed X: -37.000 Y: -37.000 Z: 0.487
11:22:53.803 : echo:busy: processing
11:22:55.804 : echo:busy: processing
11:22:55.844 : Bed X: -37.000 Y: -18.000 Z: 0.109
11:22:57.804 : echo:busy: processing
11:22:59.037 : Bed X: -18.000 Y: -18.000 Z: 0.040
11:22:59.804 : echo:busy: processing
11:23:01.805 : echo:busy: processing
11:23:02.151 : Bed X: 0.000 Y: -18.000 Z: 0.177
11:23:03.805 : echo:busy: processing
11:23:05.260 : Bed X: 18.000 Y: -18.000 Z: 0.110
11:23:05.805 : echo:busy: processing
11:23:07.803 : echo:busy: processing
11:23:08.452 : Bed X: 37.000 Y: -18.000 Z: 0.272
11:23:09.805 : echo:busy: processing
11:23:11.800 : echo:busy: processing
11:23:11.920 : Bed X: 55.000 Y: 0.000 Z: 0.329
11:23:13.803 : echo:busy: processing
11:23:15.255 : Bed X: 37.000 Y: 0.000 Z: -0.015
11:23:15.799 : echo:busy: processing
11:23:17.804 : echo:busy: processing
11:23:18.442 : Bed X: 18.000 Y: 0.000 Z: 0.210
11:23:19.804 : echo:busy: processing
11:23:21.579 : Bed X: 0.000 Y: 0.000 Z: 0.049
11:23:21.941 : echo:busy: processing
11:23:23.949 : echo:busy: processing
11:23:24.657 : Bed X: -18.000 Y: 0.000 Z: 0.350
11:23:25.947 : echo:busy: processing
11:23:27.885 : Bed X: -37.000 Y: 0.000 Z: 0.148
11:23:28.087 : echo:busy: processing
11:23:30.087 : echo:busy: processing
11:23:31.195 : Bed X: -55.000 Y: 0.000 Z: 0.292
11:23:32.086 : echo:busy: processing
11:23:34.094 : echo:busy: processing
11:23:34.537 : Bed X: -37.000 Y: 18.000 Z: 0.148
11:23:36.092 : echo:busy: processing
11:23:37.742 : Bed X: -18.000 Y: 18.000 Z: 0.020
11:23:38.117 : echo:busy: processing
11:23:40.125 : echo:busy: processing
11:23:40.852 : Bed X: 0.000 Y: 18.000 Z: 0.333
11:23:42.122 : echo:busy: processing
11:23:43.992 : Bed X: 18.000 Y: 18.000 Z: 0.109
11:23:44.188 : echo:busy: processing
11:23:46.190 : echo:busy: processing
11:23:47.254 : Bed X: 37.000 Y: 18.000 Z: 0.241
11:23:48.189 : echo:busy: processing
11:23:50.187 : echo:busy: processing
11:23:50.502 : Bed X: 37.000 Y: 37.000 Z: 0.054
11:23:52.186 : echo:busy: processing
11:23:53.789 : Bed X: 18.000 Y: 37.000 Z: 0.122
11:23:54.188 : echo:busy: processing
11:23:56.191 : echo:busy: processing
11:23:56.927 : Bed X: 0.000 Y: 37.000 Z: 0.241
11:23:58.192 : echo:busy: processing
11:24:00.096 : Bed X: -18.000 Y: 37.000 Z: 0.223
11:24:00.292 : echo:busy: processing
11:24:02.298 : echo:busy: processing
11:24:03.431 : Bed X: -37.000 Y: 37.000 Z: 0.049
11:24:04.368 : echo:busy: processing
11:24:06.025 : Bed X: 0.000 Y: 55.000 Z: NaN
11:24:06.030 : Error:Probing failed
11:24:06.035 : X:0.00 Y:55.00 Z:1.40 E:0.00 Count X:7566 Y:7529 Z:13938

Hi.

I looking for way to connect and support for classic LCD like 2004 or bigger, to replace standard LCD from stock and add classic marlin menu with all functions.

It is possible?

I followed the instructions and ended up with a non functioning printer.

The display looks like this: https://i.imgur.com/TSITvip.jpg

The web page gcode box does not respond, the serial port also will not connect.

I renamed mpmd_marlin_1.1.x-119r15-SM0001-ACfan-10Alimit.bin to firmware.bin and put it in the root of the sdcard as instructed with the rest of the files in the zip.

I am trying to heat up my printer and it stopped at 109 and had a red flashing light on the led by the DC jack. Could it a issue with the sensor?

I have studied the repeatability of the MPMD bed probing for a few years. I believe that there is a better way to get a more repeatable result in less time than averaging 3 probes. My spreadsheet probes twice (t probe average each). I average those results, then if the two probes differ, I color code the result by the magnitude of the difference. That way the user is alerted that something was not right and can opt to rerun the whole probing pattern gcode.

Since FW has access to all probing results and can change the probe sequence on the fly, a different approach could be used. I have noticed that most multiple probes at the same location come up with the same result or within one count. However, on occasion there is an outlier that messes up the average. The two probe method which throws away the first probe and takes the second tries to address that. However, both of these approaches are blind sequences. An intelligent approach would give a better result than either of these.

My suggestion is this algorithm:
Take two probes. If they match within one count, return the average result. If not save the last probe and repeat another probe... etc.

It combines the goodness of having one probe to unstick the mechanics, getting rid of outliers and having a little averaging of close numbers. And it will usually only take 2 probes to get a better result than 3.

This is very easy to test to see how much it improves the variability of the probing results, just like my spreadsheet does now.

In Configuration_adv.h, I'd like to suggest setting EXTRUDER_AUTO_FAN_SPEED to 192, like it is in Marlin4MPMD 1.3.3.

This should help prevent overcooling on the first layer and maybe help prevent thermal runaway early in the print. My assumption is that you could still raise the fan speed to 100% via slicer settings.

I had issues with this after both upgrading my hot-end fan and trying to print PETG. I can reach 240 and run PID Autotune while homed, but when the nozzle gets close to the build surface, my temperature rapidly drops, resulting in thermal runaway. I was able to print PLA at 215 with the same hardware setup with success. I just went back to using a weaker fan for the time being.

I may try compiling the firmware this way myself later this month, but I think I just expended the rest of my free time for the week.

my E stepper motor dose not work just clunks and hums
119r08
mpmd_marlin_1.1.x-119r08-SM0000-ACfan-05Alimit.bin
and
mpmd_marlin_1.1.x-119r08-SM0001-ACfan-05Alimit.bin

Moved to mpmd_marlin recently and have the 12V 10A PSU. All is working great except for some odd bed-heating issues. If I set a bed temp of 70C then my readout quickly approaches 70 but never arrives. The reading will stay as 68.3 - 68.7 indefinitely. This isn't linked to the power of my bed heater as the same thing happens if I set temp to 75, 80 or other values - the reported bed temp is always sitting 1.2-1.8 degrees below the target. Only way to do a print is to set the bed to a high temp, wait until the temp is way above desired then start the print and wait for the bed to cool until it hits the desired range. Then it'll go back to sitting 1.5 degrees under the desired temp but the print will run. Prints are otherwise fine and quality is ok.

Is there a way to configure this to not back-off the heating before hitting the desired bed temp?

Slicing with Cura, printing with Octopi. Printing on a borosilicate glass bed attached with thermal pads.

Running latest mpmd_marlin_1.1.x-119r13-SM0001-ACfan-10Alimit.bin

Buried in the discussion of issue #53 is the discovery that G29 P0 simply does not work.

@mulcmu writes:
There might be an issue going on with the G29 P0 correction. I started a print with a 3mm thick piece of acrylic placed on the bed. G29 P0 did the double tap on the acrylic which was then removed before the printing started. I expected first layer to start getting deposited 3mm above the bed, however print started on the bed surface.

@aegean-odyssey writes:
@mulcmu, your test should have produced the result you expected; that the nozzle should have stopped above the build plate. Something is not right. I'm thinking that after the G29 P0 probe, the machine is not taking up the new height value. Does homing (G28) after the G29 P0 change the outcome?

@aegean-odyssey writes:
G29 P0 does not work as advertised. Actually, it goes through all the motions and then sets the height to the value it had when it started -- it's a bug. I'll track it down. As if G29 wasn't confusing enough!

The G30 is supposed to probe one point and generate the Z offset. The stock FW actually did 2 probes and generated two results. M4MPMD probed once and generated one result. M1.1.x is probing the bed 3 times for each call and generating one result. What algorithm is it using to turn 3 probes into one result? Sorry if I am asking a question that is already documented. I just did not see it. The answer does affect my alignment algorithm.

I'm having some trouble with this firmware (mpmd_marlin_1.1.x-119r11-SM1110-PCfan-10Alimit) where the carriage is colliding with the rear bed clip during levelling. Would you be able to compile a release with a smaller probing grid?

My printer is using the the stock parts.

Thanks

When performing G29 or G33, the nozzle just stops as it is about to touch the bed, not even 1mm above. The nozzle will never touch the bed, only over few mm above it. If I cheat and manually bring the nozzle closer to bed and perform G29 without homing, it starts leveling properly.

-I'm running firmware 119r14.
-I made sure to check the whole wiki and other opened issues but I don't see anything to help, I tried factory reset, correction for 1/8 stepper.
-I checked if there was any mechanical/electrical issue but everything seems to be ok.
-The printer has upgraded stepper drivers to TMC. Everything was running ok with stock firmware and M4MDM, no extra steps had to be done.
-Checking at CALIBRAT.TXT, the log has ".Height:130.00 ". Maybe the step per mm is off?

Hello,

nice Project! :)

Im getting a Thermal Runaway Protection error with the 5A Firmware.
Im not sure if this only belongs to the 5A, or something else.

Firmware:
119r05 and 119r06

Steps to reproduce:
Cold Printer
Start an Print on the SD Card
Target Temp on Display for Bed 55°C
It heats up, afer reaching the target Temp, it heats the Nozzle (Target 210°C)
While heating the Nozle my Bedtemp falls under 37°C, the Nozzle is at this time still heating at around 160°C
Printer stops with Thermal Runaway Protection on the Display

When slowly heating the Nozzle in 5°C steps the Warning doesnt apear and i can Print.

So my MPDM has the Gigidigit Silent board and the Bed Clips and a 10 Amp power supply .

i used the : mpmd_marlin_1.1.x-119r14-SM0001-ACfan-10Alimit Firmware what works on my printer .

I jumped from your Marlin 12 to 14 and have a problem that right when the print ends the printer freezes with nozzle and bed heat still on .
Its the same end G Code like i used on your Marlin 12 Firmware :
; mpmd_marlin_1.1.x firmware
; heaters off, home, motors off
G1 E-3 F100
M104 S0 T0
M140 S0
G1 E-3 F100
G28
M84

is there a problem with the code ?

second problem :
during the calibration process one test point in the front left corner is out of the printing bed ...
and over all where are the probe offset commands in the Settings folder ? 🧐
with best regards Björn

I noted that on stock FW, the thermistor readouts on my Repetier-Host Mac graph (USB connection) were very noisy. When I switched to Marlin4MPMD FW, the graphs looked rock solid. Now switching to Marlin 1.1.x, the graphs are once again noisy. The LCD readout is also showing the noise. I recall a conversation I had with Mickey that he worked some magic to get rid of the noise. I also went to a lot of effort to construct a thermistor table with him to match the readouts of the stock FW values. Did you use that table? Are you taking full advantage of the Marlin4MPMD work?

I uh... don't really know what else to put aside from I'm using the 119r14-SM0001-ACfan-10Alimit variant. It crashed twice when I started the 25mm calibration gcode but worked when I started the same gcode through Pronterface via "SD" print w/e it's called.

I don't know what can be done about this but figured I'd at least mention it.

I was following the Wiki for calibration, and when running the AUTO_CALIBRATE.gcode I thought something was wrong at first as I did not expect it to repeat so many times. Could you add a note to the documentation that this is normal for the auto-calibration to "loop" several times and it takes a while to complete?

I was wondering how I would go about altering the stepper motor currents. I have done some research and was thinking perhaps an M907 command would work, but it didn't. I pulled the heatsink off the board to check if there were pots to alter the current (spoiler alert, there aren't) I suppose if this were regular Marlin, I would go into Configuration_adv.h and change the digipot I2C motor currents and then upload the new configuration to the board. However, for this branch of Marlin, I have no idea how to go about making such a change and then compiling and uploading the firmware. I have visual studio code and the latest version of Platform IO for VSCODE, but I don't know enough about programming to go about making the changes I would like. Any help on how to go about doing this would be great.

Hi I change my hot end over to a e3dv6 heartbreak and heatsink but with the original heater block and I believe my Z height at 450 is no longer adequate. How do I go about finding the correct Z height. Thanks

I have the Indiegogo model and installed the SM0001 AC 5ALimit firmware using the original SD card that came with the printer. Seems that the firmware installed fine, I can home and preheat but after the upgrade I am unable to get any SD card to read. “sd card is empty” pulls up every time I select Print. If I reload the card with the bin and flg files it will reflash the firmware, but once rebooted it says the card is empty. This leads me to believe that the SD card is working well but there’s an issue with the firmware reading the files after a boot.

Restoring to stock v41 firmware and the SD card reads normally.

I just upgraded to the popular BMG extruder. It is a double toothed wheel extruder and a 4:1 gear reduction. My G92 is E430 now (was E100). The extruder direction direction was correct. It works fine from the LCD switches all the time. Obviously the extruder motor runs over 4x the step rate as direct drive extruders, but has much higher torque. It can print a part from the SD.

First problem is that the extruder has no way to manually release the filament. It must be loaded and unloaded from Gcode or front panel. My Bowden tube path is about 600mm. There is an M603 load/unload length setting that will not allow that long a number. The other Gcode motion commands will also not allow that size move.

Second problem is that sending extrusion G-codes via USB sometimes works, sometimes is ignored, and sometimes runs in the opposite direction. I am still at a loss on when it decides to ignore or reverse the direction. When reversed, both extrude and retract are reversed. It seems that the first time I send the command from USB it works then the next ones after that are ignored. If I run the LCD manual extrusion, it works and I can get only the next G-code extrusion command to work. I have cold extrusion enabled and pressure Advance is enabled.

The extrusion sequence sent by the console program is: G91, G1 Exxx.xx, G90

Hi, I installed the AC fan version of the newest firmware and was able to print successfully. When I flashed the PC fan version, I am now unable to start any print successfully. After flashing the firmware, I've tried restoring factory settings as per instructions, rerunning autocalibrate, etc.

After starting a print, it will successfully come up to temperature, home itself, then hang for a second or two before the printer reboots. I am able to control the fan manually through Gcode, and can manually move print head and extrude filament through repetier but am unable to do an actual print. I have tried through both usb printing and SD card to no avail. The log in repetier doesn't really reveal any information about whats happening besides a simple "communication timeout - reset send buffer block" error.

Any ideas?

Based on the wiki and reading over the issues, it looks like at least the following should be noted:

• AUTO_BED_LEVELING_BILINEAR is enabled, so the relevant documentation page is this one and the pages on UBL, 3-point, linear, etc leveling should be ignored
• G29 C1 is now "compute least-squares leveling plane based on existing mesh" rather than "generate fake mesh for testing"
• G29 P0 has been added and does a simple start-of-print height probe (I think, based on comment here)
• RESTORE_LEVELING_AFTER_G28 is disabled, so you need to re-enable the leveling mesh in your starting G-code after homing with G28; M420 S1 should do this, it's not clear if G29 P0 will as well or if you should use both

Twice tonight, hot end has traveled in -x direction before starting a print. Using the start g-code for Cura from wiki. After probing bed, seems to home okay, but then the hot end doesn't lower to Z60, seems to wait the 4 second pause and then moves in -X direction. I then removed power. In both instances usb was not connected, printing from sdcard.

After power cycle same file from sdcard prints fine.

mpmd_marlin_1.1.x-119r09-SM0001-ACfan-05Alimit.bin was installed this morning. I had about 20 hours of runtime with 119r08 before that. Machine was originally V37.

; home axes, probe/adjust z-offset, and pause 4s
G29 P0
G0 X0 Y0 Z60 F3600 ; [DV: added feedrate]
G4 S4

I flashed the mini delta with mpmd_marlin_1.1.x-119r08-SM1111-PCfan-10Alimit.bin. The reason I chose this version was because I have altered the extruder and had to flip the cable to make it work properly. Anyway, after having flashed the board with the new firmware, I can no longer connect to it via USB because it is not recognized by my Windows 10 computer. When I connect via USB, the printer now shows up as "STM32 Virtual ComPort in FS Mode" and as "USB Serial Device(COM4)". Because of this, I can no longer connect to the printer via USB using PronterFace or Repetier-Host.

In issue #4, @cscott comments that it is common practice to heat the nozzle and bed before performing the auto-calibration. The rationale being that whatever thermal expansion the machine experiences during printing should also present during the calibration process to improve the automated calibration results. @cscott makes a good point, here.

Of course this is perfectly reasonable and easy to do -- preheat the printer using the front panel controls. Once your desired temperatures are established, run the auto-calibrate command.

During our general testing, we've calibrated the printer with and without preheating the MP Mini Delta. Qualitatively, this does not seem to very much affect the calibration, but I hope to do more specific testing and report the results. I think it will be interesting to compare the two approaches and put some numbers to it.

Hey, thanks for working on this port!

When I installed it on my MPMD, the fan for the electronics would not turn on, and when I tried to print something, the fans on the hot end would not turn on either.

If it helps, the printer is pretty old (open box buy in 2018) and came with the V43 firmware.

Thanks!

Dear All,

I just got a minidelta, found that the stock firmware was horrible, and installed MPMD, which is a HUGE improvement; thanks A LOT!!!
But the first layer was not perfect, even using AUTO_CALIBRATE.gcode, so I began tinkering.
I was able eventually to recompile a working MPMD, using Ubuntu 18.04LTS and platformio.

Then I upgraded to Ubuntu 20.04.1LTS, and the Makefile (make all) made a fatal error when linking:
/usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld:/home/mgouget/mpminidelta/mpmd_marlin_1.1.x/stm32f0xx/LinkerScript.ld:181 cannot move location counter backwards (from 0000000008020c68 to 000000000801f800)

When commenting the UNUSED_FLASH_MEMORY section in LinkerScript.ld around line 181, I got:
/usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: mpmd_marlin_1.1.x-119r14-ACfan.elf section '.rodata' will not fit in region 'ROM'
/usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: region 'ROM' overflowed by 5224 bytes

I tried to spare some memory by commenting in configuration.h EEPROM_CHITCHAT, but I got the same 5224 overflow.

It seems that the new version of the tool-chain is not as space-efficient as the old one.

Here are the versions:
arm-none-eabi-g++ (15:9-2019-q4-0ubuntu1) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
GNU ld (2.34-4ubuntu1+13ubuntu1) 2.34

Unfortunately, I don't have the versions of the previous tool-chain.

Any tricks or ideas to be able to recompile MPMD again?

Cheers,

Michel

I have been doing filament change tests over the past few days. I have noticed that when I try to specify my own U value to the M600 command that it does nothing at this step. Omitting the U value results in an unload retraction of 100mm as defined in the configuation_adv.h.

I see that the sign of my U shouldn't matter but just to be thorough I tried:

• U300.00
• U-300.00
• U300
• U-300

I couldn't get pronterface to reliably connect to the MPMD from my machine (thinkpad T460p, SS USB port) on 119r07 or 119r08. It would appear to connect, but drop half or more of the characters sent from the mini delta. Reverting back to 119r06 made the serial work properly (at 115200 baud).

Hello,
I would like to add some of my configuration data into the firmware so that I can take it out of my start gcode. I've cloned the project in VScode and it looks like the files in the "marlin" folder are default marlin files and all the changes you have made are located in the "marlin changes" folder. I was tempted to just replace the default files with the files from the marlin changes folder, but I am not sure what changes need to be made to account for stepper setup, PS amperage, and preferred fan operation. Any advice would be appreciated.

I am not sure if this is a bug in the firmware or an operator error. I am more inclined to think operator error. I compiled a recent copy of the source and changed the thermistor, and increased the print radius. Any idea what could be the issue?

I guess it could be called an 'improper boot'...

119r13
I've noticed that when my SD card isn't inserted the firmware version does not flash on the screen and the LED button is a solid red when I power the printer on. There is also no temperature readout either from the bed or hotend. This is repeatable for me.

I've witnessed it reset itself after reinserting the SD card without a power cycle, though it's not immediate.

In issue #4, @cscott reports crashes, erratic motion, and non-sensical output during the printer's auto-calibration process after installing firmware. In essence, the firmware appears to be badly broken.

From the photos @cscott supplied, it appears that the settings are suspect. In our own testing, occassionally after installing the firmware, the firmware does not properly detect and correct errors in the flash memory used to store its settings (the exact cause is not clear to us, yet). Bizarre or erratic motion is a strong indication that there is a problem with the settings. The M502 (load factory settings) command followed by the M500 (save settings) command should get the firmware operating from a known "ground" state.

Thanks to @cscott for carefully documenting his experience with the firmware.

Two crashes when running the AUTO_CALIBRATION script on mpmd_marlin_1.1.x-119r08-SM0001-ACfan-10Alimit.bin

My MPMD is an indiegogo model (ie, first or second production run).

First, if you have either of the heaters enabled (usually calibration is done with the bed and nozzle heaters enabled to allow them to thermally expand to their "while printing" sizes), the script crashes and resets the controller.

If you run the auto calibration gcode script w/o a heater enabled, it tries to move the head off the bed on the fifth point tested.

I am experiencing some thermal runway errors with my printer as it starts to print. I'm gonna check my hotend to see if anything jostled around as I caught the printer from being almost dropped by the back of my chair before I for sure say anything else. I get temp readouts any other time, but it seems to stop after a print starts.

Aside from physically checking it, should I look for anything else? I am running 119r14 and just about finished resetting the settings after a m502 (do I need to do that when updating the firmware from an older version?)

Firmware: 119r09 and 119r08

When both printing and in pronterface, G29 always fails at the last probe point and then tries to print above the bed, or sometimes even on an angle. Is there any way to use the 3 point probe from the default firmware?

Here is a video of it failing:

https://photos.google.com/share/AF1QipOpQerdXveVQ59nhlWZ6OPUsvph1YbeF6z00PXFSvpd83a3BwlIPNjzGnq16lESxA?key=alpPRFc3dk02QkxXakNrcHlfT1lGOThtdHIxTUFn

Feature Request: It was discussed briefly on Reddit, but I would like an option to perform a parabolic fit to the G29 mesh values via G29 C2 or something like that.

I have found that this works well on my WhamBam surface. I suspect it will also work well on stock surfaces. I hypothesize that this works well because the bed heater being located in the center causes the metal to warp a bit upwards in that location. For the same reason, it may not be the optimal choice for a glass bed.

The parabolic fit might also be a good choice for an alternate AUTO_CALIBRATE_SMALLER.GCODE script that uses the 50mm radius G29 discussed in another issue.

Parabolic Fit Post-Processing Script:
https://github.com/aegean-odyssey/mpmd-calibration-experimental

My Calibration Experiments/Results:
https://github.com/PurpleHullPeas/MPMD-AutoBedLevel-Cal/blob/PurpleHullPeas-advanced_readme/advanced/Advanced_Readme.md

Currently running mpmd_marlin_1.1.x-119r14-SM0001-ACfan-10Alimit I was testing repeatability of bed probing by running a gcode file that probes center, tower points and opposite tower points at 50 and 25 mm radius (13 points total). This cycle of 13 points repeated 10 times. Plotting the resulting data reveled the Z height drifting downwards:

I checked belt tension and bed clips adjustment, lubricated everything, bed heated and unheated. Same trend was observed, downward drift was very consistent between trials. More testing was completed to rule out stepper motor skipping steps such as changing speed (same drift), running the same pattern but only probing the center point, (In this case center point returned consistent probe value), repeated probing same points, and tested other patterns.

I found probing of repeating patterns that caused reported Z height to both drift downward and drift upward G30_TEST.TXT

do_probe_move in Marlin_main.cpp calls set_current_from_steppers_for_axis(Z_AXIS); I didn't dig any deeper but, this looks suspiciously like Cartesian printer specific and would cause shift in Z height.

Aut.o level works fine and bed spacing is fine with zoffset 0,
however if i increase the bed thickness and rerun g28,g29 the new thckness (glass) is not compensated.

From all the reviews of the stock MPMD autoleveling takes care of thickness changes. Noot so with this firmware v15.

am i missing something?

Is linear advance enabled in your firmware? With my other printers, I have noticed a major quality improvement in enabling it.