prusa3d / prusa-firmware

Firmware for Original Prusa i3 3D printer by PrusaResearch

Prusa Firmware MK3

This repository contains the source code and the development versions of the firmware running on the Original Prusa i3 MK3S/MK3/MK2.5S/MK2.5 line of printers.

The latest official builds can be downloaded from Prusa Drivers. Pre-built development releases are also available here.

The firmware for the Original Prusa i3 printers is proudly based on Marlin 1.0.x by Scott Lahteine (@thinkyhead) et al. and is distributed under the terms of the GNU GPL 3 license.

This repository contains development material only!

Build

Linux

There are two ways to build Prusa-Firmware on Linux: using CMake (recommended for developers) or with PF-build which is more user-friendly for casual users.

CMake

Quick-start

The workflow should be pretty straightforward for anyone with development experience. After installing git and a recent version of python 3 all you have to do is:

# clone the repository
git clone https://github.com/prusa3d/Prusa-Firmware
cd Prusa-Firmware

# automatically setup dependencies
./utils/bootstrap.py

# configure and build
mkdir build
cd build
cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=../cmake/AvrGcc.cmake
ninja

Detailed CMake guide

Building with cmake requires:

• cmake >= 3.22.5
• ninja >= 1.12.1 (optional, but recommended)

Python >= 3.8 is also required with the following modules:

• pyelftools (package python3-pyelftools)
• polib (package python3-polib)
• regex (package python3-regex)

Additionally gettext is required for translators.

Assuming a recent Debian/Ubuntu distribution, install the dependencies globally with:

sudo apt-get install cmake ninja python3-pyelftools python3-polib python3-regex gettext

Prusa-Firmware depends on a pinned version of avr-gcc and the external prusa3dboards package. These can be setup using ./utils/bootstrap.py:

# automatically setup dependencies
./utils/bootstrap.py

which will download and unpack them inside the .dependencies directory. ./utils/bootstrap.py will also install cmake, ninja and the required python packages if missing, although installing those through the system's package manager is usually preferred.

You can then proceed by creating a build directory, configure for AVR and build:

# configure
mkdir build
cd build
cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=../cmake/AvrGcc.cmake

# build
ninja

By default all variants are built. There are several ways to restrict the build for development. During configuration you can set:

• cmake -DFW_VARIANTS=variant: comma-separated list of variants to build. This is the file name as present in Firmware/variants without the final .h.
• cmake -DMAIN_LANGUAGES=languages: comma-separated list of ISO language codes to include as main translations.
• cmake -DCOMMUNITY_LANGUAGES=languages: comma-separated list of ISO language codes to include as community translations.

When building the following targets are available:

• ninja ALL_MULTILANG: build all multi-language targets (default)
• ninja ALL_ENGLISH: build all single-language targets
• ninja ALL_FIRMWARE: build all single and multi-language targets
• ninja VARIANT_ENGLISH: build the single-language version of VARIANT
• ninja VARIANT_MULTILANG: build the multi-language version of VARIANT
• ninja check_lang: build and check all language translations
• ninja check_lang_ISO: build and check all variants with language ISO
• ninja check_lang_VARIANT: build and check all languages for VARIANT
• ninja check_lang_VARIANT_ISO: build and check language ISO for VARIANT

Automated tests

Automated tests are built with cmake by configuring for the current host:

# clone the repository
git clone https://github.com/prusa3d/Prusa-Firmware
cd Prusa-Firmware

# automatically setup dependencies
./utils/bootstrap.py

# configure and build
mkdir build
cd build
cmake .. -G Ninja
ninja

# run the tests
ctest

PF-build

PF-build is recommended for users without development experience. Download or clone the repository, then run PF-build and simply follow the instructions:

cd Prusa-Firmware
./PF-build.sh

PF-build currently assumes a Debian/Ubuntu (or derivative) distribution.

Windows

Visual Studio Code (VSCode)

Prerequisites

• Visual Studio Code
• CMake Tools plugin
• Python
• Git Bash

First time setup

Start by cloning the Prusa-Firmware repository

git clone https://github.com/prusa3d/Prusa-Firmware

Open the Prusa-Firmware folder in VScode.

Open a new terminal in VScode (Terminal→New Terminal) and run

python .\utils\bootstrap.py

This will download all dependencies required to build the firmware. You should see a .dependencies folder in the Prusa-Firmware folder.

Reload VScode. If all works correctly you should see the VScode automatically configuring the CMake project for you. If this doesn't happen you likely need to set the CMake kit; This can be done in two ways:

1. Type Ctrl+Shift+P and search for CMake: Select a Kit. Select avr-gcc. If none appear, Scan for kits first.
2. If 1) does not work for some reason, as a last resort you can edit the CMake Tools settings. Search for "Additional Kits" and add .vscode/cmake-kits.json to the list.

