Homing offset and no LCD display of zMin trigger
Running repetier firmware 1.0.2 on a Mega with RAMPS1.4 and a RepRap discount RAMBO display
Printer is a home made HEVO with optical min/max endstops on X and Y and an inductive sensor for zmin (no max endstop on z)
homing order is x,y,preheat,z
I also have the z-probing enabled with a 5x5 grid
Activating the home completes the x and y but as it does the z it shifts the y to -5 (x stays at 0)
I cannot see *anywhere* in the config that this is set and I don't understand why this is happeneing
Further, the z can home successfully at y=-5 as my bed is big enough and I see it retract and retry as expected when the led on the magnetic sensor illuminates
...but the LCD display icon (the empty/filled in square) does not replicate the state of the zmin whilst homeing or if activated manually at any other time say with the use of a screwdriver tip
Any ideas on what is happening here?
Printer is a home made HEVO with optical min/max endstops on X and Y and an inductive sensor for zmin (no max endstop on z)
homing order is x,y,preheat,z
I also have the z-probing enabled with a 5x5 grid
Activating the home completes the x and y but as it does the z it shifts the y to -5 (x stays at 0)
I cannot see *anywhere* in the config that this is set and I don't understand why this is happeneing
Further, the z can home successfully at y=-5 as my bed is big enough and I see it retract and retry as expected when the led on the magnetic sensor illuminates
...but the LCD display icon (the empty/filled in square) does not replicate the state of the zmin whilst homeing or if activated manually at any other time say with the use of a screwdriver tip
Any ideas on what is happening here?
Comments
Does M119 show z min triggered when it is trigegred?
Position for homing z is set in configuration, To this the z probe offset is added but that should not be displayed. So I think you have set zhoming position to 0/-5
The pin setting appears to be the same in the web config but in the generated configuration.h there is no zMinPin defined!
it contains:
(which I guess why the probing reacts)
but no #define for the zMinPin !
in the configuration string section:
However, my ZHOME_X_POS and Z_HOME_Y_POS are both set to 999999
Let me explain *why*
in the configurator it says "[mm / 999999 = do not change]"
I read this as meaning "the units in this section are mm and IF the config boxes have 999999 in them then do not change this value or bad things will happen"
....so I left them as 999999 !
Re-reading it and thinking about it I believe this means "the units in this section are mm and if you put 999999 INTO them then whatever x and y co-ordinates the head is at when it does the home, that is what is used for the z home position"
My interpretation aside, perhaps they should be 0,0 but 999999 is properly defined as IGNORE_COORDINATE therefore I would expect it to correlate and not move
I have also noticed I don't have Z_PROBE_DISABLE_HEATERS checked but I do have ZHOME_MIN_TEMPERATURE set to 0
My gut feeling is that the permutation of settings I have is an edge case for the configurator and it misses the zMinPin setting
The use of 999999 and the conclusion that the X and Y should not change and they are already at 0,0 is a leap of faith !
I have attached 2 screenshots of the configurator; endstops and z-probe along with my configuration.h file for consideration on these findings
If left at 999999 999999 it wil try to home Z at the current xy location
note that if the x and y are undetermined (say after turning the steppers off and the location indicates an assumed value then ???), doing a home z will home x,y (to 0,0) then z, but with the y=-5 offset
If x and y are determined values then the z home does stay static to the current x and y co-ords
sending a G28 always causes the z to home at 0,-5 irrespective of the x and y being undetermined or known
Having no entry for Z_MIN_PIN is ok as this is preset with ORIG_Z_MIN_PIN or at least it should be. And being the same you must get same report for z min with M119. In fact if you look into Endstops.cpp in update you see:
#if FEATURE_Z_PROBE
#if Z_PROBE_PIN == Z_MIN_PIN && MIN_HARDWARE_ENDSTOP_Z
if(newRead & ENDSTOP_Z_MIN_ID) // prevent different results causing confusion
newRead |= ENDSTOP_Z_PROBE_ID;
if(!Printer::isHoming())
newRead &= ~ENDSTOP_Z_MIN_ID; // could cause wrong signals depending on probe position
#else
if(Z_PROBE_ON_HIGH ? READ(Z_PROBE_PIN) : !READ(Z_PROBE_PIN))
newRead |= ENDSTOP_Z_PROBE_ID;
#endif
#endif
You see in case of identical pins it even doe snot test z probe and just copies the z min state to z probe. To verify it is using that code you can add after#if Z_PROBE_PIN == Z_MIN_PIN && MIN_HARDWARE_ENDSTOP_Z
this line
#error compiles right part.
Next compilation should fail with the error message. Then you know it uses that case.
Having gone through the code, I am concurrent on your description of the default pin settings and now understand how they are set to "ORIG_" values from the start and only moved away from them if subsequently overridden with "user config"
The probe to y=-5 phenomena is a feature of having the X & Y homing position at 999999 (or what is #defined in the code as IGNORE_COORDINATE) - as soon as I set the X & Y homing positions to 0,0 then the y=-5 offset never happens
I do not believe I have the probe offset at anything apart from 0,0 as I had problems too with "moved to illegal values" errors if I had the true value of offset in there and I had to set it to 0,0 to make it work
My next attempt was to put back measured offsets into the probe offset (x=22, y=0) and it started to throw errors in the display about out of bounds moves again. At this point I then had the idea to move the X & Y homing positions to 22,0 and it then worked...but in a strange way. It brings the print head tip (as opposed to the probe centre) down at 22,0 to about z=2mm and at that point it moves the head tip to 0,0 and hence the probe centre to 22,0 for the move to measure the z home position. When its done that and its post probe raise, it zips back to 22,0, probes at that position (ie probe at 44,0) and then moves the tip back to 0,0,0 which is the true home position
I'm not sure why there is this switch at the final probing move - I would expect it to go straight there and I can't make out the second probe attempt at probe position 44,0 but with those settings I no longer get any out of bounds errors
Also, with those settings my 6x6 probe grid now works properly. my p1,p2,p3 positions are set at a bounding box of 25,25:275,275 so the 22,0 offset sits sweet withing that and when it does *those* probes the tip>probe values seem to work as you would expect ie the first probe is at tip location 3,25 (ie P1 25,25 less z_probe 22,0). For the first time ever, my bed is properly level !
Throughout all of this the LCD zmin indication (and corresponding results with M119) the zmin always stays low with the zprobe correctly switching between low (meaning "away from bed") and high (meaning "triggered and close to bed"). My gut feeling is that if I disable the z probing (FEATURE_Z_PROBE) the LCD and M119 indication will show for zmin, but this will be tomorrow as I need some rest now!
I have recompiled with FEATURE_Z_PROBE 0 being the only change and the zmin on the LCD display then shows correctly with a filled in square when the probe is triggered and an empty one when it is clear.
I've tried to decipher how this is achieved and I believe the state is held in Endstops::zMin() which is #if'd in the header file but I can't work out how the display is achieved. I think you use a placeholder system of %sz but I see no difference in this between FEATURE_Z_PROBE being 1 or 0
Is there anything else I can try to debug further?
#if FEATURE_Z_PROBE
#if Z_PROBE_PIN == Z_MIN_PIN && MIN_HARDWARE_ENDSTOP_Z
if(newRead & ENDSTOP_Z_MIN_ID) // prevent different results causing confusion
newRead |= ENDSTOP_Z_PROBE_ID;
if(!Printer::isHoming())
newRead &= ~ENDSTOP_Z_MIN_ID; // could cause wrong signals depending on probe position
#else
if(Z_PROBE_ON_HIGH ? READ(Z_PROBE_PIN) : !READ(Z_PROBE_PIN))
newRead |= ENDSTOP_Z_PROBE_ID;
#endif
#endif
As you see this line is the causenewRead &= ~ENDSTOP_Z_MIN_ID; // could cause wrong signals depending on probe position
it disables z min when z probe triggers and that for a good reason! Z probe triggers before you hit the bed, so if you test endstops and go to Z = 1 and then down to Z=0 it will stop before the bed is hit just because z min is triggered. In fact you have no z min because you have a z probe used for homing. And therefore z min never triggers. It would be more correct to not show it in M119 at all as it never triggers by design.
I can appreciate the need to ignore z-min if you are using z-probing
The discrepancy I can see is in the LCD display output
The code seems to imply you have a placeholder as I said before (decoded in ui.cpp > UIDisplay::parse)
You decode to 3 characters with variable names c, c1 and c2
c looks for the % placeholder
c1 is the first character of the command
c2 is the second character of the command
The parser does a case 's': for c1 at line 1598
this is the trap for the %s endstops
it rattles through permutations of c2 that cover xyzminmax endstops and then finally for %sP for the probe
uimenu.h lists those commands so for example %sX is the x max endstop but interestingly here there seems to be no mention of the %sP
I think that means that the %sP placeholder is never used in the menu system which is why with z-probing using the z-min pin we never see the z-probe state in the menu display, only ever z-min which is always 'off' because of the need to ignore that in this scenario
I can't quite get my head around how this is then structured forward to create the menus and show the right item
Have I interpreted the code correctly so far?