Saving G29 Bed Level Correction Matrix to EEPROM

[printbus]

ultralcd_implementation_hitachi_HD44780.h

I get it to compile with this tab from my standard firmware.

Um, yeah. That file uses a different approach to include the liquidTWI2.h file. It'll search the directory with the rest of the source files (eg. tabs I guess). The standard Marlin file will expect liquidTWI2 to be installed in the Arduino libraries area - just what configuration.h says.

FOLLOWUP COMMENT: In configuration.h, uncommenting the #define for LCD_I2C_VIKI invokes a #define for LCD_I2C_TYPE_MC23017. Look for the ifdefs for that string in the two ultralcd_implementation_hitachi_HD44780.h files. The statement #include "LiquidTWI2.h" says search in the source directory first for this file, and then search in the libraries area. The Marlin statement #include <LiquidTWI2.h> says don't look in the source directory - just search the libraries area. Eric Zalm likely didn't want to include the LiquidTWI2 library as part of the Marlin distribution, perhaps because it is a third party library not unique to Marlin or the 3D printer application. There may be other more subtle differences between the two files - I didn't compare the details.

[Fri]

Um, yeah. That file uses a different approach to include the liquidTWI2.h file. It'll search the directory with the rest of the source files (eg. tabs I guess). The standard Marlin file will expect liquidTWI2 to be installed in the Arduino libraries area - just what configuration.h says.

FOLLOWUP COMMENT: In configuration.h, uncommenting the #define for LCD_I2C_VIKI invokes a #define for LCD_I2C_TYPE_MC23017. Look for the ifdefs for that string in the two ultralcd_implementation_hitachi_HD44780.h files. The statement #include "LiquidTWI2.h" says search in the source directory first for this file, and then search in the libraries area. The Marlin statement #include <LiquidTWI2.h> says don't look in the source directory - just search the libraries area. Eric Zalm likely didn't want to include the LiquidTWI2 library as part of the Marlin distribution, perhaps because it is a third party library not unique to Marlin or the 3D printer application. There may be other more subtle differences between the two files - I didn't compare the details.

So where would I have to save the files in order to get this to work?

[printbus]

So where would I have to save the files in order to get this to work?

From the info provided at the github link in the Marlin configuration.h file -

Installation:
extract LiquidTWI2/ into <arduinosketchbook>/libraries/LiquidTWI2

I haven't actually installed and tested this, but it seems you go to wherever you have Arduino installed, look for the libraries folder, and you should end up with a folder there when you are done named LiquidTWI2.

[Fri]

Roxy, I have a few things after the LCD which I would like to change and hope you can help me.
The issue that suddenly developed is still there, the z stop triggers the x & y. We got a work around with lifting z, and that is okay.
Now I would like to turn the servo line in conf h off, to avoid the pauses. But I would like to make z move up 2-3 mm after homing z to untrigger the z stop and therefore make it impossible to trigger x & y. ???

How is the M851 different to the z offset in eeprom. It will be lost after a restart or turn off of the machine.
Also, can slicer pre codes be implemented in the fw?

[Fri]

Good deal, this compiles!!!

[printbus]

Good deal, this compiles!!!

At least you're a step closer. I'm not into the auto bed leveling scene, so I can't help with that part.

[Roxy]

You need to have:

#define AUTO_BED_LEVELING_GRID_POINTS 5

to do a G29 n5

[Fri]

You need to have:

#define AUTO_BED_LEVELING_GRID_POINTS 5

to do a G29 n5

Changed it to n3....thanks a lot! It works

[Fri]

I am using your firmware on one machine relatively successfully, on another it acts very erratically. I attached a copy of it.
On both machines, unless I do an M502, the endstops affect the motion of other axises. i. E. if z is triggered, x thinks it's home. I can work with this by moving z up, but it is not ideal. If you hit print for example when z is triggered,
the machine thinks the current position is home of all axises and starts printing form there...not good.

On the newer machine that I am currently working on, it's a whole different deal. This machine has the stop switches x and y in the left back corner (similar to Ultimaker), meaning Ymax Xmin. Z is a proximity sensor and Zmin.
I have to mention that an earlier prototype worked good, until the day all my bed leveling issues started. So for example, when connecting the machine and running an m119, if no axis is home, it shows x max triggered. There is not
switch on x max!! If I home y the x axis stop is no longer triggered and it's all working fine. So if I run a g29 after g28 z won't come up anymore, it goes down, every time I home all. If I send a M502, all home works again.

What am I missing?


Marlin_Eight3_grid_eep.rar

[Roxy]

Attaching your code was helpful.... I'm not sure what you are seeing. But I would try a couple of things to debug it. First, I would get it into a state where it isn't moving properly. And then I would give it an M119 command to see what it thinks the state of the end stops is. It may be possible you have bad wiring or switches. If this fails to show anything that might be helpful, I think I would try rebuilding the firmware with a few changes. For starters, I think I would change:

#ifdef ENDSTOPPULLUPS
  //#define ENDSTOPPULLUP_XMAX
  #define ENDSTOPPULLUP_YMAX
  //#define ENDSTOPPULLUP_ZMAX
  #define ENDSTOPPULLUP_XMIN
  //#define ENDSTOPPULLUP_YMIN
  #define ENDSTOPPULLUP_ZMIN
#endif

to:

#ifdef ENDSTOPPULLUPS
  #define ENDSTOPPULLUP_XMAX
  #define ENDSTOPPULLUP_YMAX
  #define ENDSTOPPULLUP_ZMAX
  #define ENDSTOPPULLUP_XMIN
  #define ENDSTOPPULLUP_YMIN
  #define ENDSTOPPULLUP_ZMIN
#endif

Just to make sure everything has pull up voltage to it to eliminate noise. You won't hurt anything by doing this if nothing is connected to those pins. I would then repeat the above stuff to get the printer into a mode where it doesn't move correctly and try to give it another M119 to see what it thinks of the world.

Probably, I would try rebuilding the firmware with these changes to eliminate the suppression of moves when the printer thinks the endstops are being touched. This is kind of brute force, but if these changes make a difference, that will be confirmation we are dealing with an endstop switch stopping the movements:

#define min_software_endstops false  // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops false  // If true, axis won't move to coordinates greater than the defined lengths below.

#define DISABLE_MAX_ENDSTOPS
#define DISABLE_MIN_ENDSTOPS


//  #define Z_SAFE_HOMING   // This feature is meant to avoid Z homing with probe outside the bed area.