Marlin: Release 1.1.0-RC8

[thinkyhead]

A topic to work on the release notes. There have been over 160 pull requests merged, and several intermediate direct commits. This list gives a good overview of the stuff we've been working on since the last release. A lot of it is cleanup. We continue to refine and improve bed leveling.

Summary of biggest changes since 1.1.0-RC7:

• Major performance improvement for Graphical LCDs
• Simplified probe configuration
• Enable Auto Bed Leveling by type
• Reduce serial communication errors
• Make Bilinear (Mesh) Grid Leveling available for non-delta
• Support for Trinamic TMC2130 SilentStepStick SPI-based drivers
• Add M211 to Enable/Disable Software Endstops
• Add M355 to turn the case light on/off and set brightness
• Improved I2C class with full master/slave support
• Add G38.2 G38.3 command option for CNC style probing
• Add MINIMUM_STEPPER_PULSE option to adjust step pulse duration
• Add R parameter support for G2/G3
• Add M43 optional command (PINS_DEBUGGING)
• Remove SCARA axis scaling
• Improved sanity checking of configuration
• Improved support for PlatformIO and command-line build
• Usable DELTA_CALIBRATION_MENU

New / Updated Features

• #4595, #4606, #4608, #4620, #4625, #4718 : Improved i2c messaging
• #4667 : Add M211 to Enable/Disable Software Endstops
• #4722 : Add MINIMUM_STEPPER_PULSE option
• #4832, #5088, #5094 : Enable M0/M1 with M108 (EMERGENCY_PARSER)
• #4833 : Remove SCARA axis_scaling
• #4840 : Add support for G2/G3 with R parameter
• #4900 : Add G38.2 / G38.3 commands for CNC-style probing
• #4955, #4974, #5118, #5132 : PINS_DEBUGGING and M43: Read pin states
• #5082 : Only trigger MAXTEMP error during heating
• #5133 : Add M355 to turn the case light on/off and set brightness
• #5109 : Save configured hotend offsets to EEPROM
• #5179 : Support for Trinamic TMC2130 SilentStepStick drivers
• #5188 : Add M155 auto-report temperature (AUTO_REPORT_TEMPERATURES)
• #5188 : Add M115 capabilities protocol (EXTENDED_CAPABILITIES_REPORT)
• #5238 : Support for AUTOTEMP options in M104 (not just M109)
• #5184, #5252 : Support endstops interrupts to improve performance
• #5255 : Case Light menu item (MENU_ITEM_CASE_LIGHT)
• #5330 : Support for a 3-pin RGB LED (RGB_LED)

• 5371 : Each E stepper can have different steps/mm, acceleration, max feedrate

  Code Cleanup & Documentation

• 4537, #4602, #4650, #4655, #4665, #4691, #4693, #4721,

  4749, #4779, #4797, #4836, #4895, #4941, #4993, #5053 : Code cleanup and documentation

• 4703 : Add note suggesting RAMBo users use the RAMBo board type or platformio environment

• #4893 : Define status LED pins without condition
• #5289 : Eliminate 'unused function' warnings in ultralcd.cpp

• 5394 : Remove mysterious board ID 99

  Planner & Stepper

• 4868, #4982, #5070, #5214 : Optimization of leveling and planner code

• #4611 : Use acceleration limiting based on BQ Marlin
• #4720 : Patch stepper.cpp to allow omitting steppers
• #4738 : Optimize stepper ISRs, plus cleanup, shorthand
• #4754 : Fix bug in mixing extruder mix factors
• #4852, #4980, #4984, #5056, #4963, #5124 : Fixes for Advance Extrusion
• #4936, #4997 : Adapt Jerk / Speed code based on Prusa MK2
• #5074 : Fix and optimize planner acceleration

• 5115 : Do more pre-calculation in buffer_line before waiting for a free block

  Performance & Stability

• 4554 : Repair SPI-pins, some other pins

