Dieses mal ein aktueller Artikel, denn vor 3 Stunden wurde die finale Version der Prusa Firmware veröffentlicht, welche nun in 3.10.1 vorliegt. Schaut man sich diese genauer an, kann man gut sehen, dass nicht soviel dran gemacht wurde als beim letzten finalen Release.
Vielmehr hat man ein Auge auf die Speicherkonfigurationen gelegt, aber auch hier wieder Hut ab, dass diese es immer wieder schaffen eine neue Firmware zu veröffentlichen. Die letzte RC Version war im Juli und somit hat es ganz 5 Monate zur neuen Firmware gedauert. Ob die Entwickler da an was anderem noch arbeiten? 😉
Summary
- New debugging functions & crash analysis tools
- A rare memory bug debugged and fixed
- Long-Press action fixed
- Move auto reporting out of the temperature ISR
- Uint8_t used consistently for the block buffer’s index
- Arduino boards definition updated
- Build script updated
- Algorithm for reading SN in EEPROM improved
- Spanish translation fixed
- Firmware version parsing removed
- Bug fixes
This is the final release of firmware 3.10.1, which introduces improved functionality and several bug fixes. These release notes also include information provided in the previous release RC1.
Before we describe all the new features, improvements and changes, we would like to thank the entire Prusa community members for their feedback – especially @gudnimg and @Panayiotis-git who helped us test and debug this firmware release. Your input is very much appreciated!
New debugging functions & crash analysis tools
The „Dump memory“ feature is a very important new debugging support tool. It allows you to store the RAM content into the xFlash memory for further issue/bug analysis, just like we have in the Buddy firmware for the MINI+. This procedure has proven vital for identifying the rare bug of “static memory overwritten”.
MK3, MK3S and MK3S+
This feature is now accessible from the printer’s Display menu Support-> Dump memory, which is the last command within the Support menu.
The dump command is also available during an active print, which allows the user to execute an actual Memory „Snapshot“ during a critical status or misbehavior of the printer. You will find it under LCD Menu -> Support -> Dump memory display menu. Please note that the snapshot takes some time to finish, therefore we advise not to use this feature if you are not experiencing any problems – i.e. the printer will stop for a while to dump the memory.
Also, to allow for simpler usage of this function, we put it at the end of the support menu for now. If it was hidden somewhere deep, a user experiencing an issue may hot reach this option quickly.
When you have connected a serial device like Pronterface or Octoprint, you can use the following commands via the serial link:
- D20 – create memory dump on xFlash (same as LCD Menu -> Support -> Dump memory)
- D21 – download/print the memory dump via the serial link. This is the only way to get the Dump from the printer. Warning: please be aware not to connect the serial link during print as it can restart the printer and break the recent printing job
- D22 – clear the current memory dump in the printer
The crash dump to xFlash is active at any time, it is stored in xFlash and can be downloaded even after the system reboot until a new D22 command is sent to the printer.
MK2.5, MK2.5S and MK2.5S+
The MK2.5 series does not contain the xFlash, so the situation is different. The dump cannot be stored but it can be sent down to a serial link. In order to get the memory dump from the printer, there must be a serial link connection available prior to any dump download. In default, the LCD Menu -> Support -> Dump to serial and crash dump are disabled after printer restart. To get the dump the following process has to be followed and serial commands used:
- Connect the serial link to Printer. As the serial link connection restarts the Printer, it has to be done before any further activity.
- Using the D23 command from the serial link enables the crash dump by setting the crash dump flag and activates the LCD Menu -> Support-> Dump to serial display menu.
- D23 R command disables the crash dump and removes the LCD Menu -> Support-> Dump to serial display menu.
- The command D23 E – sends the Dump down to the serial link immediately and resets the printer.
- Command D20, D21, D22 are ignored.
- The Dump to serial command should be available even during print and should be found again under LCD Menu -> Support-> Dump to serial display menu.
Please note, that in this release the “Dump memory” function is currently not fully working on the MK2.5 series. After the memory Dump is successfully sent down to the serial link the printer is freezing during Booting and you can see the following or similar:
To resolve the situation at the current firmware build, push the HW reset button below the knob and the printer will restart. We are working on a workaround, this feature should be fully functional in the future firmware release. Should you find any other issues, please let us know.
A rare memory bug debugged and fixed
We have noticed several issues with unpredictable and non-replicable behavior like preheat menu loop when the printer was powered on with already loaded filament. Unpredictability and non-replicability made the root cause identification very hard. Recently we believe we found the major root cause. Its explanation is rather technical, but there’s really no other way to describe it.
The bug was not directly in our firmware, but we believe we ran into a bug in the link-time code generation stage of GCC 4.9.2 (bundled with PF-build-env-1.0.6.*) with optimization for size. The generated code could then partially overwrite the stack, which obviously resulted in random behavior. A workaround was found to avoid this bug by not allowing some functions to get inlined, even when they were used at one spot only.
We believe this is the main reason behind issues #3147, #3151, #3175 and probably others. We have verified that the code generation issue was also present in 3.9.3 already and probably in older FW versions as well. We have been able to track the problem down to FW 3.8.0, it may have been there even longer.
For more detailed technical description see please: #3202
However, since we haven’t been able to reproduce ANY of those issues mentioned above in-house during our tests, we kindly ask the community for help. To help with tracing those malfunctions, you can use the debugging tool described at the very beginning of these release notes.
Please, report any of those potential issues you discover on GitHub and attach the Crash Dump file.
Long-Press action fixed
In the previous releases, the LCD knob „Long press“ action was monitored and executed within the temperature control loop Interrupt Service Routine (ISR). This operation could under some circumstances destroy the menu buffer and create the menu itself inconsistently.
This change improves the printer reaction when the user is applying the „Long press“ action (move Z etc. ). The main change is that the jog wheel „Long press“ execution part has been moved to the main program loop. The temperature control loop is now exclusively dedicated to its generic task – temperature control.
Move auto reporting out of the temperature ISR
This change is similar to the Long-Press action described above. The code running in the temperature Interrupt Service Routine (ISR) needs to be fully reentrant, which is hard to keep for other than Temperature control tasks.
For this reason, the auto reporting (response to M155) is moved to the main processing loop. This can make the auto reporting slower or irregular but removes the reentrant restriction, which allows to use “printf_P” to serial port and to keep Temperature ISR only for temperature control.
For more information head to: #3180
Uint8_t used consistently for the block buffer’s index
We have identified and fixed another potential problem in the planner’s block buffer. The index was sometimes computed as an int (2 bytes), sometimes as 1-byte uint8_t. On the AVR working with 2-byte integers, this is generally not an atomic operation, because it takes multiple instructions to perform. Since it has been possible, all indices of the block buffer are now referenced as 1-byte uint8_t.
Arduino boards definition updated
The developers have merged several pull requests from the community. These commits changed the logic for parts of the code that are dependent on the board version, moving that dependent information directly to the boards.txt file. This simplifies the board version-dependent actions to be done by the compiler and makes them more transparent. Other compilation optimization changes have been made as well. This will not change the printer functionality but the built code quality and bug tracking is improved. The board definition was updated to v1.0.4.
For more detailed information, see please links below:
Build script updated
For our community members, who besides printing also enjoy coding, we have updated our build script to version 2.0, which focuses on improving the MK404 project, which is an MK3 printer family simulator. Adding this project to the PF-build.sh will enable users to compile the Prusa-Firmware and immediately start the simulator with the correct hex file and correct printer.
The credit for this great simulator goes to VintagePC.
Algorithm for reading SN in EEPROM improved
Another significant improvement is a Serial Number (SN) reading algorithm change from the 32u2 communication chip. When reading the SN, the code is expected to start with the standard „CZPX“ prefix used for all Prusa printers worldwide. Unsuccessful attempts are repeated until a valid SN is read.
Spanish translation fixed
A tiny contribution from our community on improving wording in Spanish translation. Specifically for the text string: „Was filament unload successful?“.
Firmware version parsing removed
This FW optimization has saved 936 bytes of Flash memory which is very important in the already critically occupied XFlash memory.
Bug fixes
Temperature display glitch
This bug is related only to 3.10.1-RC, where after a manual filament update the printer might display the hotend temperature at the top row of the screen, even though the user was in a different part of the menu.
We would like to thank user Panayiotis-git for reporting this issue and providing a suggestion for a fix. More information can be found in the following pull requests PR#3214 and PR#3303.
Build error if TMC service code is enabled fixed
In case you are building your own firmware from the code with parameter TMC2130_SERVICE_CODES_M910_M918, then the build process resulted in an error. This bug was introduced recently to 3.10.1-RC.
We would like to thank user gudnimg for reporting this issue and providing a suggestion for a fix. More information can be found in the following pull requests PR#3285 and PR#3304. This fixes the issue #3284.
Premature file list closure fixed
In certain scenarios, the folder/file list opened and closed immediately after the SD card was inserted, which required the user to reinsert the card again. This was happening due to a timeout and the current fix is making sure lcd_timeoutToStatus.start() is called in the specific case when the SD card is inserted into the printer after it was removed beforehand.
We would like to thank again user gudnimg for reporting this issue and providing a suggestion for a fix. More information can be found in the following pull requests PR#3269 and PR#3305.
Occasional missing error message
In the initial release 3.10.1-RC1 our testing team was able to achieve a specific scenario (either Preheat error or Thermal runaway), when the printer correctly turned off the heating, but the error message was not displayed. The developers have found and fixed this issue.
„Preheating to load“ screen behavior fixed
During the Load filament process, the printer was waiting for the preset temperature and displayed the „Preheating to load“ message. When the user removed the SD card, the previous message was replaced by the message „Card removed“ but the Preheating process still did not finish, so the lasting displayed message was not correct. Now after this and similar action the “Preheating to load“ message is redrawn again which is the correct Process status Message.
Message on boot while inserting SD card fixed
When the user inserted the SD card during the booting process, the „Sorting files“ message was presented twice on the display later followed by the correct „Print from SD menu“ message. The issue has been reported on GitHub issue #3135 and clearly reproduced.
We have fixed the SD card handling while booting scenario, which corrected the double „Sorting files“ message. Now the system works correctly.