Auto_Bed_Leveling: Enhanced G29 command

[ctcwhexdx]

That was it, it's compiling now without any errors. Thank You!

[syl20]

Can you show me that script? I'll modify the G29 to make use of it and probe the region that the print will be.

I have merged your code with the one of bonm14 from github, this night. It compiles but I do not have tested. I write as soon as posible the post processing script.

[Roxy]

I have merged your code with the one of bonm14 from github, this night. It compiles but I do not have tested. I write as soon as posible the post processing script.

Please report back when you have either tested the merged code or have the post processing script for others to look at! It would be great to get this all working together!!! It might make sense to start a new thread with the single focused topic of getting the merged code bases in a form to be released and with full automatic support for the bed probing of what ever size is needed for the print.

[ctcwhexdx]

I might of spoke to soon, on one hand the auto-bed leveling is working great!! On the other hand I have run into something that has me stumped. I have a ramps 1.4 setup with the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER, while the display works fine, what does not work is getting it to print from the sdcard, I can use the LCD to select what gcode file I want to print from the sdcard, but when I select what I want to print, it goes back to the main menu and nothing else happens. I have replaced the ramps board, the arduino board, different sdcards, and also tried another lcd controller(same as the other one) and have had no luck.

From pronterface I can run my printer from my laptop, but I would much rather print from the sd card and not have to use the laptop to control the printer. I have doing diffs all day and have yet to find anything

If I go back to an earlier firmware everything works fine, I can print from the sdcard and everything, I just can't use the auto bed level. I went through the issues list for this firmware and didn't find anything.

Anyone have any ideas? Google doesn't turn up anything useful either...

I'd really appreciate any ideas/suggestions

[Roxy]

If I go back to an earlier firmware everything works fine, I can print from the sdcard and everything, I just can't use the auto bed level. I went through the issues list for this firmware and didn't find anything.

Anyone have any ideas? Google doesn't turn up anything useful either...

I'd really appreciate any ideas/suggestions

There are issues with most of the Arduino boards in that the SD-Card control signals are used for multiple purposes. When you go back to the previous version of the firmware that works, I suggest you take that Pins.h file and do a visual diff against the current Pins.h file. I suspect you are going to see different pin definitions for your board. If that is the case, report back with what you found and we can discuss the trade offs of going forward in different directions.

[ctcwhexdx]

There are issues with most of the Arduino boards in that the SD-Card control signals are used for multiple purposes. When you go back to the previous version of the firmware that works, I suggest you take that Pins.h file and do a visual diff against the current Pins.h file. I suspect you are going to see different pin definitions for your board. If that is the case, report back with what you found and we can discuss the trade offs of going forward in different directions.

Thank You for helping me with this, i've gone cross-eyed at this point!! I did do a diff against the old and the new pins.h file, there are 300 more lines in the new pins.h file vs the old one. In going through the changes almost everything has nothing to do with the board type I am using (33, Arduino Mega pin assignment), there is one section that I am wondering about, in the new pins.h file the section reads:
#define SCK_PIN 52
#define MISO_PIN 50
#define MOSI_PIN 51

In the old pins.h file it reads:
#define MAX_SCK_PIN 52
#define MAX_MISO_PIN 50
#define MAX_MOSI_PIN 51

All the other changes are for different controller boards, but maybe i'm missing something.. Please let me know..

[ctcwhexdx]

There are issues with most of the Arduino boards in that the SD-Card control signals are used for multiple purposes. When you go back to the previous version of the firmware that works, I suggest you take that Pins.h file and do a visual diff against the current Pins.h file. I suspect you are going to see different pin definitions for your board. If that is the case, report back with what you found and we can discuss the trade offs of going forward in different directions.

I forgot to add that the pin assignments are the same....

[AbuMaia]

Roxy, I have to thank you for turning me on to diff viewers. It made it so much easier and quicker to migrate my customisations and settings from my old Marlin over to DACB's new fork. Thanks!

[Roxy]

Thank You for helping me with this, i've gone cross-eyed at this point!! I did do a diff against the old and the new pins.h file, there are 300 more lines in the new pins.h file vs the old one. In going through the changes almost everything has nothing to do with the board type I am using (33, Arduino Mega pin assignment), there is one section that I am wondering about, in the new pins.h file the section reads:
#define SCK_PIN 52
#define MISO_PIN 50
#define MOSI_PIN 51

In the old pins.h file it reads:
#define MAX_SCK_PIN 52
#define MAX_MISO_PIN 50
#define MAX_MOSI_PIN 51

All the other changes are for different controller boards, but maybe i'm missing something.. Please let me know..

Are you using complete code bases? Or are you mixing and matching files? The reason I'm asking is if you use and old Pins.h with a new code base, the difference in the names is enough that those pins will be undefined and of course, the SD Memory card won't work!

[Roxy]

Roxy, I have to thank you for turning me on to diff viewers. It made it so much easier and quicker to migrate my customisations and settings from my old Marlin over to DACB's new fork. Thanks!

Yeah... Visual Diff programs are great! Especially for this kind of stuff. Of course you know the original diff program was for UNIX. And it was super helpful. But now with visual diff programs, it is fairly straight forward to merge pieces of code from one code base into the other. And I think one way or the other, that is going to happen with that print size tweak for the G29 that somebody else did. But we still need the corresponding piece that does the post processing to get the GCode commands right.

The one I use is ExamDiff Pro. The cool thing about it is that it is smart about white space. If somebody changes the indentation of a line or puts an extra space in it, it shows up as a 'non-important change'. A lot of diff programs don't handle white space nicely. It also handles whole directories. So it is pretty straight forward to find which files changed even if there is 20 or 30 of them in a code base.