• #4564 : MISO is an input
• #4569 : Always disable SLOWDOWN for DELTA/SCARA
• #4572 : Show up to 99:59 in digital time
• #4573 : Throw MINTEMP BED error only if heating
• #4594 : Fix serial output for MBL, M303
• #4605 : Fixup 3DRAG pins based on updated RAMPS pins
• #4610 : Fix stopSDPrint so it works when paused
• #4621 : Init PWM-able AUTO_FAN pins with SET_OUTPUT
• #4688 : Repair MarlinSerial with TX-buffer
• #4748 : Patch duration_t toDigital method
• #4804 : Fix some regressive typos in G29
• #4820 : Fix Pin Definition Files to define USBCON
• #4834 : Standardize code_value_bool for flag parameters
• #4859 : Kinematic and SCARA patches
• #4860, #4883 : Fix BLTOUCH string and SERVO_DELAY
• #4887 : Improve MINIMUM_STEPPER_PULSE
• #4889 : Fix HEATERS_PARALLEL
• #4914 : Clean up PID algorithm for heaters
• #4954 : Fix buzzer when both i2c and beeper pin are set
• #4991, #5036 : Patches for Stepper DAC and MAX31855
• #5033 : Fix freezing and MINTEMP Error with MAX31855 thermocouple
• #5071 : Extend measurement range of MAX31855
• #5087 : Fix Azteeg X3 servo pins
• #5110 : Include Z2 min endstop in M119 output
• #5148 : Fix Z raise in Dual X auto-park mode
• #5175 : Fix various Dual X Carriage and Dual Z issues
• #5144, #5230 : Fix and optimize LIN_ADVANCE
• #5212, #5228 : Fix and optimize MIXING_EXTRUDER
• #5258 : Fix MBL Z feedrate
• #5267 : Fix LCD edit items to support over 999 steps/mm

• 5288, #5303, #5389 : Graphical LCD optimizations to reduce print lag

  Configuration

• 4535 : Move tests for old symbols to the top of sanity check

• #4666 : dropsegments => MIN_SEGMENTS_FOR_MOVE
• #4669 : PREVENT_DANGEROUS_EXTRUDE => PREVENT_COLD_EXTRUSION
• #4673 : MIN_SEGMENTS_FOR_MOVE => MIN_STEPS_PER_SEGMENT
• #4727 : Add heading for movement settings
• #4765 : Sanity check endstop plugs based on homing direction
• #4805 : Additional documentation of Configuration.h
• #4821 : Z Raise/Clearance rather than Height
• #4842 : Drop DISABLE_Z_MIN_PROBE_ENDSTOP, clean up probe config
• #4919 : K8400 has 1xXY and 2xZ endstop plugs
• #5072 : Pre-define auto fan pins. EXTRUDER_n_AUTO_FAN_PIN => En_AUTO_FAN_PIN
• #5141 : Remove obsolete OLD_SLOWDOWN option

• 5371 : Allow E steppers to have different factors (DISTINCT_E_FACTORS)

  Homing and Bed Leveling

• 4551 : Make Allen Key Probe stow

• #4562 : Fix Z_DUAL_ENDSTOPS with Z MIN Homing
• #4563 : Explain that Z_PROBE_*_HEIGHT options are nozzle-relative
• #4651 : Improvements to homing / leveling
• #4660 : Fix zigzag moves with MBL
• #4709 : Log whether homing with probe or endstop
• #4710 : Bed leveling that accounts for home XYZ
• #4719 : Marlin patches for homing, esp. Delta
• #4781 : Use simplified Z correction in G29 when possible
• #4789 : Big cleanup of leveling code
• #4835 : Allow non-square Auto Bed Leveling grid
• #4837 : Handle nonlinear bed-leveling in Planner
• #4839, #4856 : Better BLTOUCH support
• #4851 : Patch G29 for 3-point leveling
• #4875 : Use probe clearance for bump when homing Z with probe
• #4888 : Suppress warnings, fix nonlinear_z_offset
• #4899 : ABL: Enable by type. Bilinear grid leveling for all.
• #4918 : Add PROBE_Y_FIRST option. Arduino 1.6.8 required.
• #4927 : Don't check Z_MAX endstops on raise when the probe pwns the pin
• #4958 : Improve M48 output; Add min, max, range, etc.
• #5097 : Fix Y endstop bit set by Z2 or probe
• #5224 : Apply limits in G30, report correct XY
• #5264 : Make Delta Safe Zone homing optional (DELTA_HOME_TO_SAFE_ZONE)
• #5299 : Extend M420 with Z to limit compensation to a given height

• 5388 : Bilinear subdivision via Catmull-Rom (ABL_BILINEAR_SUBDIVISION)

  Mesh (Manual) Bed Leveling

• 4555 : Remove premature int-cast from MBL cell index methods

• #5008 : Save some PROGMEM in MBL G28

• 5057 : Fix manual leveling coordinates

  LCD Controllers

• 4553 : Save bytes for custom chars (Hitachi LCD)

