Problem with Autohome AND next with Display

This is a X-Posting from german User Forum "Software" but I post it here again in english because its actually a Developper topic and i am confident
that the australian main designer can easier handle it in english

I use Marlin 1.1.4 with my MPCNC router and i have recently added the Endstops.
My goal is beeing able to continue milling WITHOUT any offset after a tool change.
For that my strategy is to incluce an Auto-Home command (G28) into my program right after tool change.

My 1st Autohome works at a glance like this:

* Lift Z-Axis
* Zero X Axis ( 2x touchdown)
* Zero Y Axis ( 2 x touchdown)
* Zero Z Axis ( 2x touchdown). The Contact happens between the milling tip and a metal sheet which i put onto the working piece.
(Be aware that i have endstop polarity inverted for all 3 axis)

If i redo Auto-Home right afterwards, Auto-Home does not work anymore.

It is just

* Lift Z Axis and wait
* until I hit the emergency stop

After power reset autohome works again, and this is 100% reproducible.

Does Marlin remember that autohome has already been performed and acts differently in successive trials ?

Please find my Configuation of my Marlin 1.1.4 Attached

While I tried to find out, if the problem is already solved in more recent versions of Marlin, I have downloaded and configured 8 different Marlin releases already.

Unfortunatly I realized that more recent versions of marlin introduce even more Errors.
Starting with Version 1.1.9 the Content of My Display appears to be scrambled or distorted). With 1.1.8 Display is still OK.

The Display which i am using is this one:

#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

I even tried to decrease the SPI to 1/8 speed, but without success

Looks like it could be a timing issue with the MOSI pin, Hold time ??

Additionally it was quite painful for me as marlin did not correctly remember the EEPROM settings for my Z Axis : 400 Steps/mm, it always reverted to 4000 Steps/mm.
Marlin announces to keep the eeprom settings while changing the Firmware Version.

Additionally Starting with Version 2.0.5.3 my display won't show anything at all anymore.
With 2.0.5.2 there was still scrambled artifacts.

Thank you for reading.
Looking forward to getting useful feedback now

Thank you very much and nice greets from Lake of Constance

Cant help with endstops

but scrambled display is delays

Add he following to your boards pins.h file or in Configuration.h


#define ST7920_DELAY_1 DELAY_NS(125)
#define ST7920_DELAY_2 DELAY_NS(125)
#define ST7920_DELAY_3 DELAY_NS(125)

Values are dependent on your screen.

Quote
gsohler
Does Marlin remember that auto-home has already been performed and acts differently in successive trials ?

Please find my Configuration of my Marlin 1.1.4 Attached

Starting with Version 1.1.9 the Content of My Display appears to be scrambled or distorted). With 1.1.8 Display is still OK.

The Display which i am using is this one:

#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

Use Marlin 1.1.9BF or Marlin 2.0.x and Follow Dust suggestions by adding delays.

A few things that could by using the below on newer versions of Marlin.

#define Z_MIN_PROBE_ENDSTOP_INVERTING true // set to same logic as "Z_MIN_ENDSTOP_INVERTING".
#define FIX_MOUNTED_PROBE

#define S_CURVE_ACCELERATION
#define RESTORE_LEVELING_AFTER_G28

#define Z_SAFE_HOMING
#define EEPROM_SETTINGS 
#define INDIVIDUAL_AXIS_HOMING_MENU

Edited 1 time(s). Last edit at 05/06/2020 04:04PM by Roberts_Clif.

---

Computer Programmer / Electronics Technician

Hi Guys,

Thank you for your valueable replies!

The Delays worked out of the box, I am running with the latest Version Marlin 2.0.5.3 now!

FIX_MOUNTED_PROBE
and
Z_SAFE_HOMING

Dont like this, i need the Z-Homing happening in the XMIN and YMIN position

S_CURVE_ACCELERATION
great thing, i will keep it

RESTORE_LEVELING_AFTER_G28 does not seem to have an effect for my plotter.

EEPROM_SETTINGS and INDIVIDUAL_HOMING_MENU , i like it

Finally, my problem with the 2nd homing persists and is not fixed using all these settings.

What can we further do to debug ?

Can you upload a video to a share like Google Drive an post a link to the video so we can watch.

---

Computer Programmer / Electronics Technician

you can set the Z_SAFE_HOMING location in the following part of you configuration.

#if ENABLED(Z_SAFE_HOMING)
#define Z_SAFE_HOMING_X_POINT X_CENTER // X point for Z homing when homing all axes (G28).
#define Z_SAFE_HOMING_Y_POINT Y_CENTER // Y point for Z homing when homing all axes (G28).
#endif

just replace X_CENTER and Y_CENTER with the positions you want. Perhaps 0 if your sure that is a safe location.

Hi Group,

I have now created a video of my MPCNC router in Action.

Is shows the issue with the Autohome

1st Autohome works like a glance
2nd Autohome just lifts Z Axis

after reset, 1st autohome also works ok

The two spots in my display is where its somehow broken

[photos.app.goo.gl]

BTW: when i had save homing enabled with my printer, 1st autohome did neither work for z-axis(probably needs a different endstop pin), so i disabled it again

Forgot to share my latest config for use with Marlin 2.0.5.3

