Marlin Firmware Upgrade 1.1.0 RC8 & RCBugFix (For R1 & R1+PLUS)

@WheresWaldo - I noticed that "PIDTEMPBED" is defined in configuration.h (Line 231) in RC3 - but it hasn't been in the prior versions. I'm wondering if that makes a difference?

I'm getting weird powers issues, like the printer slows down like it's not getting enough power and the LED's even blink as if they are about to shut off. I did all my basic modifications and PID tuning. To test I reverted to your settings and still the same issues. I reverted back to RC2 and it's back to normal.

I plan on going through the Marlins GIT to see all the changes they implemented. See if I can find where my issues are, but defining "PIDTEMPBED" stood out as it was a major difference in the last iteration.

 

Hi so my extruder fan no longer runs, even when I try to run custom G-Code along with putting slic3r at "Always On". Could that be because of this or do you think its a hardware problem instead of firmware?

 

On the firmware I'm running on the bigbox it has a "Bed Leveling" script where the nozzle moves to 9 points on the bed and you define the offset at each one, negating the need to run G29 each and every time.

Is this universal to 1.1.0? I think that would be a good justification for Robo to upgrade

 

Mine has an option in the prepare menu called "Bed Leveling"

I prefer it over the G29 nonsense

 

Yeah, right here: http://wiki.e3d-online.com/wiki/BigBox_Software

 

Hi Robo3D people!

Be sure to keep reporting any issues you're having with RC3 on the main MarlinFirmware/Marlin project. (The MarlinFirmware/MarlinDev branch has diverged somewhat, so any bugs reported to that branch will not apply.)

I've been taking a break from Marlin for a couple months to give the development team space to figure out its new goals, processes, and priorities. Now that we're plunging headlong into 2016 and still don't have a 1.1.0 release, my mission is to shepherd the RC branch through to a final 1.1.0 release that we can all be happy with. This means:

• Fixing all extant bugs in 1.1.0-RC3 reported by users
• Incorporating bug-fixes from the MarlinDev branch, where possible
• (Also porting any RC bug-fixes over to the MarlinDev branch)
• Getting feedback from testers on a variety of machines
• Maintaining the freeze on features and behavior

So, please continue reporting issues on the Github issue queue for MarlinFirmware/Marlin, and I will do my best to address them in a timely manner. If you encounter a bug in MarlinFirmware/Marlin/RC, also check MarlinFirmware/Marlin/RCBugFix to see if the bug has been patched.

(Sorry for the absence of direct links in this post. I have to do 3 postings in this forum before links are allowed.)

 

Sorry for the "drama" around Marlin. I don't want to shake anyone's confidence in the project, which still has a lot of smart and conscientious people working on it. As you know, big changes were made in October that I felt required more consideration, and I was very annoyed that one developer could (or would) make sweeping changes in the middle of a release cycle (though I understand, for example, the inevitable need for a revamp of the project format). As you may know, I had spent almost a year cleaning up the code, revitalizing the project, writing documentation, etc., and I had become quite personally invested in the quality of the project. So, with much of my work being thrown out (e.g., configurations, the configurator, the marlinfirmware wiki), and with carelessness becoming all too common, I just had to step away from the project for a while.

So, I apologize for the extra cruft that ended up in RC3 while I was on vacation! I'm now beginning to work on Marlin again, but I will be limiting myself to finishing the 1.1.0 release. I haven't even tried to compile the new MarlinDev code, because I don't want to diverge from the rest of the community while trying to produce a release — one that I can feel some pride in.

Anyway, there's a small pile of issues in the queue, so I'm off to kill some bugs!

 

I finally figured out what the situation I was trying to understand is. They enabled a mesh leveling grid option for manual leveling, called manual bed leveling in Marlin. They only use the autoleveling on the Pro version because they advertised it in the kickstarter, but they actually prefer the manual method. If you look in the dual firmware you should see what I mean.

I'm definitely considering upgrading for that. Doing a mesh once would save some time on each print.

 

@WheresWaldo , thanks for the work you did on this thread. I'm now running this thread, with the new zoffset and calibration with no issues. And I was able to hook up my little I2C OLED screen without much code change. Nice to know it's on a up-to-date codebase!

 

Mine uses the SSD1306 driver, so for it, I just had to uncomment this define:
// SSD1306 OLED generic display support
// ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: http://code.google.com/p/u8glib/wiki/u8glib
#define U8GLIB_SSD1306

And made sure the full graphic smart controller was commented out:
// ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: http://code.google.com/p/u8glib/wiki/u8glib
//#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

The wire connect was simple, 5V, GND, SDA, and SCL right to the I2C connector on the RAMPS board. SDA is pin 20 and SCL is pin 21.