I've almost summoned up the courage to dive into the Auto Bed-Leveling pool, but which thread is the one to study and use?
Old Man Emu
Printable View
I've almost summoned up the courage to dive into the Auto Bed-Leveling pool, but which thread is the one to study and use?
Old Man Emu
My suggestion is you grab the Marlin fork that Dacb did. It is here. https://github.com/beckdac/Marlin It is forked from a very current version of Marlin. He has the 'Basic' Enhanced G29 stuff, but it also has other good stuff:Quote:
Originally Posted by old man emu
- fixes for MakerFarm people on the Thermistor types
- Ability to limit bed probing to area being printed.
- support scripts for Slic3r and Cura for previous item.
- Fixes to memory leaks in Marlin's G29
I think you would just take your Configuration.h and see if there are any settings you particularly like, and if so, cross them over. And you will have a good starting platform.
This will also give us a good case study to make sure we have things fully baked because at some point I'm hoping Dacb will push all the changes back into the main Marlin code base. What I'm saying is, if you start fresh with that Marlin fork, we will be able to work through any issues associated with this fork and fix any issues with it. It would be good for everybody if we can accomplish that. It is possible that it just fires up and goes with no hiccups because you have a MakerFarm printer. But I guess that remains to be seen?
Downloaded as advised. Now do I do a straight install of the whole lot? Remember I've got an i3 8"
OME
You need to change a few settings to match your printer.
Such as X Y and Z build size, ESteps, but the rest should be setup for the i3v
You need to also change all the settings pertaining to Auto Bed leveling too of course.
This video series was a great help to me.
https://www.youtube.com/watch?v=awsI9bMndJA
OME- I just installed this and it was pretty easy. The one thing that threw me for a few minutes is you have to uncomment the #define SLED_DOCKING_OFFSET (remove the //) otherwise it will go through the G28 and never start the G29 in your start gcode. I would like to see this uncommented by default, but I'm sure there must be a reason for it.
The whole SLED_DOCKING stuff is screwed up. There are missing #ifdef's and #endif's. Who even cares about SLED_DOCKING? It shouldn't be causing these problems.Quote:
Originally Posted by Drone
I couldn't agree more with your Roxy. I really think if this code is going to continue to be in the build it should at least have the SLED_DOCKING_OFFSET define uncommented or it will continue to be a stumbling point for most. If it is uncommented it will just be a line of mostly unused code that will not cause an issue for anyone, even the people that have a sled would need this uncommented anyway right? I really don't know enough to say one way or another and maybe there is a good reason for this to be there and be commented, but I think for most having it commented is a PITA. Oh...and maybe change the default value to 0 instead of 5.
Yes, I was going to go through the coding to make sure that the build size and Steps values were the same as the original coding for the MakerFarm i3 8"Quote:
Originally Posted by jtice
Am I going to strike problems due to differences between the original i3 and the improved 13v?
OME
I wouldn't think there would be much difference, but not really sure. But I don't see a downside to working on it and setting it up either. You can revert to the original code in a matter of minutes if there are issues you need time to resolve, and no need to remove the servo or mount. I had a number of issues with the earlier code having to add it to the latest build, but this new version is very easy. I took a couple week break and went back to the stock MakerFarm firmware and then gave it another try with DACB's build with Roxy's code folded in. Very easy with the new fork and all the issues I had before are pretty much ironed out. I know nothing about programming or code, so if I didn't have problems it truly must be easy. So you don't have to use it, but it will really be worth it when you get it working.
I'm sure that by using this coding my printer will behave much better. One thing I really must address is the calibration of all axes and the extruder feed. I've never done it as the printer worked well from the start. Now that I'm messing around with the coding, it is worth doing all the calibrations.
I'll have to wait until the weekend to do this as I have an exam on Saturday afternoon and then I've got to put some time into a vehicle restoration I'm involved in.
So much to do ... so little time!
OME
I would suggest finding a good file comparison program. On Ubuntu Linux, I use Meld. I can load up my current configuration.h, and a new version from freshly-downloaded firmware, and see them side-by-side with the differences highlighted. Then it's just a matter of moving my settings from one to the other. It makes upgrading very fast and easy, especially since I have several mods of my own that need to be moved as well.
Agreed! I use ExamDiff-Pro on Windows. Without that type of tool, it makes it very hard to figure out where your code deviates from another piece of code.Quote:
Originally Posted by AbuMaia
I use Winmerge, but honestly I found a diff program very confusing when examining the original Makerfarm build and any more current build. Because the order of many of the modules was different in the code it made it quite confusing and even the comments were significantly different making the amount of changes between the code very large... even though most of the changes were meaningless to running the code. Add all the new code for ABL and it made it very confusing to a non-programmer like me. Once I got Roxy's code sorted from the original code manually a diff program was extremely useful in switching to the DACB fork. I'm sure this is just because of my lack of programming knowledge, but that was my experience.
Thanks! Downloaded it.Quote:
Originally Posted by Roxy
OME
I'm rooting for you OME! I'm looking forward to seeing if you get it working as I may also take the plunge into auto leveling.
I recently switched from a 0.4mm nozzle to a 0.3mm nozzle and have had a harder time getting a good first layer stick. That 0.1 mm less coming out of the nozzle really takes away any room for error in your bed leveling. But it makes for fantastic top layer finishes on parts that actually stick! ;)
I think you might have worded this wrong but I'm not sure. My experience is the Auto Bed Leveling corrects the errors in your bed leveling (and position) and the first layer almost always goes down perfect once you have it dialed in correctly.Quote:
Originally Posted by gmay3
Roxy, totally agree with you. I know Auto Bed Leveling will help. I don't have auto leveling implemented on my printer yet but I am thinking about it.Quote:
Originally Posted by Roxy
We have a language problem here. In Australia, "rooting" has as one of its meanings "male/female horizontal gymnastics" if you get my drift.Quote:
Originally Posted by gmay3
A man who has a lot of one-night stands is called a wombat, because he eats, roots and leaves.
A wombat is a ground dwelling marsupial herbivore that eats things like the roots of plants and the leaves of trees. http://en.wikipedia.org/wiki/Wombat
Here is a picture of two wombats.
Attachment 3153
OME
Hahaha thanks for the many laughs with this one OME. That's exactly what I meant! :cool:Quote:
Originally Posted by old man emu
No but seriously, I meant that I am cheering you on and hoping that you succeed with auto bed leveling. I'm thinking about going for it but it seems pretty complicated.
So far... I don't think we have had anybody start the process and not get it going. And in fact, if you are using the same printer, it would seem you just print out the parts the previous person did, and wire them up the same and you should be there????Quote:
Originally Posted by gmay3
OME: It really should be pretty tame if you get the Dacb fork loaded into your printer!!!
With reference to Post #94 in: http://3dprintboard.com/showthread.p...s-enhancements
what is the current version (fork?) that we should be using?
I'm not having trouble updating my firmware, it's just that I have an exam on Saturday, a vehicle restoration, doctors' appointments, gardens to maintain, housework to do, transporting of kids, and a 2-year-old grandson to entertain. Sometimes I have to make an appointment to pee!
OME
What I've been doing with regard to the main Marlin branch is go to the owner's page on GitHub. So, in my case I would go to https://github.com/ErikZalm and drill down on Marlin to get the latest version.Quote:
Originally Posted by old man emu
You can do the same by going to: https://github.com/beckdac and drilling down on is Marlin. What ever the 'best' is, it would be committed and available by taking that path. It isn't very formal, but Sly20 has a post processing script to find the bed area used by a piece of GCode and I think Dacb is in the process of getting that committed to being part of his branch right now. I'm hoping Sly20 can get some release notes or instructions prepared so what ever slicer a person is using, his script will painlessly bolt in and work. But that isn't a reason for you to hold off. Probably that will be figured out by the time you get the firmware working right.
The firmware is the easy part. The hard part is finding the right bits to print out to add the leveling probe to your printer, whether you're going for the servo probe, or the sled probe, or something else. Well, maybe it's not that hard, as I haven't yet seen any sled probes for the i3v. I use clough42's servo mount http://www.thingiverse.com/thing:335632 and kizinfo's switch mount http://www.thingiverse.com/thing:201406.