Marlin: Z_MIN Endstop / Probe usage on a board with limited input pins

[theinternal]

I'm on Marlin 1.1.9 and am using a board with 3 endstop input pins: XMIN, YMIN, ZMIN.

I want to use a deployed Z_MIN_PROBE for auto bed leveling, a simple pressure contact based switch basically. The probe's logic is based on "Z_MIN_PROBE_ENDSTOP_INVERTING true" while "Z_MIN_ENDSTOP_INVERTING false" is correct for the Z_MIN endstop of the pre installed endstop of the machine.

No matter what i try, I end up having either one or the other one working at the same time.

SanityCheck.h states that "Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN requires Z_MIN_ENDSTOP_INVERTING to match Z_MIN_PROBE_ENDSTOP_INVERTING." which forces two completely different things into one definition.

Why is that?

If I were a more competent coder I'd surely be able to figure out a way out of this. Unfortunateley I'm too dumb to figure this out, no matter how much I keep staring at the code.

Please help me out!

[AnHardt]

What should the state of the pin be when endstop and probe are not triggered when the logic is different? Ligh? How?

[boelle]

also i think it will help if you attach your 2 config files in a zip file

[reloxx13]

it just says u should invert (or not invert, ur config is missing, shame on u) both.

#define Z_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MIN_PROBE_ENDSTOP_INVERTING false // set to true to invert the logic of the probe.

or

#define Z_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define Z_MIN_PROBE_ENDSTOP_INVERTING true // set to true to invert the logic of the probe.

and shame on u even more if u dont close this issue if its fixed ^^

[theinternal]

@boelle here are the config files (I doubt they'll help much though):

13266.zip

Maybe I didn't make myself clear in the initial description, so let me give it another try:

I understand how the configuration works, what the descripton says, that "ligh" and "how" are not proper states (thx @AnHardt and @reloxx13 pointing out the obvious, the downvotes and the "shaming"!?) and what I need to define to have the firmware compile without errors.

I'm looking for a solution (I guess this makes it less of an "issue" and more of a "feature request") to the following scenario:

• controller board without available free PINS (Z_MIN is already in use by - you guessed it - Z_MIN enstop)
• the Z_MIN endstops' logic calls for "Z_MIN_ENDSTOP_INVERTING false" - this is the state the printer is operating in for at least 99.99% of the time
• I want to use a different sensor (simple, low cost nozzle based pressure sensor) for AUTO_BED_LEVELING_BILINEAR - a state the printer will be operating in for less than 0.01% of the time
• the bed leving sensor's logic is based on "Z_MIN_PROBE_ENDSTOP_INVERTING true"
• I know I have to unplug the Z_MIN endstop and plug in the probe sensor for AUTO_BED_LEVELING_BILINEAR and reverse this after leveling is done each time
• I understand that there is a potential risk of damaging the hardware if I forget to plug in the correct switch and homing/leveling fails due to this
• I understand that Marlin does not support this method in its current state and there is no way I can "configure" my way out of this (that makes it even more of a "feature request" I guess).

Thank you for you attention!

[reloxx13]

i dont get it why u want two z endstops...

as far as i know, its not possible to change the invert rule on the go.
ull need another input pins on the board.

i didn´t find a gcode for it, too.

the main problem is:
the printer wont know when u switched the endstops, so it will be needed to add another gcode which changes the invert state and ull have to call this everytime u change the endstop.
if u have more then one input pins for the z endstop, u can configure them seperatly.

tell us ur problem when u only use the sensor as endstop.

[AnHardt]

I guess you''ll be tired of changing the plugs very soon.
The obvious idea then is to use a switch to change the lines. Don't do that.
The proper solution is to use a simple NOT-gate (Inverter, 74xx04, 74xx14, 74xx19) to change the polarity of one of the lines. This will cost you less than the switch.

[ghost]

To clarify a little: Use the probe BOTH as the ZMIN switch AND also as the probe. That means: Disconnect the old ZMIN switch, remove it. Attach the probe as the ZMIN switch, configure accordingly.

Then when homing, the probe will be your home-point-switch. When probing, it will be the mesh generator. Configure the right (must be negative) offset for printing, the probe contact must be below the level of the print head.

If it is a pressure sensitive switch then configure moving down slowly on homing and on probing.
If it needs deployment, this will work (I use a BLTouch in this szenario).

[theinternal]

Thanks to everyone (!) for their input!

I tried fiddling around with a breadboard, some cables and a 74LS04 inverter (as suggested by @AnHardt (thx)) but due to my lack of experience I couldn't get this approach to work (the probe's signal gets "drowned" when I process it through the IC and I end up with a constantly open or triggered state, according to the firmware configuration no matter what I try).

Thanks to @FanDjango for the clarification that I can change my hardware setup, so that the probe acts as the regular Z endstop (most of which I already knew, it might be helpful for others in comparable situations though, so thanks for that too)!

@reloxx13 thanks for your suggestions and your analysis too! I want two different endstops/probes because it is the most convenient solution and the approach I believe is most reasonable for my (!) setup. I honestly don't know enough about coding to make a profund judgement as to why a hardware solution would be the simpler, more direct or more reasonable approach. It absolutely may be!

Yet, I still believe that incorporating a scenario for MBs with limited endstop inputs, that would allow Marlin to offer up even more options for those limited inputs, is a good thing. From my (limited) understanding, there should be a way to use one input signal, during two different states in two different ways/configurations in software. Am I wrong in this assessment?

Should 3D printer manufacturers offer better hardware? ABSOLUTELY! Are there users with very limited hardware out there, who want to add features that their hardware does not support OOTB but potentially supports through an update that incorporates all the potential advantages available at the time? You be the judge.

Fun fact: I'm a hardware retailer myself, so every time software doesn't accomplish something it could potentially do, I have an argument for another hardware sale. I could easily "solve my problem, by grabbing one of the boards I have in stock and configure and flash it with whatever configuration I want" and be done with it.

Yet, I have this "old" (1,5y) board in a fully functioning printer in front of me, that I want to add one simple function to, one that I know it can absolutely handle, and can't get rid of the feeling that it would be wrong to "take the easy route".

Poor software generates wasteful hardware.

Let's make progress... :D

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.