search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.26k stars 19.23k forks source link

Release 1.1.0-RC8 #5077

Closed thinkyhead closed 7 years ago

thinkyhead commented 8 years ago

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:

jackshi618 commented 8 years ago

What time published

thinkyhead commented 8 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

Your response is mean and inappropriate.

Blue-Marlin commented 7 years ago

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

adamfilip commented 7 years ago

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

thinkyhead commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

What's the issue # for that one?

thinkyhead commented 7 years ago

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

landodragon141 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

/fingerscrossed that this is the last RC

thinkyhead commented 7 years ago

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 commented 7 years ago

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

thinkyhead commented 7 years ago

@VanessaE What's the issue number again?

VanessaE commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

Sebastianv650 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

Just waiting for confirmation that Dual X is working better.

thinkyhead commented 7 years ago

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

Roxy-3D commented 7 years ago

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

thinkyhead commented 7 years ago

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

h4nc commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Thx, that worked. I commented those out.

github-actions[bot] commented 2 years ago

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.