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

Likely yes, it could serve the same purpose, there is always more than one way to skin a cat.

 

I have been testing this all day and would like others who are daring enough to try it out:

Here is my test Robo configuration. It is an R1 labeled R1 14 03, upgraded to a E3Dv6 hotend with a stud thermistor. The stud thermistor uses the same table as the one supplied by Robo and the Hexagon hotend. A Full Graphics LCD Smart Controller clone from China which requires inverting two pins (modification is done and documented). EEPROM saving is enabled as well as Babysteps. A small modified version of @Ziggy Babysteps display code for the LCD in merged into these files.

All modified lines contain comments and include the following text at the beginning of the comment //--ROBO-BH. You are responsible for any additional modifications needed for your particular Robo configuration.

In the past week there has been a lot done to simplify the menus as well as changes to how the Z Plane is mapped. Please try it out and report here what you find.

 

"Daring enough to try it" is right. This latest Marlin development effort has been going full on for about 6 months now. There have been so many changes and reversals in thinking and direction over the 6 months I am not clear at all what the new Marlin will have as "improvements".

 

It has been a confusing conversation to listen to (mostly following along with bug updates).

 

@Ziggy yep a lot of back and forth, but it seems like they are trying to make a concerted effort to fix the stuff broken especially in the Auto Bed Levelling sections of the code. There is a lot of additions for Delta printers.

This started as a project to just see how far Marlin has come and whether or not I could make work on the Robo. Believe it or not, I am not having any issues printing with 1.0.3.

@mark tomlinson, I gave up on trying to figure out what they are bug fixing and why they chose the ones

 

ALERT!

Somehow there is an error in the way auto-bed-leveling is handled with offsets from the zprobe. Or at least there is for the ROBO. I have added my test findings to the issue opened on the development GITHUB. in the meantime there is a work-around that I found that appears to work very well. It is completely backwards from the way it is documented and requires you to find your own offset, since it appears to not be settable in firmware. In the current firmware it appears that Z_PROBE_OFFSET_FROM_EXTRUDER is completely ignored, so you can set it to whatever number your heart desires. In the attached Configuration.h I have set it to -0.2. Here is how you would find the correct value for M851.

1. Install this version of the firmware.
2. From a terminal window as found in Pronterface or Repetier-Host or your favorite slicer/printer host program, issue the following commands:
   
   Code:

   G28
   M119

3. Note the results of the M119 command, it will likely say that z_min is TRIGGERED
4. Issue the following two command as many times as needed until you report z_min as open, Each time you issue the G1 increment Z by 0.1, the end result will be the number you will need for the next step. As a result of bed flex, the number you derived in this step needs to be incremented, this additional value needs to be determined by trial and error.
   
   Code:

   G1 Z0.01
   M119
   G1 Z0.02
   M119
   G1 Z0.03
   M119
   . . .
   

5. Lets say when you got to G1 Z0.09, M119 finally reported open on all endstops, note that number
6. Issue a M851 command as follows M851 Z1.09. Please note that this is now a positive number because it is broken! If you enter a negative number it will simply dig further into the bed. Also note that there was an additional 1.0 mm added to this example to account for bed flex.Your amount of correction may vary and must be determined by trial and error. It will not vary after it is correctly determined.
7. Issue an M500 command to store this value in EEPROM

Once this is done, you can repeat this as often as your like and it will always be the same number, so one time is enough. Z:0 will always be just at the very top edge of the bed with the z axis probe open. Now use your extruder settings to adjust just how much filament you need to extrude for proper adhesion to the bed.

 

I am trying to stay positive on this latest Marlin development effort. Especially since the contributors are doing it all for the love of it. There has been much confusion about the levelling, probe offset handling etc etc. Hopefully it will all end well.

 

