Auto_Bed_Leveling: Enhanced G29 command

[applekeith]

Does anyone else have an issue trying to download? I cannot get either file... seems to be redirected to clear.gif.
Alternatively, is there a build out there with this implemented?

[Roxy]

Does anyone else have an issue trying to download? I cannot get either file... seems to be redirected to clear.gif.
Alternatively, is there a build out there with this implemented?

Probably, the right thing to do is go here and use this code base. All of the good stuff is in it and it is stable and works. (Which is more than we can say right now about what is at GitHub/Marlin) !

https://github.com/beckdac/Marlin

If you have a MakerFarm printer, you just load and go. If you don't have a MakerFarm printer, cross your Configuration.h settings over to its Configuration.h file. You should be up and running in very little time.

[somenzi]

Hi there, I too cant download and only get clear.gif. Someone can help. I want to use Enhanced G29. Thanks

[somenzi]

Hi there, could you please tell where can I download probe_pt.cpp and G29.cpp. Here I only get clear.gif. Thanks
Greetings

[KeithUK]

Probably, the right thing to do is go here and use this code base. All of the good stuff is in it and it is stable and works. (Which is more than we can say right now about what is at GitHub/Marlin) !

https://github.com/beckdac/Marlin

If you have a MakerFarm printer, you just load and go. If you don't have a MakerFarm printer, cross your Configuration.h settings over to its Configuration.h file. You should be up and running in very little time.

Hi Roxy

From reading the posts about your work around the G29 code it would seem you have done a great job.

Unfortunately I am one of those who is unable to download from the links getting only clear.gif. I had a look at the config files in the beckdac/Marlin page in github and they appear to be out of date, they are missing an important new configuration for filament diameter sensors of which I'm about to implement.

Would it be possible for you to either fix the link on this page or update your files in the beckdac folder on github (I'm assuming it's your page)

Thanks for your great work, looking forward to implementing it on my system.

Keith

[Roxy]

Hi Roxy

From reading the posts about your work around the G29 code it would seem you have done a great job.

Unfortunately I am one of those who is unable to download from the links getting only clear.gif. I had a look at the config files in the beckdac/Marlin page in github and they appear to be out of date, they are missing an important new configuration for filament diameter sensors of which I'm about to implement.

I have the problem reported. I don't know how long it will take to get it fixed.

The BeckDac fork is older, but it is solid and it works. My suggestion would be to get that up and running. Once you have that running I think the main branch of Marlin over at GitHub will be fixed and you can pick up the filament diameter sensor code. Doing things in this order would let you get started right away, but the other thing it does is it lets you fight just one set of problems at a time.

Would it be possible for you to either fix the link on this page or update your files in the beckdac folder on github (I'm assuming it's your page)

Thanks for your great work, looking forward to implementing it on my system.

Keith

I have the download problems reported. And soon, this page will lose a lot of its importance. These features have been (mostly) folded into the main branch of Marlin over at GitHub. About the only thing not folded in is the ability to rotate the topographical map to match the orientation of your print bed. But most people have the origin at the left-front so that is a non-issue for those people.

[KeithUK]

Thanks Roxy, your suggestion makes sense and I will go along with that.

I have a question - in the past, going back to the early days of microprocessors in the latter half of the 1970's decade, I have done a lot of programming, mainly in Z80 assembler code and some in 6800, later I turned my hand to PIC's. I haven't until now, done any programming with the Arduino so I need a little info about, this so my question, is it simply a matter of just pasting in your code into the correct place in the files? What I ponder is, does the Arduino software compile before uploading to the motherboard, mine is a mega2560. Is there any machine code or low level programming besides the code that resides in configuration.h and it's partners or is it really as simple as pasting in your code, that's superb if it's correct.

Keith

[Roxy]

Well, if you grab the BeckDac fork and start with that, my code is already spliced in and is alive. You shouldn't have to do anything other than set up the Configuration.h file with your printer specific values. The Arduino program is really just a Windows front end to the GCC compiler configured to produce code for the AVR microprocessor. The Arduino program compiles, and links the Marlin code. Then it runs some program called AVRDude that uploads the firmware to the microprocessor. You do have to configure Arduino so it knows what the target hardware is. In your case, you would go to the Tools / Board menu and say you have a Mega2560. In the Arduino libraries and such... In fact, in a few places in Marlin there is low level assembly programming. But in general, you don't need to worry about any of that. Just change Configuration.h values to match your hardware and you should be good to go.

[KeithUK]

That's cool, thank for the info and help, much appreciated.

I've been promising myself to learn C perhaps now is the time to start, assuming I'm right that it is written in C.

I currently use Repetier firmware, I like it, amongst other things it has a lovely soft double touch when homing, it halves the speed on the second try and makes a really smooth finish, Marlin appears to use the same speed for the second try. I think you said somewhere in this thread that you weren't sure how popular Repetier is, it has quite a following, the forum is busy to.

I can understand the coding and am able to follow what it is doing some of the time, though it does go a bit deep for me a lot of the time.

Now you explained why the the board is selected in the Arduino front end it all makes sense, I would imagine it needs to know the individual board to allow for addresses of devices added to the different boards, USB, A to D etc, the machine code would stay the same wouldn't it? assuming they all use the same processor.

[Roxy]

That's cool, thank for the info and help, much appreciated.

I've been promising myself to learn C perhaps now is the time to start, assuming I'm right that it is written in C.

There is a tiny amount of .cpp code. So all of the C files have .cpp as the extension. For all practical purposes, it is correct to say it is C code.

I currently use Repetier firmware, I like it, amongst other things it has a lovely soft double touch when homing, it halves the speed on the second try and makes a really smooth finish, Marlin appears to use the same speed for the second try. I think you said somewhere in this thread that you weren't sure how popular Repetier is, it has quite a following, the forum is busy to.

Probably, that double bump you are talking about is done directly by Marlin. You can control that speed in the Configuration.h file settings.

I can understand the coding and am able to follow what it is doing some of the time, though it does go a bit deep for me a lot of the time.

Now you explained why the the board is selected in the Arduino front end it all makes sense, I would imagine it needs to know the individual board to allow for addresses of devices added to the different boards, USB, A to D etc, the machine code would stay the same wouldn't it? assuming they all use the same processor.

I could be wrong on this. But my belief is the Marlin code doesn't really care about the board being used. What matters are link time options and the various libraries that get pulled in. If you have the board type set wrong, what ever you build won't produce meaningful results even if you get the firmware to compile cleanly. Most likely, it won't compile cleanly. There is a file called Pins.h that has a million #defines to turn on this and that in the different processors. That is where most of the mapping to the physical world happens. You should pull it up and look at it... But you don't want to change anything there without fully understanding things.