After updating the kit, you may need to reload VScode.

Building

To start building a firmware, click the CMake Tools plugin icon on the far left side. You will get a very large list of targets to build. Find the firmware you'd like to build (like MK3S_ENGLISH) and select the small icon which shows "Build" when hovered over.

The built .hex file can then be found in folder Prusa-Firmware/build

Arduino IDE (deprecated)

Using Arduino IDE is still possible, but no longer supported. Prusa-Firmware requires a complex multi-step build process that cannot be done automatically with just the IDE. For a long time we provided instructions to use Arduino in combination with shell scripts, however starting with 3.13 the build system has been completely switched to cmake.

Building with Arduino IDE results in a limited firmware:

• Arduino IDE can only build a single, english-only variant at a time that you manually have to select
• The build will not be reproducible (meaning you will likely get a different binary every time you build the same sources)
• You need to download, patch and select the correct board definitions by hand

For these reasons, you should think twice before reporting issues for a firmware built with Arduino. If you find a bug in the firmware, building and testing using CMake should be your first thought. Issues regarding Arduino builds are answered by the community and are not officially supported.

Environment preparation

Install "Arduino Software IDE" from the official website https://www.arduino.cc -> Software -> Downloads. Version 1.8.19 or higher is required.

Setup Arduino to install and use the Prusa board definitions:

• Open Arduino and navigate to File -> Preferences -> Settings
• To the text field "Additional Boards Manager URLs" add https://raw.githubusercontent.com/prusa3d/Arduino_Boards/master/IDE_Board_Manager/package_prusa3d_index.json
• Open Board manager (Tools -> Board -> Board manager)
• Install "Prusa Research AVR Boards by Prusa Research"

Source code preparation

Clone or download this repository to your local drive.

In the subdirectory Firmware/variants/ select the configuration file (.h) corresponding to your printer model and manually copy it to Firmware/Configuration_prusa.h

Run "Arduino IDE", then

• Open the file Firmware/Firmware.ino
• Select the target board with Tools -> Board -> "PrusaResearch Einsy RAMBo"
• Open Firmware/config.h and change LANG_MODE to 0.

Compilation and upload

• Run the compilation: Sketch -> Verify/Compile
• Upload the result code into the connected printer: Sketch -> Upload

prusa-firmware's Issues

No "Error:" reported on serial line in case of thermal runaway?

I've had some users complain on OctoPrint's mailing list that a thermal runaway on their MK2s wasn't recognized by OctoPrint, which therefore kept bombarding the printer with commands and didn't stop printing.

I have still not gotten a log from the users in questions of what went over the serial, but I did a quick look into your MK2 branch here and found this function which I perceive to be the handler for thermal runaways:

https://github.com/prusa3d/Prusa-Firmware/blob/MK2/Firmware/temperature.cpp#L1163

If that assumption is correct, I'm either missing something crucial here or a thermal runaway produces NO output at all on the serial line, leaving any potentially connected hosts completely in the dark that something is amiss. If that is true, that's an issue - hosts depend on the firmware to inform them about any issues the host cannot detect since it doesn't have the data via a message prefixed with Error: in order to react accordingly, without such a message it's impossible for a host to do the right thing.

File names get cut off on OctoPrint

Please add this fix to the firmware!
MarlinFirmware/Marlin@2d22902

Without it OctoPrint can't be used to print from the web interface as uploading, selecting, starting files doesn't work.
http://i.imgur.com/5B4xcyh.png

Adding a "long pause" option