Hi Group,

Thank you for looking into my post!

Weekend is about to come and i will have more time then to look into my homing issue again.
I am just wondering ...

* If you had the chance to look into my video
* If could easily enough see the actions of the axis( its not 100% perfect, i need to admit)
* If you find, that all movements of the 1st auto-home are right
* are there more debugging commands to try to pinpoint the issue
* Is it so uncommon to have non-inverting endstops that nobody else sees my issue ? ( i believe the problem is about that)
* Where do i spot into the code to see the behaviour of autohome beeing implemented ?

Any Answer to the above question can help me to progress ...
Thank you again!

Need to correct myself:

During 2nd Autohome, the Z axis does not lift infinitely but it *does* stop.
I found this out while i deattached the Z axis.
the 2nd lifting height is somewhere between 90 mm and 150 mm (instead of 10 or so).

But it did not proceed after lifting this much so it must be an emergency give-up.
What does Autohome wait for while its lifting the Z Axis ?
The Z-Enstop is not triggered since the beginning.

You have built a MPCNC you should start with the MPCNC firmware then upgrade to the newer Marlin 2.0.5.3 .

OK I see in your video that you have a -14C this is because you have selected thermister #1 this is expecting a min-temp of 170C
Where you do not have a thermister you should select the dummy thermister below.

#define TEMP_SENSOR_0 999

After selecting the dummy thermister you could disable the temperature sensing using

#define DUMMY_THERMISTOR_999_VALUE 170

Edited 2 time(s). Last edit at 05/11/2020 03:00PM by Roberts_Clif.

---

Computer Programmer / Electronics Technician

Hi Robert,

Thank you for your valuable answer.

I used

#define TEMP_SENSOR_0 999
#define DUMMY_THERMISTOR_999_VALUE 170

but there was no reaction on that. still -14 Deg Celsius, so i thought it might be an index error

#define TEMP_SENSOR_1 999
#define DUMMY_THERMISTOR_999_VALUE 170

still nothing. I use the with Marlin 2.0.5.3
Is there a typo in the name of the define ?

Actually I have doubts that bad temperature readings has an effect on my autohome behaviour, but its still worth a trial

In the meantime I managed to attach the serial Console and i was able to debug the readings of my endstop with M119
all the readings are correct.Initially all 3 endstops are open. After 1st Autohome all 3 endstops are TRIGGERED.
Before 2nd autohome i moved my axis so all 3 endstops are open again.
Especially Z Endstop is open now. IF i do the 2nd Autohome, Z Axis lifts again something between 90 and 120 mm

What can be wrong in the firmware ?

Hi Group,

Beeing desparate enough I finally started putting debugging information into the code and i log relevant variables during my Homing process.
As it turns out they actually differ between the 1st and 2nd Homing process and i was right: The Firmware actually remembers the state of the
Homing process.
I found the Relevant code in (what a surprise ...) in G28.cpp

Here it is
------
const float z_homing_height =
(DISABLED(UNKNOWN_Z_NO_RAISE) || TEST(axis_known_position, Z_AXIS))
? (parser.seenval('R') ? parser.value_linear_units() : Z_HOMING_HEIGHT)
: 0;
SERIAL_ECHOLNPAIR("z_homing_height is", z_homing_height); // 5,5

if (z_homing_height && (doX || doY)) {
// Raise Z before homing any other axes and z is not already high enough (never lower z)
SERIAL_ECHOLNPAIR("test axis ",TEST(axis_known_position, Z_AXIS) ); // 0,1
SERIAL_ECHOLNPAIR("current_position ",current_position.z ); // -100,-100
destination.z = z_homing_height + (TEST(axis_known_position, Z_AXIS) ? 0.0f : current_position.z);
SERIAL_ECHOLNPAIR("destination.z is ", destination.z); // -95,5
if (destination.z > current_position.z) {
if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPAIR("Raise Z (before homing) to ", destination.z);
do_blocking_move_to_z(destination.z);
}
}

---
And here comes the explaination:
The SERIAL_ECHOLNPAIR were added by myself and the values after the comment correspond to the result of the 1st working homing process and the 2nd homing process.
The state which is saved is axis_known_pos, Z_AXIS. It increases the position of the destination Z height by 100. which makes z axis lift so increadible high.

Yes, my Zmin position is intentially set to -100 because i want to approach negative Z coordinates when the mill dives into the material.
And yes, it should be still a Z Min endswitch , because its approached from above even though the endstop switch lies centered within zmin and zmax.

So whats the best approach to solve my issue while keeping all Marlin core concepts ?
Is it possible to make marlin forget that it has been homed before ?

So for a marlin insider the task should be easy to solve now.
I am not yet , this is why i ask for support again

Greets ...

... just for anybody which happen to have the same Problem as i had.


M18 - Disable all Steppers

is the key to solve my issue. If you use this command before the 2nd Autohome, even the 2nd Autohome thinks that the position of Z is unknown(as it might have moved)
and subsequent autohomes behave exactly identical

However, I was really convinced, that the expertice of the marlin Developpers newsgroup would know the answer of such a problem on the fly given i have provided so many hints
until i could solve the issue by myself.

Thank you for the hints with my display, though ...