• #4570, #4571, #4584 : Make DELTA_CALIBRATION_MENU universal
• #4574 : Include days in Graphical LCD print timer
• #4597 : Added hyphenated strings for full graphic display
• #4747 : Option to show SD percent on Graphical LCD
• #4803 : Clear LCD button state, apply timer to all
• #4967 : Revised DAC Drive Strength Menu
• #5059 : Set defer delay back to false when exiting babystepping
• #5089 : Better handling of encoder clicks
• #5176 : Instant feedback for (M600) Filament Change
• #5209 : Megatronics has no SD Detect
• #5298 : Fix Turkish and Greek font descents
• #5303 : Draw no more than 4 stripes on graphical LCD
• #5304 : Draw a hollow frame to optimize graphical LCD (`MENU_HOLLOW_FRAME
• #5313 : Refine preheat options for multiple nozzles
• #5378 : Right-align or center elapsed print time

• 5385 : Show decimals for small XY values (LCD_DECIMAL_SMALL_XY)

  Languages

• 4603 : Strip never-translated strings from language files

• #4634 : Set language display charset in language.h
• #4530, #4542, #4578, #4806, #4822, #5043 : Updated German language (Thanks AnHardt, Kaibob2, and blubbfish!)
• #4624 : Updated Spanish language (Thanks RicardoGA!)
• #4642 : Updated Russian language (Thanks mkile, lcfm1!)
• #4649, #4723 : Updated Danish language (Thanks boelle!)
• #4685, #5066 : Updated French language (Thanks gege2b!)
• #4815, #5347 : Updated Italian language (Thanks tnw513!)
• #4885, #4943, #4981, #5233, #5292 : Updated Japanese language (Thanks esenapaj!)
• #5065, #5351 : Updated Czech language (Thanks petrzjunior!)
• #5167, #5284 : Turkish language support (Thanks Rigid3D!)
• #5323 : Ukrainian language support (Thanks akaJes!)
• #5364 : Updated Croatian language (Thanks robimarko!)
• #5386 : Update Galician language (Thanks rafacouto!)

• 5387 : Update Polish language (Thanks c64pl and android444!)

  For Developers

• 4196 : Add PlatformIO support

• #4556 : Within Marlin, maintain most feed rates in mm/s
• #4652 : Add Rambo support/env to platformio.ini; properly map extended pins
• #4717 : Debug logging of nozzle type and offsets
• #4725 : Log machine info in G28 and G29
• #4756 : Makefile fix for Arduino 1.6.9 unzipped
• #4857 : Arduino 1.6.10, direct download U8glib in Travis CI
• #4934 : More detailed debugging of G28 delta
• #4972 : Move platformio directories out of source tree
• #5226 : Bump -std in Makefile to C++11
• #5251 : Support for CMake build
• #5358 : Improved missing translations shell script

[jackshi618]

What time published

[thinkyhead]

@jackshi618 Not yet published. Just _"a topic to work on the release notes,"_ as stated. Note the "Discussion: Developers" tag. It will be announced publicly when actually released. Perhaps in a few days weeks. Still investigating some bugs.

[boelle]

@thinkyhead what can we test at this point? and how to do it.... ?

i was thinking of a kind of script of things to put the printer through that tests as much a given setup can do

[Blue-Marlin]

@boelle ? Testing? You are scaring me.
From a useful tester i expect
a minimum ability to decide if a problems root is in Marlin or not,
a minimum ability to look up problems in the available sources,
a minimum idea about how a feature should work,
the ability to search and read,
the ability to stand more or less on its own feet.

Please just try to use your printer. That will keep us busy enough with just answering your not Marlin specific questions.

Writing a test script seems to be completely beyond your abilities.

[adamfilip]

Your response is mean and inappropriate.

[Blue-Marlin]

That entirely depends on the question of how many of his issues you have read and answered.

[adamfilip]

Sure, but everyone comes from different backgrounds with different skills. You assume alot.

[thinkyhead]

@boelle I can almost imagine a GCode file with just about every command in it, and a configuration with every possible option enabled. But truly, it would be daunting to test everything in one go. Plus we have to test many kinds of printers.

In that vein, I was trying to recruit the PDX 3DP Lab —the user group in Portland, Oregon, USA— to help with this very thing. It's a large group with many kinds of printers, from the most standard to some very unusual. But it is like herding cats to get everyone together.

I think our best bet is to put out the release candidate and, as usual, we'll get a big surge in feedback. The next round will be all about fixing any remaining bugs. And, Crom willing, RC9 will be the last RC before the final release.

[christianh17]