How many times has happened to you that you are printing and suddenly somebody want to go to bed and ask you: "is all this noise necessary?", kindly insinuating that you should shut down the machine and :( your creation. However, in some situation, it would be possible to simply pause and then resume in the morning.

At the moment I usually do that manually: pause, move the nozzle away from the object (or there will be some extra material under the nozzle), bring the temperature of the nozzle and the bed to 0.

In the morning I simply restore the two temperatures, select "resume printing" and the great MK2 do the rest, sometimes you cannot even see the point where I resumed.

My point is that it would be nice to have an extra option during the printing that says: long pause and do all those tasks automatically. If you like the idea, I could even try to provide some code, with some guidance.

Unpredictable axis move after Selftest on 3.0.10 RC1

On the 3.0.10 RC1, if I try to move Z axis just after SelfTest, the result is unpredictable, X and Y axis movement are triggered as well.

Once these X&Y axis move stopped, everything seems to behave as intended.

Use silent-mode only during XYZ calibration

If the printer have issue finding the calibration points during XYZ calibration, and that stepper current control is set to "power mode", the damage can be heavy on the bed if the nozzle goes deep in the bed (even with a paper sheet).

To limit damages in such an event, it would be nice to switch to "silent mode" just for the XYZ calibration, or event with special lower current control.

Does that make sense ?

Heating turns off

Hi, I've got a problem since the firmware
upgrade on this G-Code File. On a Z-Height of 1.35mm get a lot of offset and the heating turns off (see picture). I guess the disabled heating is the reason for the offset. I also used different layer heights for the objects in Slic3r for the first time, could this be related to that?
EDIT: I flashed the old firmware again (from the master branch) and now it prints fine (I also updated Printrun/Pronterface that could have been the problem too)

Front left calibration point not reachable

After upgrading to the newest Firmware 3.0.10 I am unable to perform the XYZ calibration anymore.

The printer hasn't changed, no new modifications added and with all other mods and the previews firmware version it was not a problem to calibrate the printer.
Since the update of currently only one of my printers, I cannot calibrate it anymore. It goes over all the points, and as soon as one think that the calibration has finished successfully, the extruder moves to the parking position, and I get the message, that the front left point couldn't be reached. Front left means the side of the X axis stepper motor, right? How comes, that Mesh Bed Leveling and Z calibration work but not the XYZ calibration if all of them uses this front left point?

Is it safe to downgrade to the previous firmware version to test if it is firmware or hardware related?

Bye
Martin

Selt Test fails on front fan in 3.0.10-8

Downloaded 3.0.10-8 on Apr 1st 2017 (no it's not a joke). Seems like the self test fails on the front fan on 2 of my printers. After the previous test (left fan test), it just fails without giving me a choice to select an answer. If, upon pressing the button on the previous screen (left fan test) I quickly scroll the wheel and then press the button, it succeeds and moves on to the next step, allowing me to continue.

Remember Last Tool?

I tried to raise this question on the base marlin branch but I am unsure what could be the issues here. Since prusa mk2 are going to have multi-material upgrade soon, is it possible to have this feature on the prusa firmware?

my previous thread are here MarlinFirmware/Marlin#5797

Linear Advance Integration

I've noticed that the firmware still refers to the old version of the advance algorithm in Marlin, and is not able to be configured through M905 like it is now in stock Marlin fw. Refer to http://marlinfw.org/docs/features/lin_advance.html. A new LIN_ADVANCE feature has been introduced which has been shown to drastically improve print quality in some areas.
It would be great if this could be integrated in the next update

ultralcd.cpp errors - redefinition

Downloaded the Firmware today - need to build one for a geared extruder.
It seems there is a typo or copy/paste error (however you want to call it).

Line 111 equals to line 116, 112 equals to 117, 114 equals to 118.

I'm not a programmer, but at least i managed to solve this problem by commenting out the doubled lines (116 to 118).
;-)

Unable to set PID settings using M301

Using 3.0.9 GA on current gen MK2

M301 submission to update P receives gibberish in response followed by echo back that the new value was received, but M504 shows values unchanged. Using M500;M501 shows same unchanged values:

Send: M301 P35
Recv: )}f7��}_]
z^{Z]v=^s��G�$^kxr����x�_{/lk-9W;V�6f�{_fn�q_!5?wO;e,NetO>7wj8>u|Z�/^��~i>�Nz
~}�w��+{�N7|{�?z]Uku_;G{��rT2s*?~n�?zI])v�/-k(�tl(r]g\ytJh.mw?{
U�:i7/�O�HlmwE9mG�~`�b�w�g�$/�:)7=g�cI�uk}�?X{4_MV8�M�[�li(GtWL}s�N_<\;s_g�i_�Zw�^#�W|u|D�9�p17q}�n9BQvV�_wVgc~v�g+-Yv]{-�w��eq{9vl�7k}��w9?#}}>/}�z~�u<?�qyf�_m��*UO4o{}�%o`�o<T0}��?�wY��;=%~j^�g3e|O�Bz�.(]?p=;Wex?Vit�m~q-t�};w�:6p�pf}��1�c�6xoK}L}DUln}p?>Ta\8Q���SwfUw
Recv: ;�_r�8{��h-w� )3}5Wo[�gg�~_y_cOg3_e�6d~l8�1�W5�|�~qy=u7?^w/m�W'{/�Ri�YaO^iVOVb/]�5Q�_�z�i^�p[?��5�3M�..?9�xg:K4/W/#nYwZ'w�^1Y�'u}?~�>~}hylo}-7{9Q�y�)f{Ts?�>�7e.Uquv�0yO9r##8�7D�c?�;�rx}�no�'[�{'i.FzkW=]~_GzGy}N�__ue/y_[mvfv`�/�o={o_h|i}..f�o_wl�l�/r}V�K7X=/Og&/+�j�M_&p}.g/u�:u�a)��u7s�};9[[{}xnpKy6Zo\~3y.Xk{f?&{=lkO$j_j/>=7?2�W^�{+�s*^_Z}Vs/SM�}7!y[_@[o������ ���� p:35.00 i:4.88 d:86.08 c:1.00
Recv: ok

Please update the build instructions

The build instructions need to be more precise.
For example:

1. you need a specific Arduino IDE version (1.6.8) or to do some changes
2. the stk500boot_v2_mega2560.hex file is missing
3. the generate_version_header_for_marlin file is missing
4. a bit of explanation on why you are doing each step usually helps

Firmware version 3.0.0 unloads filament on Stop

When the user chooses to Stop the print in Firmware 3.0.0 on a Prusa i3 Plus, part of the stop process ejects the filament like an unload, This is because the G1 command designed to move the X and Y axes also sets the Extruder to zero. This causes the extruder to wind backwards for all the filament that has been printed so far when the gcode is using absolute extruder positioning as it does in Cura generated gcode.

The issue is on line 504 of ultralcd.cpp: https://github.com/prusa3d/Prusa-Firmware/blob/dev/Firmware/ultralcd.cpp#L504

Either the extruder needs to be instructed to operate in relative mode by enqueuing M83 or the E0 needs to be removed from the G1 command.

Potential for filament to get stuck after cancelling print and then telling the printer to load the filament

After cancelling a print and immediately asking the printer to load filament the printer will attempt to load filament whilst the temperature is dropping. This can mean that the hot end temperature can fall below the temperature needed to load filament whilst the printer is loading filament meaning it will cause a jam.

I found this out when I started a print and the realising I hadn't loaded the filament so cancelled the print, this caused a jam that I have now corrected.

Firmware 3.0.8

Parts fan keeps blowing after stop print

It seems like (at least on the i3 MK2) the firmware doesn't turn off the parts fan when stop print is selected from the menu.

Of course it can be manually shut off but since printing has stopped an automatic M107 could be convenient.

M600 results in communication timeout with host

While waiting for a filament change after issuing a M600 command the printer does not answer to the host resulting in a timeout (in my case in OctoPrint).

It should instead answer with busy messages regularly so the host knows that a long running command is running (like original Marlin does).

Is there any planing for making the new firmware compatible with the MKI?

Hi,
I was wondering if Prusa Research was working on making the newer firmware compatible with the MKI, since e115c51 is the latest commit that works with the MKI. If not I would like to do that.

M303 PID Tuning communication lost

3.0.10-RC1: After submitting M303 E0 S200 C8 (Octoprint terminal) I get normal PID tuning procedure response, but in cooling phase LCD status line shows M105 and USB communication drops - after MCU restart everything is back to normal.

Filament change script: Need menu option to manually unload filament if automatic unload fails.

On my first real attempt with Colorprint and a mid-print filament change - I ran into an issue where the extruder slipped when the printer automatically attempted to unload my first color of filament. The menu options available do not cover this scenario -- I could either proceed with the print, attempt to load filament a second time, or to extrude more filament (if the first color had not been purged yet.) A fourth item would be very helpful -- one that gave the option to try to unload the filament again. Since there is no way to access the printer's main menu screens while the filament change script is running, it didn't seem that there was any way to save the print.

Home Before Calibration

One thing I noticed is that there is no auto home sequence added right before either calibration option xyz nor z.

Without auto homing before this, this also increases the risks of having the nozzle crashing onto the bed since the probe aren't always on the probe point unless manually homed first

SD card statistics recording

When a print is done via SD card a log file is generated that says how long a print took and perhaps other information. This would be helpful in keeping overall statistics and keeping track of multi part prints.

M500 and EEPROM functions

M500 function can't be enabled; the max_*_jerk variables don't exist (they have to be renamed) and also some variable declarations about preheat temperature are kept off by some #define.
Anyway, after fixing those bugs, the M500 still doesn't store values into eeprom (e.g., PID tuning values).

Have "Unload filament" reshape plug at end of filament before unloading

When unloading filament, there is sometimes a plug at the end of the filament that prevents the filament from being pulled through the hole at the top of the extruder body. Would it be possible to have the "Unload filament" function briefly push the filament through the hotend to reshape the plug at the end of the filament before unloading the filament? This would also need to be added to the M600 filament change function.

Feature request: Add option to beep when finished print

Add option in settings menu for the printer to beep when a print has finished (like a microwave does). This will help to get the attention of the user if they are not in the room, listening to music etc.

Enabling Auto Bed Leveling breaks the build

I can compile version 2.2.2 successfully with bed auto leveling enabled. The latest version breaks when I enable auto bed leveling with the following error:

Arduino: 1.6.8 (Windows 10), Board: "RAMBo"

C:\Program Files (x86)\Arduino\arduino-builder -dump-prefs -logger=machine -hardware "C:\Program Files (x86)\Arduino\hardware" -hardware "C:\Users\sever_000\AppData\Local\Arduino15\packages" -tools "C:\Program Files (x86)\Arduino\tools-builder" -tools "C:\Program Files (x86)\Arduino\hardware\tools\avr" -tools "C:\Users\sever_000\AppData\Local\Arduino15\packages" -built-in-libraries "C:\Program Files (x86)\Arduino\libraries" -libraries "C:\Users\sever_000\Documents\Arduino\libraries" -fqbn=rambo:avr:rambo -ide-version=10608 -build-path "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp" -warnings=none -prefs=build.warn_data_percentage=75 -verbose "C:\Users\sever_000\Downloads\Prusa-Firmware-master\Firmware\Firmware.ino"
C:\Program Files (x86)\Arduino\arduino-builder -compile -logger=machine -hardware "C:\Program Files (x86)\Arduino\hardware" -hardware "C:\Users\sever_000\AppData\Local\Arduino15\packages" -tools "C:\Program Files (x86)\Arduino\tools-builder" -tools "C:\Program Files (x86)\Arduino\hardware\tools\avr" -tools "C:\Users\sever_000\AppData\Local\Arduino15\packages" -built-in-libraries "C:\Program Files (x86)\Arduino\libraries" -libraries "C:\Users\sever_000\Documents\Arduino\libraries" -fqbn=rambo:avr:rambo -ide-version=10608 -build-path "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp" -warnings=none -prefs=build.warn_data_percentage=75 -verbose "C:\Users\sever_000\Downloads\Prusa-Firmware-master\Firmware\Firmware.ino"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Firmware.ino.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\BlinkM.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\ConfigurationStore.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Firmware.ino.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\LiquidCrystal.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\MarlinSerial.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Marlin_main.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Sd2Card.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\SdBaseFile.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\SdFatUtil.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\SdFile.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\SdVolume.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Servo.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\cardreader.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\digipot_mcp4451.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\language_all.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\motion_control.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\planner.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\qr_solve.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\stepper.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\temperature.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\ultralcd.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\vector_3.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\watchdog.cpp" -o "nul"
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Firmware.ino.cpp" -o "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\preproc\ctags_target_for_gcc_minus_e.cpp"
"C:\Program Files (x86)\Arduino\tools-builder\ctags\5.8-arduino10/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\preproc\ctags_target_for_gcc_minus_e.cpp"
Using previously compiled file: C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\BlinkM.cpp.o
Using previously compiled file: C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\ConfigurationStore.cpp.o
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Firmware.ino.cpp" -o "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Firmware.ino.cpp.o"
Using previously compiled file: C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\LiquidCrystal.cpp.o
Using previously compiled file: C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\MarlinSerial.cpp.o
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10608 -DARDUINO_AVR_RAMBO -DARDUINO_ARCH_AVR   "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Users\sever_000\AppData\Local\Arduino15\packages\rambo\hardware\avr\1.0.0\variants\rambo" "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Marlin_main.cpp" -o "C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Marlin_main.cpp.o"
In file included from C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Marlin.h:16:0,

                 from C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Marlin_main.cpp:38:

C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Marlin_main.cpp: In function 'void process_commands()':

Marlin.h:67: error: initializer fails to determine size of '__c'

 #define SERIAL_PROTOCOLPGM(x) (serialprintPGM(PSTR(x)))

                                               ^

C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Marlin_main.cpp:2101:13: note: in expansion of macro 'SERIAL_PROTOCOLPGM'

             SERIAL_PROTOCOLPGM(MSG_BED);

             ^

Marlin.h:67: error: array must be initialized with a brace-enclosed initializer

 #define SERIAL_PROTOCOLPGM(x) (serialprintPGM(PSTR(x)))

                                               ^

C:\Users\SEVER_~1\AppData\Local\Temp\buildb09b91c15fcaebe254ec6eb9e6435f6b.tmp\sketch\Marlin_main.cpp:2101:13: note: in expansion of macro 'SERIAL_PROTOCOLPGM'

             SERIAL_PROTOCOLPGM(MSG_BED);

             ^

exit status 1
initializer fails to determine size of '__c'

Any assistance would be greatly appreciated

Using M600 with optional arguments results in too fast extruding

The M600 command has optional parameters (X, Y, Z, E, and L).
While X, Y and Z work as expected, using E and L can result in too fast (unsafe) extrusions.

Reproduction:

• M600 E0 L0 results in a filament change operation without any retraction (this can be handy if you do not actually want to change the filament but stop to insert something into the print and then continue)
• Pressing the knob as told by the display results in very fast (hardcoded) filament feed to load the new filament
• As the filament was not unloaded before and is still in the nozzle it is extruded at high speed as implemented here

Expected behaviour:
The code to handle M600 should check if the filament was unloaded and only load it if it was really unloaded first.

The original Marlin firmware has a check and only loads if it unloaded first as implemented here.

This needs to be fixed for both, E and L parameter.

M304 does not survive reboot

M304 is not saving with the m500 this is still a bug. m301 does save however

terminal output from octoprint
`
[...]
Send: M301
Recv: ok p:18.11 i:1.38 d:59.35 c:1.00
Recv: ok
[...]
Send: M304
Recv: ok p:126.13 i:4.30 d:924.76
Recv: ok
m301 is the current tuning for the hotend
m304 is the firmware values

prior to reboot
Send: M304 P59.44 I2.43 D362.74
Recv: ok p:59.44 i:2.43 d:362.74
Recv: ok
[...]
Send: M500
Recv: echo:Settings Stored
Recv: ok
[...]

after reboot

Send: M301
Recv: ok p:18.11 i:1.38 d:59.35 c:1.00
Recv: ok
[...]
Send: M304
Recv: ok p:126.13 i:4.30 d:924.76
Recv: ok`

Move axis during leveling

Hi, I am wondering whether or not it is intended to allow the move z axis during leveling (non-printing execution through lcd panel).

I noticed it this morning when I kind of fiddling with the lcd panel, decided to do mesh bed leveling followed by move z axis to 100mm. What I did is to initiate leveling procedure and during the process I raise the z axis. To my surprise was, the z axis corresponds to the move axis command issued during the procedure.

I would like to address this behavior whether it is a bug or not. If it is a bug, I would like to suggest that the leveling procedure will be completed first before executing the other command

X_MAX Y_MAX Z_MAX pins.

In pins.h the following pins are defined:

  #define X_MAX_PIN 24
  #define Y_MAX_PIN 23
  #define Z_MAX_PIN 30

This contradicts the pinout: http://reprap.org/mediawiki/images/e/ef/MiniRambo1.3a-schematic-pg2.svg

It should be:

  #define X_MAX_PIN 30
  #define Y_MAX_PIN 24
  #define Z_MAX_PIN 23

When pausing a print and cooling down the hotend the cooling fan does not restart when restarting the print

When pausing a print and cooling down the hotend the cooling fan does not restart when restarting the print. It is possible to restarting it by going into the tune menu but this mean the fan runs constantly not only when needed.

Firmware 3.0.9

DOGLCD implementation issue

Hi, Sorry for my English.
I am trying to compile the firmware version 3.0.10 for use with the lcd display: http://reprap.org/wiki/RepRapDiscount_Full_Graphic_Smart_Controller ,
but I get compilation errors. In Marlin versions this works correctly,
but in firmware 3.0.10, when setting up in the same way that in Marlin the file dogm_lcd_implementation.h is incomplete.

Configuration firmware 3.0.10 for Prusa i3 MK2

---

//#define ULTRA_LCD //general LCD support, also 16x2
#define DOGLCD // Support for SPI LCD 128x64 (Controller ST7565R graphic Display Family)
#define SDSUPPORT // Enable SD Card Support in Hardware Console

//#define REPRAP_DISCOUNT_SMART_CONTROLLER

#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

---

When using REPRAP DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER option the process defines DOGLED using the file dogm_lcd_implementation.h
#if defined (REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER)
#define DOGLCD
#define U8GLIB_ST7920
#define REPRAP_DISCOUNT_SMART_CONTROLLER
#endif

The following logic is in the ultralcd.cpp file
#ifdef DOGLCD
#include "dogm_lcd_implementation.h"
#else
#include "ultralcd_implementation_hitachi_HD44780.h"
#endif

When using the library dogm_lcd_implementation.h the compilation process fails because several functions are missing, such as:

lcd_implementation_init_noclear
lcd_set_custom_characters
#define lcd_implementation_drawmenu_back_RAM_selected(row, str, data) lcd_implementation_drawmenu_generic_RAM(row, str, LCD_STR_UPLEVEL[0], LCD_STR_UPLEVEL[0])
#define lcd_implementation_drawmenu_back_RAM(row, str, data) lcd_implementation_drawmenu_generic_RAM(row, str, ' ', LCD_STR_UPLEVEL[0])

#define lcd_implementation_drawmenu_setlang_selected(row, pstr, data) lcd_implementation_drawmenu_generic(row, pstr, '>', ' ')
#define lcd_implementation_drawmenu_setlang(row, pstr, data) lcd_implementation_drawmenu_generic(row, pstr, ' ', ' ')

All functions are defined in the library ultralcd_implementation_hitachi_HD44780.h

If I comment the line "#define DOGLCD" the compilation process uses the library ultralcd_implementation_hitachi_HD44780.h,
The process compiles correctly, but nothing appears on the display.

I wanted to know if there are any options that I am missing comment or uncomment.

Thanks and Regards.

Filament leakage during pre print Z calibration

Hi, I think that printer should start heating (if not yet) before print and at certain temperature 180-190 (PLA) retract filament by ca. 4mm to stop leakage and ask user to remove anything that has leaked from nozzle. Because when Z calibration start this leaked filament get all over nozzle and sometimes I have to stop print many times before it actually start the print correctly.

Now I found out that I can retract manually which I do and it works, when printer starts print job retracted filament get back to nozzle during the flow check line.

Thanks for considering this or point me to some other solution, like maybe GCODE I can add to the start gcode section to do just this? Not sure if this is possible.

Bed Correction Resolution?

Hi, I stumbled across this thread http://shop.prusa3d.com/forum/software-f13/i-need-help-printing-abs-please-its-driving-me-mad-t3416.html and I got to agree that the bed correction resolution are somewhat coarse and can't really be used if either bed corners are high or low.

I also would like to suggest to increase the bed correction resolution, by using probe points as index number and reference, adjustable to a max of about +-100microns. The probe point index will be based on the auto bed leveling index point, meaning up to 9 points can be adjusted

Q: How does the XYZ correction work?

Is there something special about the bed that makes this work?

I would love to have this on my mendel90 and would not have any issue paying for the bed and probe

Prusa3d Specific G-code explanation?

Hi, I would like to know what do these g-codes do when issued especially

• G80
• G86
• G87
• G88

From my point of view at G80, it is almost similar to G29, but another addition after all 9 points has been probed is that the print head will go to position 0,0,0. I need confirmation on G80 though because at the start g-code of slic3r, no Z movement were issued.

Wrong "Total filament" statistics

General statistics report 128km filament usage after 24h of use...
Statistics during print are instead working correctly.

"Smoother prints of diagonal lines" not working in 3.0.9

After upgrading to 3.0.9, medium/large surfaces show "waves" on diagonal fillings, after downgrading to 3.0.8 those waves dissapear automatically, seems like 3.0.9 modifications were performed over an older version than 3.0.8.

I attached 2 images that show same surface printing: with 3.0.9 (waves) and with 3.0.8 (perfect)

Optimize some jerk code

I found that some of the jerk code is redundant and can be optimized pretty easily to save some cycles in the planner. The code in this loop can be changed from the existing…

for (uint8_t axis = 0; axis < 4; ++ axis) {
  float jerk = fabs(current_speed[axis]);
  if (jerk > max_jerk[axis]) {
    // The actual jerk is lower, if it has been limited by the XY jerk.
    if (limited) {
      // Spare one division by a following gymnastics:
      // Instead of jerk *= safe_speed / block->nominal_speed,
      // multiply max_jerk[axis] by the divisor.
      jerk *= safe_speed;
      float mjerk = max_jerk[axis] * block->nominal_speed;
      if (jerk > mjerk) {
          safe_speed *= mjerk / jerk;
          limited = true;
      }
    } else {
      safe_speed = max_jerk[axis];
      limited = true;
    }
  }
}

to the equivalent, but more concise:

for (uint8_t axis = 0; axis < 4; ++axis) {
  const float jerk = fabs(current_speed[axis]),
              maxj = max_jerk[axis];
  if (jerk > maxj) {
    if (!limited) {
      safe_speed = maxj;
      limited = true;
    }
    else {
      const float mjerk = maxj * block->nominal_speed;
      if (jerk * safe_speed > mjerk) safe_speed = mjerk / jerk;
    }
  }
}

Re-add positive live Z

I would like to request that positive live Z be re-implemented. I'm currently running a -0.30 offset and wanted to try other build surfaces but that would require I either flash back to previous firmware or play with the pinda probe.

Also, some filaments I run like PETG need less squish and I currently cannot print PETG as I typically have to add anywhere between .50 and .100 more positive offset than my PLA offsets. Not sure why this was changed. I agree that maybe negative offset should be capped so people dont scar their beds, but why lock the positive direction as it only allows you to move the nozzle further away from the bed.

If there are no plans to revert this, can someone tell me what I would need to change in the code so I can put it back the way it was?

Unload filament function, unloads to slow

Since the 3.0.10, the "unload filament" is "slower", so slow that the filament is stringing on unload. I've got a clog in the cold zone for two time now.
Why is this slowed down in this release?

Add option to pause print away from the top layer of the print

When pausing a print the printer does not raise the hot end meaning that the hot end makes a little melted section in the print, this is made worse if the printer is paused for a long time when cooling down the hot end and the heating it back up is needed.

Is it possible to either have an option to pause the print and move the print head away from the print or to have this as the default?

It would also be really nice to have an option to 'pause, move print head and cooldown (only the hotend)' as these are the steps needed to pause a print for a longer time. Keeping the heated bed on will decrease the likelihood of the print warping or coming unstuck from the bed.

Mesh bed leveling and PINDA probe temperature drift

Detailed information about the issue and workaround is here: http://shop.prusa3d.com/forum/improvements-f14/pinda-probe-live-z-calibration-z-offset-and-temper-t2048.html

Short version: the probe has a temperature drift, if it gets hot from the bed, the offset will change. Workaround: Keep the probe away from the hot bed before mesh leveling to avoid heating it up too much.

Marek

Add custom G-code to toggle high-power mode & silent mode

An idea for a very minor enhancement I had this evening: a way to toggle the firmware's silent mode remotely.

Currently, we can switch between high power-mode and silent mode mid-print via the LCD screen, even while printing from USB.

Is there a way this functionality could be replicated via a custom G-code command? (if it isn't already there but I just haven't searched enough)
I.e. sending Mnnn 1 to switch to silent mode & Mnnn 0 to revert to high-power mode. (where nnn is the number for the chosen M-command)

This would make it possible for users to switch between these modes remotely, i.e. via a machine running Pronterface or an Octoprint server, or even as a scheduled task.

Semi-related: The Reprap wiki describes M913 (only used in reprapfirmware) as a means to set stepper motor currents to percentages of their normal values, describing motor noise reduction as a possible application.

Arduino Compatibility

Hi, I had a hard time compiling your FW because I dian't want to change much thing that were supposed to work.
the fpos_t structure is already in the core of arduino. I suggest to change the 5 instances of this fpos_t for filepos_t to avoir any problem with the original arduino files.

Cheers

Add serial speed option

Could you please add serial speed option, in order to choose at least between 115200 and 250000?

3.0.11-RC1 temp calibration preheat doesn't happen?

Perhaps I'm confused about the instructions, but I don't see any evidence of the pinda preheat referred to when a new print is started. I'm reasonably confident that I did the calibration correctly and selected use of the calibration. I couldn't get a good z offset tune selected at all either.

Missing U flag with M303 command

http://marlinfw.org/docs/gcode/M303.html

In vanilla marlin firmware, the M303 command includes an optional U flag that can be set to 1. With this flag activated, instead of just being printed out, the PID values will actually be applied to the current settings. This means they can be saved with a simple M500 and you don't need to re enter M301 P#.## I#.## D#.##.

I had a look around in the code and it doesn't look like it would be too hard to integrate, but then again I wouldn't really know. This would be really helpful to make the PID process even easier, as that M301 is usually the source of confusion for new users

Farm mode

Hi, today I downloaded and compiled the latest version 3.10.8, and got the same issue that the self-test fails. Besides some "farm mode" was turned "additional F -/-" showed up in the display, and after the printeI was asked if print was ok. I could only turn this off by recompiling by setting farm_mode to false in Marlin_main.cpp.

Version check integrated into M115 nuking communication over serial

I just had a user run into this issue: Print job containing a M115 U3.0.10 (injected by the slicer, I guess it's even your own Slic3r version) effectively nukes serial communication. A look at your firmware source reveals this line causing the serial comms to be stalled while user gets shown a message to upgrade the firmware, introduced in 0b372bf. That's really really bad because external hosts do not have any way to abort this or even to know why the printer stopped replying. The printer is effectively dead on the serial interface and the only option is a disconnect (or the user has to be physically present to handle the LCD prompt).

I understand the reasoning behind this behaviour (being able to inform the user that the GCODE cannot be run on the current firmware version), but the current implementation causes a huge headache for host software like OctoPrint.

Could you please look into a solution that isn't as disruptive?

In the specific case of OctoPrint, returning an actual "Error: Upgrade your firmware" or something like that on the serial line (while also displaying a message on the display maybe?) would be way more straightforward, since it would allow me to cancel the (incompatible) print job and shutdown the connection gracefully, instead of just freezing up. Like wise for the use of an action command.

As a general rule of thumb, any kind of blocking LCD-only behaviour triggered through commands received via serial is really bad for interoperability and a nightmare for host software devs.