Bed auto leveling works, but x/y axis are off with correct offset

[Roxy]

I really appreciate all of the help.
I noticed however in that version of Marlin, that there was no Marlin.pde file that I normally use to upload the firmware with the Arduino software. I ended up just copying my .pde file over to compile it.(I hope that was ok because I'm not really sure how else to remedy that issue)

The .ini and .pde files switched between Arduino v.022 and Arduino v1.05 If everything compiles clean, you are good to go. But I suggest you download and install the v1.05 because some compiler bugs have been fixed in that version and right now you don't need extra variables when things don't work.

I'm going to try your version Roxy, but I was wondering if I could get some more information about how I should modify the pin.h because I have zero experience with messing with that. I'm going to go ahead and download your 9-15-2014-work copy.rar and see if I can't get that going. I was really hoping that Dacb's version was going to fix my issues because I was assuming it was a problem in my configuration.h. I feel more confused to why this I am experiencing this issue now more than ever lol.

Just take the stock, generic Pins.h from just about any Marlin release and replace that file in my version. I have a few extra things defined in my Pins.h and some stuff moved around to be on different GPIO pins. You don't want my changes. They are for my hardware setup. That is the only reason I pointed out that Pins.h was different so nobody would assume the generic #define's were there.

I almost forgot, here is the version of Marlin that I was using with my configurations. I did notice a few differences with mine and Dacb's in the configuration.h file in regards to endstop pullups and a few other things, but they must not be the cause of my issue since Dacb's version and configuration is still creating the same offset issue for me.

This is valuable information!

Roxy, I've been working on my configuration.h file for your 9-15-2014-Work Copy.rar, but when I got to a certain area it was so different than any other configuration.h file that I have ever messed with, that it just completely when over my head.

the part that has me confused and/or confused is about I'll paste below
-----------------------------------------------------------------
//===========================CALIBRATION PARAMETERS==========================
//================================================== =========================
...
#define DEFAULT_AXIS_STEPS_PER_UNIT {((XY_MTR_STPS/MICROSTEPPING_RATIO)/(BELT_PITCH*GEAR_TEETH)), ((XY_MTR_STPS/MICROSTEPPING_RATIO)/(BELT_PITCH*GEAR_TEETH)), ((Z_MTR_STPS/MICROSTEPPING_RATIO)/Z_ROD_PITCH),((PACKING_DENSITY*EXTRUDER_MTR_STPS*E XTRUDER_GEAR_RATIO*(1/MICROSTEPPING_RATIO))/(PI*BOLT_DIAMETER))}

Don't be scared of that stuff... Just delete it. All of that stuff is so that last line

#define DEFAULT_AXIS_STEPS_PER_UNIT

has the right numbers in it. I have symbolic values that get used in the calculation instead of just having final hard coded values there. Just put what ever your Configuration.h file's #define DEFAULT_AXIS_STEPS_PER_UNIT line is into the file to replace the stuff that is there.

I'm completely a newb when it comes to motor stepping and motor specs/belt pithces and what not. Any idea what I could enter for these values or where I could teach myself in order to better understand how to configure this part?

Well... For now delete that stuff up above and replace it with your hard coded numbers. But if you print out that section, you can walk through the calculations and see how those numbers are generated. Probably, my final numbers are not too far off from what yours are. But the point is with my setup I can change any one component and the correct numbers will get generated. For example, I could change my belt pitch and put the new number in there and in theory, my printer will stay calibrated.

[Pronus]

Ok, so I updated to Arduino v1.05. Swapped out the pin.h file. Finished up the configuration.h file like you said by just entering my hard coded numbers instead of the equations and then uploaded it to my board.

I can totally tell a difference in how the printer acts with a G28 and G29 (I actually like it's behavior better now) however, I'm still getting the exact same offset issues on the x/y axis. Of course though, the z axis is working great as it has been. I'm having a hard time understanding how I could be experiencing this problem especially after using someone elses code that is seemingly working.

BTW, I love the idea of changing one variable or component to generate the right numbers for the stepper motors. I definitely plan on educating myself further in order to better understand every little component of the printer and how it relates to axis steps per unit and etc. The plus side of having issues with the printer has granted me some much need knowledge about how it works.

[Roxy]

Ok, so I updated to Arduino v1.05. Swapped out the pin.h file. Finished up the configuration.h file like you said by just entering my hard coded numbers instead of the equations and then uploaded it to my board.

I can totally tell a difference in how the printer acts with a G28 and G29 (I actually like it's behavior better now) however, I'm still getting the exact same offset issues on the x/y axis. Of course though, the z axis is working great as it has been. I'm having a hard time understanding how I could be experiencing this problem especially after using someone elses code that is seemingly working.

BTW, I love the idea of changing one variable or component to generate the right numbers for the stepper motors. I definitely plan on educating myself further in order to better understand every little component of the printer and how it relates to axis steps per unit and etc. The plus side of having issues with the printer has granted me some much need knowledge about how it works.

OK, Please upload your Configuration.h and Configuration_adv.h file. Almost for sure the problem is there. And if it isn't we can start adding lines of debug code to figure out why things are going sour. But please be aware... If we have to go the debug code route... It maybe 3 or 4 days until you have closure.

[Pronus]

Configuration.hConfiguration_adv.h
Ok, here are both of the files. I really hope it comes down to me just messing something out in the configuration.h file

Thanks again

[Roxy]

I don't see anything crazy in the Configuration files. I do question if you should have the pull up resistors turned off. I think you should check into that. But that isn't the problem you are fighting right now.

Can you do a M502 and post what it says. And then do a M499 and reset your printer and see if it is still misbehaving.

If it is, then turn off these lines in the Configuration.h file:

//#define EEPROM_SETTINGS
//to disable EEPROM Serial responses and decrease program space by ~1700 byte: c
omment this out:
// please keep turned on if you can.
//#define EEPROM_CHITCHAT

[Pronus]

I realized when I put together the configuration.h to match your code base, that I enabled EEPROM_SETTINGS and adjusted my pull up resistors to be turned off because I was matching those of Dacb's configuration file since he had working auto bed leveling. Those were the only figures that I seemed to question that were different than my own configuration.h. (especially the pull up settings)well of course other than his different bed size, nozzle temps, servo endstop angles, and z-probe offsets. After enabling the EEPROM I did try to revert back to the default with a M502 just to see if it would make a difference.

Anyways, I just tried it again

>>>m502
SENDING:M502
echo:Hardcoded Default Settings Loaded

and am still experiencing the same issues, so after turning them off and trying to upload to the board with the Arduino software I recieved an error:

It highlighted: Invalidate_EEPROM_Settings(); // Roxy added function to guarintee we are using

"Invalidate_EEPROM_Settings' was not declared in this scope
------------------------------------------------------------------------------
Marlin_main.cpp: In function 'void process_commands()':
Marlin_main.cpp:3576: error: 'Invalidate_EEPROM_Settings' was not declared in this scope
---------------------------------------------------------------------------------

I can validate however, in the version I was previously using of Marlin I always had my EEPROM settings turned off and was still experiencing the issue.

[Roxy]

I realized when I put together the configuration.h to match your code base, that I enabled EEPROM_SETTINGS and adjusted my pull up resistors to be turned off because I was matching those of Dacb's configuration file since he had working auto bed leveling. Those were the only figures that I seemed to question that were different than my own configuration.h. (especially the pull up settings)well of course other than his different bed size, nozzle temps, servo endstop angles, and z-probe offsets. After enabling the EEPROM I did try to revert back to the default with a M502 just to see if it would make a difference.

I don't know what the correct settings are for the MakerFarm printers, but the Auto Bed Leveling should not factor into the end stop pull up resistors. (at least for the X & Y) They should be what ever other MakerFarm people are using. However, your printer is stopping at the end stops so what ever you have is not seriously wrong if it is wrong at all.

Anyways, I just tried it again

>>>m502
SENDING:M502
echo:Hardcoded Default Settings Loaded

and am still experiencing the same issues, so after turning them off and trying to upload to the board with the Arduino software I recieved an error:

It highlighted: Invalidate_EEPROM_Settings(); // Roxy added function to guarintee we are using

"Invalidate_EEPROM_Settings' was not declared in this scope
------------------------------------------------------------------------------
Marlin_main.cpp: In function 'void process_commands()':
Marlin_main.cpp:3576: error: 'Invalidate_EEPROM_Settings' was not declared in this scope
---------------------------------------------------------------------------------

I can validate however, in the version I was previously using of Marlin I always had my EEPROM settings turned off and was still experiencing the issue.

There was a small bug in the ConfigurationStore.h file. There is was a missing declaration for the case where EEPROM stuff is turned off. Please replace the existing ConfigurationStore.h file with this one. And then go back and see if you can do what the previous post requested.

[Pronus]

Ok, I replaced the configurationstore.h file with the new one and everything compiled and uploaded good. I ran my same routine G28, then G29, and then G1 F1500 X0 Y0 and I'm still noticing the exact same offset problem. I was kind of hoping I just messed up my configuration.h file so I wouldn't take up anymore of your time, but it doesn't seem like I got that lucky. I know the problem isn't fixed yet but thank you so much for trying. Without help I would be more than lost at this point over it.

[Roxy]

M502 currently says "Hard coded Default Settings Loaded." now?

What does M503 say? Can you cut and paste?

What happens when you press the X & Y home buttons on Pronterface? Does the nozzle end up in the corner of the bed where it belongs?

After doing the X & Y home using the PronterFace buttons, can you do a M114 and verify it thinks X & Y are at 0.00 ?

[Pronus]

Yes M502 does respond with"Hard coded Default Settings Loaded"

When I use the x and y home buttons I can confirm with an M114 that it is in fact at X0 Y0.

Also the numbers are not thrown off after a G28. G1 F1500 X0 Y0 will bring the hotend back to the correct X0 Y0. It isn't until I run the G29 that things get thrown off.