Hi!
I would love seeing a new RC. In the last weeks I often thought about moving to a new version, yesterday I found the new M43-option by chance - and would like to have it.

But: In the issues-list there are so many potential or confirmed bugs and I am not sure if it is a good idea to switch to a version with bugs as I do not see any relevant bugs in my setting. On the other hand I want to support the development and part of it is to use the actual version, test it and give feedback.

So: as soon as you developers think the version is stable enough I would install it asap.

Hopefully this post helps in a decision to do the next RC.

Kind regards
Christian

[stigjoergensen]

Hi Christian

If i were you i would download the RCBugFix and use it - it may have bugs, but chances are you will never see them, or if you do, you can report them as well - and then disable the feature that are causing the bug - you are not worse off then with the RC7, on the contrary, it have a lot of benefits.. and even in worst case you can reinstall RC7.. just backup your folder with RC7 in... or even better download the RCBugFix into a separate folder and go from there, easy peachy...

Trust me, its not that unstable - and i think most here actually run the RCBugFix (if not all - all is just a huge word ;)

rgds
/Stig

[christianh17]

Hi Stig!

I already use RCbugfix from August, 8th and had some issues afterwards. Normally I think "do not change a running system". But I want to support the development and think it would be a sign from the developers if there would be a new RC and perhaps a feature freeze afterwards to get a real release. With this strategy there will perhaps a bigger community to install it and give feedback.

And: Of course I do have a good system for my personal releases so I can switch back very easily to every running version from the past.

Regards
Christian

[thinkyhead]

@christianh17 It's worth giving RCBugFix another try. A good number of things have been fixed since August. The main pitfall is the Z max speed and acceleration, which may need to be lowered for RCBugFix because some acceleration code was fixed. And of course, M43 is brand new and deserves some testing.

[christianh17]

Hi Thinkyhead!
I just did it today in the afternoon. My printer works, M43 helped me already a bit connecting my new full graphics display (I am afraid the connectors are turned around compared to my old fashioned display).

First tests looked good! There is a very (!) small thing with M115 - but I already opened a new issue.

I will test further on and report as soon I have new ideas for improving!

Regards
Christian

[landodragon141]

Scott how close do you think we are to releasing RC8, it seems like the line needs to be drawn somewhere or we'll just keep fixing ;-)

[thinkyhead]

@landodragon141 Dual X Carriage issues with Duplication Mode need to be solved. Please contribute, if you can. I seem to be the only coder around here who looks into bugs. I guess they're not as fun as other things.

[landodragon141]

What's the issue # for that one?

[thinkyhead]

Related issues are #4694, #4695, #5162, #5175

[landodragon141]

Great thanks! I'm not a phenomenal coder but I'm an excellent troubleshooter. I dig into that and see what I can find.

[thinkyhead]

I believe the last few PRs in the queue should cover the most serious issues. If there's no other blockers, I will release 1.1.0-RC8 on Monday or Tuesday.

[Grogyan]

/fingerscrossed that this is the last RC

[thinkyhead]

I think so. We'll leave it out there for a couple of weeks, patch up any serious bugs, and release 1.1.0 just in time for Kringelmas.

[VanessaE]

Don't forget the linear-advance/lost E-steps problem. :smile:

[thinkyhead]

@VanessaE What's the issue number again?

[VanessaE]

We kinda talked around it in #5222, but that issue wasn't explicitly meant to address that glitch. The short version is that LIN_ADVANCE causes loss of E steps on retract, even with K=0. While turning up MINIMUM_STEPPER_PULSE can help, it interferes with serial timing above 4µS (on my bot anyway), causing checksum/line number errors.

[Roxy-3D]

I think so. We'll leave it out there for a couple of weeks, patch up any serious bugs, and release 1.1.0 just in time for Kringelmas.

Actually... I think it would be helpful if we could get confident enough to commit to that. The reason I say that is a lot of people have time off from work over the Christmas and New Year's holiday. It would be nice timing for a lot of people to have the V1.1.0 available so they can spend the time required to bring it up.

[landodragon141]

I see an added advantage of potential bugs being found from a large uptake.

[Sebastianv650]

@VanessaE #5259 should fix your serial comunication issue.
Regarding LIN_ADVANCE, I will try to integrate the estepper ISR into the main stepper ISR. I hope that the higher resolution from the timer it's using will solve some problems.

[boelle]

@adamfilip no worries... i have kind of an internal "pissed off gauge", @jbrazio made that gauge go into the red a LOT..... @Blue-Marlin have gotten it to the yellow area... and then again i have grown up and are just ignoring certain names and avatars completely. ie i don't reed or respond, its like they are not even there.