I hope I didn't offend anyone on the development forum with my last post. I have been involved in the OS community as a documentation writer in the past, so I understand this is a labor of love. But I don't see a clear direction currently. If you were to ask, just here on this board, how to adjust for bed adhesion, you will get at least 10 different answers, from the 10 or so people that are the most helpful here. As I mentioned on the GITHUB site, I look at a 3D printer and I see a mechanical device with enough precision and accuracy to make it a useful tool rather than a toy. I don't see any difference between a panel full of switches and knobs or a configuration file full of #defines. I see all that as a way to make my precise machine, a more accurate one too. I look at all these offsets and memory locations as a means to achieve accuracy. If I need something precisely a specific size, I can't be adjusting and futzing with configuration parameters whenever I change filaments. If I need my first Z move to be .2 mm, I expect it to be .2 mm not .18 mm because I need my filament to stick better. I do understand that is how we have all been taught to use things like M565 and M851. In my opinion, accuracy rules over precision, and I think that adhesion should be a function of extrusion rather than a function of layer height adjusted each time by an offset.

Now one issue I see with Marlin, is that there is not one overarching document or set of design specifications, that is why we end up with code that works one way the first time, then several people patch and now works another without any explanation as to why it behaves the way it does or why it changed. Without design specs, we end up with the hodgepodge of code that sometimes even conflicts with itself, because no one has a clear and cohesive understanding of what it is supposed to do.

Yes this is the nature of Open Source. Since it is a volunteer driven community people tend to work on what interests them or what is easy to program. Only a masochist likes to go back and fix bugs, or document their code. The only thing I can provide here is a way to work with the existing code to meet my expectations, express my opinions and publish my results. I hope that all the effort I put in this to help myself, will also help others, but if not, I am satisfied that I am doing the best I can within the current limitations presented by my hardware/firmware/software choices.

 

Yep. We are seeing the nature of open source development.

I absolutely agree there has to be some design principles which are thought through, written down and adhered to. For example there is still confusion about whether the Z probe offset should be positive or negative. While that kind of confusion exists it is very difficult to write any kind of consistent code.

In the early development phase I tried to explain why the Z probe offset can be positive or negative depending on the printer design. eg the Robo Z nut switches are different to most Z probe designs. Unfortunately no one seemed to understand why this was needed. I kinda gave up. Maybe I should try again.

There are some great examples where open source works well. For example the functionality and reliability of the Ardupilot/copter and Mission Planner in the RC world is brilliant.

 

Just as an FYI, I love the work that is being done by 3DR with the Pixhawk and Michael Obome on Mission Planner. There you have a group dedicated to Open Source with strong design goals and an adherence to quality standards.

I can only help so much as I am an enduser not a programmer, I can skim over C++ code for just a little while before my head starts to hurt. But I will continue to provide feedback and assistance where I can.

There are also a few things being done in 1.0.3 that I thought would be of benefit (at least to myself) that incorporated some of the things that others patched in 1.0.0. That is why I found it interesting and wanted to help move the Robo forward.

 

Just a quick update. During the past week the team developing Marlin has been trying to knock out the little stuff, so no major work has been done on ABL. When there are a few more commits to fix G29 I will update this thread with the new stuff. There is some code cleanup, but again it is on little stuff, nothing major.

 

Unfortunately the auto levelling stuff is still a mess. Some big egos are indulging in point scoring - until that stops little progress will be made.

 

The joys of open 'sauce'

 

Just a quick update, I was given access to some debug code that will spit out a report of what the ABL commands are actually doing. I am going to test it today and see what it outputs. Thankfully I am not the one that has to diagnose the problem or remediate it either, just reporting. Once that is done, I am hoping to have another go at 1.0.3 dev for the Robo, at the very least I am hoping that the zprobe_offset will be working again.

What I can say about 1.0.3 is that once you get past the ABL issues and actually use it to print, it is 100% stable on my Robo, and I like the way they cleaned up the LCD display some.

 

I saw that thread, good luck. Glad you are taking the bull by the horns here

 

My testing is done and I reported my findings. The zprobe_offset is still backwards and I asked them to explain why it changed in the last 10 days, we will see what the answer is. I have been printing with it solid since I started this little project. I have yet to have a firmware related print failure. I have done some stupid things on my own, like forgetting to clean off the nozzle or bumping the printer off a Z endstop switch, among many other stupid things, but the firmware has always worked.