Results 11 to 20 of 33
-
09-16-2014, 02:04 PM #11
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.
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.
This is valuable information!
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.
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.
-
09-16-2014, 04:08 PM #12
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.
-
09-16-2014, 04:40 PM #13
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.
-
09-16-2014, 05:52 PM #14
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
-
09-17-2014, 08:46 AM #15
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
-
09-17-2014, 09:52 AM #16
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.
-
09-17-2014, 10:13 AM #17
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.
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.
-
09-17-2014, 10:27 AM #18
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.
-
09-17-2014, 10:42 AM #19
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 ?Last edited by Roxy; 09-17-2014 at 10:50 AM.
-
09-17-2014, 10:51 AM #20
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.
My 3D Norn Emissary print
09-13-2024, 02:28 AM in 3D Printing Gallery