Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Release 1.1.0-RC8 #5077

Closed
thinkyhead opened this issue Oct 24, 2016 · 45 comments
Closed

Release 1.1.0-RC8 #5077

thinkyhead opened this issue Oct 24, 2016 · 45 comments
Labels
T: Development Makefiles, PlatformIO, Python scripts, etc.

Comments

@thinkyhead
Copy link
Member

thinkyhead commented Oct 24, 2016 •
edited
Loading

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

Code Cleanup & Documentation

Planner & Stepper

Performance & Stability

Configuration

Homing and Bed Leveling

Mesh (Manual) Bed Leveling

LCD Controllers

Languages

For Developers
@thinkyhead thinkyhead added the T: Development Makefiles, PlatformIO, Python scripts, etc. label Oct 24, 2016
@thinkyhead thinkyhead mentioned this issue Oct 24, 2016
Closed
@jackshi618
Copy link

What time published

@thinkyhead
Copy link
Member Author

thinkyhead commented Oct 28, 2016 •
edited
Loading

@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.

@thinkyhead thinkyhead mentioned this issue Nov 16, 2016
Closed
@boelle
Copy link
Contributor

boelle commented Nov 20, 2016

@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
Copy link
Contributor

Blue-Marlin commented Nov 20, 2016 •
edited by thinkyhead
Loading

@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
Copy link

Your response is mean and inappropriate.

@Blue-Marlin
Copy link
Contributor

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

@adamfilip
Copy link

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

@thinkyhead
Copy link
Member Author

thinkyhead commented Nov 21, 2016 •
edited
Loading

@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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link
Member Author

@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
Copy link
Contributor

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
Copy link

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
Copy link
Member Author

thinkyhead commented Nov 27, 2016 •
edited
Loading

@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
Copy link

What's the issue # for that one?

@thinkyhead
Copy link
Member Author

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

@landodragon141
Copy link

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
Copy link
Member Author

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
Copy link
Contributor

Grogyan commented Nov 28, 2016 via email

@thinkyhead
Copy link
Member Author

thinkyhead commented Nov 28, 2016 •
edited
Loading

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
Copy link
Contributor

VanessaE commented Nov 28, 2016 •
edited
Loading

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

@thinkyhead
Copy link
Member Author

@VanessaE What's the issue number again?

@VanessaE
Copy link
Contributor

VanessaE commented Nov 28, 2016 •
edited
Loading

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
Copy link
Member

Roxy-3D commented Nov 28, 2016

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
Copy link

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

@Sebastianv650
Copy link
Contributor

@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
Copy link
Contributor

boelle commented Dec 2, 2016 •
edited by thinkyhead
Loading

@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
Copy link
Contributor

boelle commented Dec 2, 2016

@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
Copy link
Contributor

jbrazio commented Dec 2, 2016 •
edited
Loading

@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
Copy link
Contributor

boelle commented Dec 2, 2016 •
edited
Loading

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
Copy link
Member Author

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
Copy link
Contributor

jbrazio commented Dec 3, 2016

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
Copy link
Member Author

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
Copy link
Member

Roxy-3D commented Dec 5, 2016 •
edited
Loading

@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
Copy link
Member Author

@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
Copy link
Member

Roxy-3D commented Dec 5, 2016

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
Copy link
Member Author

Just waiting for confirmation that Dual X is working better.

@thinkyhead
Copy link
Member Author

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

@Roxy-3D
Copy link
Member

Roxy-3D commented Dec 8, 2016

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

@thinkyhead
Copy link
Member Author

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

@h4nc
Copy link

h4nc commented Jan 14, 2017

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
Copy link
Contributor

Blue-Marlin commented Jan 14, 2017 •
edited
Loading

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
Copy link

h4nc commented Jan 16, 2017

Thx, that worked. I commented those out.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 31, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
T: Development Makefiles, PlatformIO, Python scripts, etc.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests