Separate names with a comma.
Discussion in 'Mods and Upgrades' started by WheresWaldo, May 4, 2017.
Can you explain how to change refresh rate?
There are apparently still some LCD related issues in the latest release ... they are always more akin to an anarchy than a a release crew when new versions are rolled out so I would expect a few more things to crop up as well
The line you want to change is in Configuration_adv.h and you need to change line # 557
#define DOGM_SPI_DELAY_US 5
to a number higher than 5, 10 is the default but try something like 7 first. Most good quality LCD screens will work with 5 µs and some Chinese ones need as much as 10 µs, but most will work at 7 or 8 µs. It does allow Marlin to execute commands faster by lowering the number.
#define DOGM_SPI_DELAY_US 5
Release 1.1.2 happened a few hours ago, but I cannot get it to compile with MESH enabled. I opened a ticket on GITHUB. As soon as I see something and we can figure out what is going on then I will post the files at the beginning of this thread. Thread title has already been changed but no 1.1.2 files are currently available.
Mesh compiles fine for me.
The newest files from today? or the ones already in this thread?
Did you know that old school MESH_BED_LEVELING is deprecated and will be going away in Marlin 1.2.0? That is what I was told in a tweet from the Marlin Firmware team.
@danzca6 Yes I know but their suggested alternative doesn't work and UBL is a pile of you know what right now. I am fighting them on this now. Apparently testing is not high on the Marlin devs priority list so they keep breaking stuff that worked in previous iterations.
Well, then we might as well just stick with 1.1.1 since almost all the coding effort right now is focused on UBL with no other code optimizations or new features in the timeline.
I have been told by a few of the Marlin contributors that UBL is workable in the manner that MESH was in the past. I am going to test this with 1.1.2. This is how I use MESH currently. First, the code here changes where the Z axis is homed, for MESH it is homed near the front corner of the bed. The R1(+) bed flexes much less near the corner where the bed is supported so you get more consistent results. My sequence is like this, I use a dial indicator in the middle of the Y axis with the hotend in the middle of the X axis. Alternate the position of the dial indicator from side to side and adjust the lead screws until the measurement is as level as it can be. Then I use the LCD menu under PREPARE to LEVEL the bed. With a feeler gauge and spinning the encoder wheel you can monitor the height of the hotend to get the adjustments precise at all points on the bed, without worrying about the amount of bed flex. If it needs an offset then you can use M851 to offset the bed whichever way needed.
This whole process does not require that you know any G-codes, you don't need any measurement adjustments, it is a one and done process.
I am told that with the new UBL Tools menu you can do essentially the same thing. Everything can be done from the menu and you don't need to know any G-codes, no guesses about close adjustment measurements, easy. If that is the case, I will write up the procedure and post it here. We will basically have auto-leveling that will level the bed as it did with the older Robo provided firmware, which each print. We will have a complete manual leveling using all the features of UBL.
I should be done with my testing a in couple of days. In the meantime my suggestion is to stick with the files posted earlier in this thread.
I am working on this UBL thing and it is not obvious or intuitive in any shape or form. Plus, the idea that even if I am using the LCD that I still need to enter terminal commands (the mesh fails to create is you don't first do M502, M500 & M501 in that order). The whole point of the LCD is to not have to remember G-code commands! The other issue is almost no feedback, if you create a mesh it heats the bed and extruder first. If you are unaware of that you would conclude that UBL is frozen. I am trying it first with an auto-generated mesh, just to see how that works. Then I will test with a manually created mesh to see if there are any differences.
My results for auto-generating the UBL mesh were as I expected, the mesh generates and it is enabled. If I run the validation grid I find that I have about 80 of the 100 points that need adjustments as a direct result of bed flex. I find this unacceptable.
Now there is a menu system for LCD users and I have asked the menu contributor what it would take to create a mesh manually and have it enabled all without typing in a single G-code. We shall see what transpires. It can be done this way in the original MESH leveling, and I am told that UBL is just as easy (fake assessment).
If you want UBL to work, you will probably need to change how the probing works. Consider a BLtouch. If I come crawling back to marlin, I will likely try to create my own lightweight, hair trigger probe. The robo exerts too much force on the bed to take accurate measurements. That's really more appropriate for a fixed bed, where it can be evenly supported and the force distributed evenly.
There is a thread on IR Sensors (one of which was designed by a member) here in the MODS area.
The menu system does not work as expected. It seems that user experience is currently on the back burner as basic functionality and code reduction are the primary focus of the contributors. There was mention of having UBL polished in about a 6 week time-frame. As a result I will not be updating this thread with any new sets of files until the end of July. The file sets uploaded in post #4 and #5 work as expected and should be used in the meantime. MESH leveling is still functional in that version and should be the preferred method of bed leveling if you have not upgrades to a non-contact probe.
I’ve been following the back and forth dialog on GitHub. They just don’t get it. Semi-automating the process may work on most printers, but not the Robo R1 with its brute force probing and flex.
The manual MESH process was quick, easy to understand, and it worked. Simply build a height map by using a paper feeler gauge, turn the knob for resistance, push the knob to go to the next point in the grid. Done.
I don’t have much confidence they’ll do any better in 6 weeks because they think simplicity equates to lack of sophistication. I’m sure all the commands are defined, they just don’t want to organize them into a routine that’s easy to use and doesn’t require being tethered to a computer.
@Ed Ferguson I have spent the better part of the last hour trying to explain that very thing with them. The Marlin issue, which is true of a lot of OSS projects (not all) is that they have no direction or overall specification document that they can measure against. A lot of contributors don't want a Program Manager telling them what is and isn't important. So they go on blissfully ignorant adding features that are only partially flushed out or of value to a very small group (sometimes only 1) of end users. Removing other features without ever accessing the impact to others.
I just added my $0.02 worth to the GitHub discussion in the nicest possible way while gritting my teeth. I don't plan on making any more GitHub contributions unless they ask for tester feedback. The case has been made to keep MESH in one form or another. Not holding my breath. Gotta get the R1+ back to my son and start using my R2. Worst case I keep his R1+ at ver 1.1.1. At least it solved the bed leveling / first layer adhesion issue which kept him from enjoying the printer. The other Marlin improvements that came later are minor in comparison.
Thanks @Ed Ferguson for adding your voice to the discourse.