and should all fail etc etc... bla bla.... Marlin is not the only firmware arround :-D

[boelle]

@thinkyhead yes its a big task with a common list of G-codes and all the various configs

an old thought came to mind... 2 mega boards linked together... one is the "printer" with the config and options we want to test. the other is the "tester" that fires off commands and measures what the other do etc.

or maybe travis could do this?

just thoughts

[jbrazio]

@boelle I'm such a peaceful person.. :-/

Doing unity testing would greatly improve Q&A for Marlin, doing it in the physical world would be possible but hard to automate to a certain degree IMO.

Building upon your suggestion and @daid's firmware simulator could be a good way to go forward into such direction, because we could automate it and feed in test scenarios (we control all the inputs into the simulator) and can validate all the outputs.

[boelle]

hehe

i guess my nordic blood does not mix well with your Portuguese.

but oh well, its nice to see that you are still among us mortals :-D

Q: are travis at all usefull for automated testing? and could our config files be of any use in this regard?

[thinkyhead]

and @daid's firmware simulator

I have gotten it to build in XCode, but I have not gotten it to actually do anything — I am presented with a blank window. I would love to be able to get it working.

i guess my nordic blood does not mix well with your Portuguese.

My Finnish blood is supposed to have me drinking clear liquors and ice fishing.

[jbrazio]

I some how was able to make it run with the included Marlin firmware, I couldn't make it run with the latest marlin version. There are build time dependencies on the Marlin source code, which means we build the simulator at the same time as we build the Marlin firmware.

In order to be useful we would need somehow to modify it to simulate the Arduino bootloader and boot .hex files.

[thinkyhead]

Ah, that's right, too. I couldn't build it with XCode. I had to get and use CodeBlocks… I will have to try it some day soon with the included Marlin source. I probably just dropped in some recent version.

[Roxy-3D]

@thinkyhead Are we close to tagging RC-8 ?

The reason I'm asking is I need to move the UBL code forward to the current code base. I'm hitting a number of bugs that are now fixed in RCBugFix and it is a lot of work to cross those bug fixes back to UBL. So, instead, I was thinking I would spend a couple of days moving forward. But I wanted to do that to something nice like 'RC-8'. (I'm losing characters on the serial line and there are a number of LCD Panel bugs that are currently fixed that are causing problems.)

[thinkyhead]

@Roxy-3D I'm working on debugging the Dual X auto-park issue right now. As soon as I have that resolved I will merge the code into RC and tag 1.1.0-RC8.

[Roxy-3D]

I'm working on debugging the Dual X auto-park issue right now. As soon as I have that resolved I will merge the code into RC and tag 1.1.0-RC8.

Thanks for the info! As soon as I see RC-8 get tagged... I'll start moving the UBL code to it.

[thinkyhead]

Just waiting for confirmation that Dual X is working better.

[thinkyhead]

Ok, It's official! https://github.com/MarlinFirmware/Marlin/releases/tag/1.1.0-RC8

[Roxy-3D]

And can we have a 'Stable Release' on December 24th ? Then I'd have a 'Happy New Year' !

[thinkyhead]

Test, report, and help fix, and it'll be done in no time.

[h4nc]

I'm want to configure RC8 for my Diamond Hotend. It uses three extruders and I'm using Ramps 1.4, so I have to use a Stepper Expander Board.

My problem is that in pins_Ramps.h there are new used pins, like:

define Z_CS_PIN 40

define E0_CS_PIN 42

etc.

Can someone explain what CS does?
I checked the circuit diagrams. For me it looks like all of those pins end up not connected to anything. Most of them end in AUX-2.
So what are those pins doing, when they are not connected?

[Blue-Marlin]

From Configuration_adv.h

/**
 * Enable this for SilentStepStick Trinamic TMC2130 SPI-configurable stepper drivers.
 *
 * To use TMC2130 drivers in SPI mode, you'll also need the TMC2130 Arduino library
 * (https://github.com/makertum/Trinamic_TMC2130).
 *
 * To use TMC2130 stepper drivers in SPI mode connect your SPI2130 pins to
 * the hardware SPI interface on your board and define the required CS pins
 * in your `pins_MYBOARD.h` file. (e.g., RAMPS 1.4 uses AUX3 pins `X_CS_PIN 53`, `Y_CS_PIN 49`, etc.).
 */

Probably you can ignore them.

[h4nc]

Thx, that worked. I commented those out.