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

In previous Marlin development versions the Z Probe Offset was negative for a typical servo based probe. I've pointed out that this did not make sense as when the probe triggered, the extruder tip was ABOVE the bed (ie the Z position is positive). In other words, the Z probe offset (which is really the extruder tip offset) is positive.

In the case of the Robo R1 with the Z nut switches, the Z probe offset will be negative. This is because when the Z nuts trigger the extruder tip is logically (but not physically of course) below the bed.

Anyway this whole issue has been an ongoing source of confusion. So it wouldn't surprise me to see this change many times until some kind of final version comes out.

 

@Ziggy, I have tried to explain this also, but I have not gone to the lengths you have. Regardless the outcome, whether it ends up positive or negative we will adjust. I just wanted to get it working.

@jbigler1986 I shimmed my bed also and I am within 0.02 mm in all four corners, so essentially as level as it will ever be. But the issue is flex and even though the corners may be level there is no telling just how flat the glass is, so we still need auto tramming.

 

One way for OSS developers to fix all their remaining issues is to just ignore them. The Marlin devs just deprecated the current Marlin Development branch and started a brand new GIT. This basically clears the slate of all the issues listed. For us the auto-leveling is working in 1.0.3 dev, but the offset is backwards. I am going to open an issue with this if the old issues do not get transferred to the new GIT. There are a lot of changes since 1.0.0 and some of the math has been corrected in long-standing problem areas, the graphics displays have all been updated (although more needs to be done) so it will be a worthwhile modification for Robo users. I will try to stay on top of this as it moves forward.

 

Second time in about 6 months all outstanding Marlin issues have just been closed.

It seems the theory is "there has been a few months of development so all issues must have been fixed by now"

Still very much a lottery to see what useful mods come out of this.

 

Thought I would catch this tread up a little. I can't find anything that is new that applies to the Robo since July 23, but this is the latest code as of Monday August 10.

Please note M565 is no longer a setting in this version of Marlin, use M851 instead. Because the developers are not a coherent group changes to the zprobe_offset have forced it to be entered as a positive number rather than negative. For example, if your zprobe_offset was set like this M565 Z-1.0 then the new offset will be set this way M851 Z1.0. So far everything else seems to work and I am getting consistent prints. I have enabled the Full Graphics LCD Smart Controller and modified the code to display the actual number of Z Babysteps (per @Ziggy).

Just unzip, modify Configuration.h, compile and upload. If you use the command windows to send commands to your printer, then don't forget to issue a M500 command at the end so the printer will remember your settings.

One more thing, version number has changed to 1.1.0.

 

I have pointed out to the Marlin dev team that using M851 to set the Z Probe offset does not make sense. M565 is defined in the RepRap gcode wiki as the gcode to use to set the Z Probe offset.

Re the Z Probe offset value - This is inconsistent with the way RepRap define the Z probe offset in M565.

http://reprap.org/wiki/gcode

 

@Ziggy - Thanks for continuing to work with the developers. It looks like there are a few that do really want to see this working, even though at times it seems like they are at cross purposes.

Everyone else, I just got notification today that there will be a new debug build. and in about a week more pull requests with some, supposedly beneficial changes to the way auto-leveling works. Of course I will test and post the results here. In the mean time I have done about a half dozen prints with the 10-AUG-2015 code I posted above and it appears to be working.

 

Just got a couple of comments by a Marlin developer regarding M565 and M851, according to the developer M565 was never supposed to work on Marlin. If you look at the reprap wiki page listing g-codes you will see that Smoothieware is the only firmware that supports M565. So how we got it and are using it is a mystery to me. It should be M851, so I guess moving forward it will only be M851. The kicker is that now the offset is positive. Which makes sense from a human readable perspective but not from a machine perspective. We all know the Robo triggers the Z minimum end stop below the surface of the bed, so we have come to expect that the offset is negative, but we want to move the probe (the extruder) up from the bed, so humans would tend to think that it should be offset in a positive direction. To be honest, I am okay with this change, and I really believe that no discussions with the developers will change their mind on this point.

So the takeaway from all this: If you want to use the newest versions of Marlin you will have to throw out all your knowledge of M565. This is good since their is no official support in Marlin for M565. You will need to start using M851, which by the way, is not currently documented in the reprap g-code wiki, and it must be entered in as a positive number. Think about it like we are raising the probe from the end stop so we want to offset upwards.

I am hoping that I will see a debug version in the next few days so I can play with it. I will post a followup a couple of days later, along with any newly available files. As I have mentioned in previous messages, I have been using the development code on my Robo for some time now and I am printing just fine

 

>So how we got it and are using it is a mystery to me<

Open Sauce man

and in all fairness this particular group of developers let people in to 'play (make commits) with no real vetting.

 

Here is the latest snapshot of Marlin Development code configured for the Robo R1. Modifications are all listed with comments.

What's enabled:

• Babystepping
• Full Graphics LCD Smart Controller
• EEPROM saving
• E3D-v6 Thermistor (modify this in Configuration.h if you are still using a Hexagon thermistor)
• Better calibrated E-Steps (You should still do your own calibration of your particular extruder)
• Better calibrated heaters (You should still PID tune your own heaters http://reprap.org/wiki/PID_Tuning)
• Auto Bed Leveling grid centered over build area and movements sped up between points.

Just unzip to a Marlin directory and upgrade your firmware as you normally would.

Note: There is no longer M565 defined in this firmware. Marlin never intended to implement this particular code and it is not in the reprap.wiki as supported. Instead you must use the Marlin supported M851. It is set in a similar way to M565 but the number is positive rather than negative. Example: If your Z offset is currently -0.8 then in this firmware you would use the command M851 Z0.8 to set it correctly. This can be placed in startup gcode or set from the command line. If your setting doesn't change much (and technically is shouldn't) Issuing an M500 command after the M851 will save that setting in EEPROM. The current Marlin issue has been closed and ABL appears to be stable and working on the R1.

FYI: I have been using the development builds since I started this thread, and while it has been a bumpy ride at time, it is working very well now and I am using it to print models daily. I have included two files, the Robo_Development_08182015.zip is the complete firmware with all modifications listed above included. The Robo_Defaults.zip contain just the files changed if you wanted to compare them to the current Marlin development branch.

 

Start of a new month, everything appears to be working on the R1. I am just about ready to pull the trigger on a Pull Request to add sample configuration files for the Robo3D R1 to the development branch. This way when the developers finally release an RC or the actual release code, it will be a simple matter to upgrade the R1 to the newest version of Marlin.

The same proviso exists in this version as in the one mentioned in message #71

Enjoy.

 

Again, same proviso as in message #71.

There as been a lot of work cleaning up the code and now it compiles to about 46% of available memory, previous versions were over 50%.

 

The like is for managing to use the word "proviso" in a sentence.
(correctly)