How to Re-Purpose XYZ (min/max) Endstops

[kcheeeung]

Hello everyone. I would like to create a "4th axis" using the extruder stepper motor. In the current 3D printer setup, we have the XYZ positions using either XYZ min/max pins. I would like to use one of those extra pins such that I can achieve this.

Current setup is that each XYZ min/max pins, when activated (configured to stop only the XYZ axes respectively), is to stop the stepper motor from moving, which is what I am looking for. I would like a way such that the "4th axis" knows when to stop without crashing or damaging the system.

What's the best way of doing so? I have attached an image to demonstrate what I am trying to do.

Thanks for reading.

[Bob-the-Kuhn]

Is this for 1.1.x or 2.0.x?

[Bob-the-Kuhn]

This might work. They define/create E_MIN and E_MAX endstops.

E endstops 1.1.x.zip
E endstops 2.0.x.zip

You'll need to define E_MIN_PIN and/or E_MAX_PIN as needed.

You'll also need to add the following to the Configuration.h file as needed.
#define E_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define E_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.

The E endstop(s) are setup with the pullup resistor always enabled.

[Bob-the-Kuhn]

Had a couple of compile errors. Here's the corrected files.

E endstops 1.1.x rev B.zip
E endstops 2.0.x rev B.zip

[kcheeeung]

Wow! Thanks for the quick response Bob! I'm working with 1.1x right now. Great work of you and the Marlin team on the development on the Marlin 1.1.x and 2.0.x. The Marlin 2.0.x looks very promising!

I've been looking through the source code myself previous to try to understand what were the key changes needed, but I've come somewhat close as to identifying that I woud need endstop.cpp. It's pretty difficult to understand the Marlin unless one has developed and worked with it a lot. I hope to learn more soon.

The next steps would be define the E_MIN_PIN and E_MAX_PIN in the .h file of the board I'm working with. Great to hear back from you, and I'll you know how it goes.

[Bob-the-Kuhn]

I have not been able to test the changes.

Let me know if you run into trouble & I'll see what I can do.

[kcheeeung]

I hope you had a nice Thanksgiving holiday. I couldn't figure this one out yet. I made the changes as mentioned of the E_MIN_INVERTING. I reassigned pins in RAMPS.h for testing purposes and also so I don't have conflicting pins. Everything seems to compile correctly, but testing with the endstop doesn't appear to stop the E motor when it's moving
Sample Gcode:
G92 E100
G1 E0
click endstop, but still moves to 0 position.

**pins_RAMPS.h**
// Limit Switches
//
#define E_MIN_Pin           3
#define X_MIN_PIN           2//3
#ifndef X_MAX_PIN
  #define X_MAX_PIN         2
#endif

Not sure what else might be missing. The "E axis" exists for the extruder filament, but there aren't any bounds to it. It appears you can send any G0/1 E## and the extruder motor will spin regardless.

In a setup with filament runout sensor, I believe 4 endstops are used as well. The X, Y, Z, and finally another one for the filament sensor. The filament runout sensor looks like it calls quickstop_stepper() when it's activated (it stops the single E motor? all motors?) Do you think this is what we need? Would this optimal is accuracy and repeatability?

The intended idea is to use the E# in the gcode to spin a certain number of steps to reach a particular position, which requires the knowledge of a "home or reference point." I'd have a post processing script do something like this to the gcode:
G0/1 E## (in the correct + or - direction to "home")
firmware stops E motor when it hits endstop or endstop is touched/activated
G92 E0 (Define "homed" position as the 0 point)
G0/1 E## (move to calculated position based on E steps/mm)

Sorry for this long post. What is your take on this?

[kcheeeung]

Hmm. I have done a bit more digging and realized that the endstops result in stepper.endstop_triggered(), which ultimately leads to kill_current_block().

**stepper.cpp**
void Stepper::endstop_triggered(AxisEnum axis) {
  #if IS_CORE
    endstops_trigsteps[axis] = 0.5f * (
      axis == CORE_AXIS_2 ? CORESIGN(count_position[CORE_AXIS_1] - count_position[CORE_AXIS_2])
                          : count_position[CORE_AXIS_1] + count_position[CORE_AXIS_2]
    );
  #else // !COREXY && !COREXZ && !COREYZ
    endstops_trigsteps[axis] = count_position[axis];
  #endif // !COREXY && !COREXZ && !COREYZ
  kill_current_block();
}

For all purposes, I would just need the kill_current_block() function to stop movement of the moving E motor. Would that we correct?

**stepper.h**
    static inline void kill_current_block() {
      step_events_completed = current_block->step_event_count;
    }

Then we'd need is the "E endstop" to be a signal to call kill_current_block() to stop the E motor movement. The E axis is "homing" and upon the trigger of the endstop, the motor stops movement. I'd using be "manually homing" by sending one of the G0/1 E# commands.

[Bob-the-Kuhn]

Here's the link to rev C of the 1.1.x E endstop code.

There's several more changed files plus an example Configuration.h file.

I was able to test this code.

[Bob-the-Kuhn]

I just saw your latest post.

Yes, kill_current_block(); (or its equivalent) is what actually stops the stepper motor. I had that part correct but I didn't have the enables (#if statements) setup correctly.

[Bob-the-Kuhn]

I'd using be "manually homing" by sending one of the G0/1 E# commands.

After that issue a G92 E0 to set the E position to zero.

[kcheeeung]

Great! I've gotten it to work. Is it possible to use all 3 of the leftover XYZ MAX pins/ports to control the same E axis?

E axis is shared between the extruder motors, so I'll change it by using the T0, T1, T2. E_MIN_PIN is configured to a different pin than F_MIN_PIN. Different names/pins, but the results of stopping the E axis should be the same.

I'm not sure what else I might be missing because the testing using the F_MIN_PIN (endstop) didn't work, but E_MIN_PIN (endstop) did. When you have some time, please help me take a look.

In config, I added:

#define F_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define F_MAX_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.

I was trying to make a "2nd E min pin" (named F_MIN_PIN): E endstops e_min+f_min.zip

[Bob-the-Kuhn]

You want to stop the E axis when any of a list of pins goes active?

[Bob-the-Kuhn]

One way of using multiple sensors to make one pin go active is to "wire or" them and declare active as logic zero ( E_MIN_ENDSTOP_INVERTING set to false .

If the sensors are a mechanical switch then tie common to ground and tie all the normally open contacts to the E_MIN_PIN along with a pullup.

If the sensors are electronic then they'll need to be open collector or open drain.

The downside is this method can't tell the difference between the sensor not activated and the cable being broken/off.

If you want to keep E_MIN_ENDSTOP_INVERTING as true then we'll need to use one I/O pin per sensor and modify the code.

[kcheeeung]

Essentially yes. I'm trying to make the E axis work for a list of pins.

That's very smart. Using the "wire or" definitely works, and I have tried it out as your suggestions.

I'm trying to "hack" the board and make the most use of it by trying to utilizing all the free pins. I'd figured it might be a waste not to use them otherwise so I've looked at the code as well.

[kcheeeung]

@Bob-the-Kuhn thanks for the help thus far and throughout this year or so. I've been working on the code and got the individual I/O pins working with new modified code I added.

[Bob-the-Kuhn]

Good news!

[ReaganLawrence]

Hi there guys, I am quite interested in doing this on a Sanguino ATmega1284P, however it only has 1 endstop for x/y/z. I would like to use the x endstop as another z endstop. Will try and follow along to see if I can solve the problem myself but good chance I will need help. Cheers

[Bob-the-Kuhn]

You want one X endstop, one Y endstop and two Z endstops.

What does the second Z endstop do?

What are you using as the Z sensors?

[ReaganLawrence]

Thanks for the prompt reply! I'd like no X endstop, one Y endstop and two Z endstops. The Sanguino board only has 3 endstop options, unlike the RAMP which has 6.

The two Z endstops are max and min, currently have a Y min and Z min, would like to use the X endstop as a Z max.

Using microswitches as sensors.

[kcheeeung]

Oh I see, so is your board has X min, Y min, and Z min. What's the name of the board you have (in Marlin config)?

And what you want to do is turn the X min into a Z max?

[Bob-the-Kuhn]

In Configuration.h change the homing section to read:

//#define USE_XMIN_PLUG
#define USE_YMIN_PLUG
#define USE_ZMIN_PLUG
//#define USE_XMAX_PLUG
//#define USE_YMAX_PLUG
#define USE_ZMAX_PLUG

In pins_SANGUINOLOLU_11.h change the limit switch section to read:

//
// Limit Switches
//
//#define X_STOP_PIN         18
#define Y_STOP_PIN         19
//#define Z_STOP_PIN         20
#define Z_MIN_PIN          20
#define Z_MAX_PIN          18  // X_STOP_PIN is now used for Z_MAX

---

How are you planning to home your printer?

The only difference between an endstop input and any other input is the endstop has a 1K-10K pullup resistor on it. My suggestion is to grab an unused input for use as the Z_MAX endstop. You'll need to create a custom cable that has the pullup resistor built in.

Let's say that you use pin xx as the Z_MAX endstop. Here's the changes you'll need to make.

#define USE_XMIN_PLUG
#define USE_YMIN_PLUG
#define USE_ZMIN_PLUG
//#define USE_XMAX_PLUG
//#define USE_YMAX_PLUG
#define USE_ZMAX_PLUG

//
// Limit Switches
//
#define X_STOP_PIN         18
#define Y_STOP_PIN         19
//#define Z_STOP_PIN         20
#define Z_MIN_PIN          20
#define Z_MAX_PIN          xx  // should have a pullup to +5V

---

Very few people actually use both a Z_MIN and a Z_MAX endstop.

X, Y & Z are needed to home the printer. X_MAX & Y_MAX are used incase you're worried about a print going out of bounds. Z_MAX is rarely used.

Fairly soon you'll find out that your bed has enough ripple & tilt that getting good first layer adhesion on a large object is hard to do. The answer is to use one of the bed leveling systems but it's hard to get all the features you want plus bed leveling into the memory available in a 1284. Please consider using a 2560 based controller.

A 2560 + RAMPS + LCD display will cost you about $30 and should arrive in a week.

[ReaganLawrence]

The printer at the moment uses the Z axis for homing.

I have implemented the above code, then SanityCheck.h gave an error saying that XMIN_PLUG or XMAX_PLUG must be defined, so I just commented it as below out and it compiled.

Then using Pronterface I tested it out, and the Z axis will not move up at all, then I move it down, then it won't go up again. Here is the error:

[kcheeeung]

@ReaganLawrence
May I ask what is it you are concerned about? I think what Bob is asking is that he wants to know how exactly you are using it. His other suggestions is using another free pin on the board, which you can do as well.

Are you using it as a "normal" 3D printer?
Since you are not using the x_min endstop, how will you make sure the printer will know where the home (X0) position is?

Another suggestion is that if your concern is that your print might exceed the Z height, then look in configuration.h and edit your Z_MAX_POS to whatever height (in mm) you require. Most printers come with "maximum build dimensions" so that is something you usually take in consideration when you create a CAD.

// Travel limits (mm) after homing, corresponding to endstop positions.
#define X_MIN_POS -50
#define Y_MIN_POS -40
#define Z_MIN_POS 0
#define X_MAX_POS X_BED_SIZE
#define Y_MAX_POS Y_BED_SIZE
#define Z_MAX_POS 200]

[Bob-the-Kuhn]

You got rid of the sanity check for X. That makes sense for your system.

The Z movement problem you're seeing is because the Z_MAX endstop is always triggered. M119 will confirm that.

Either you have a wiring problem or the Z_MAX_ENDSTOP_INVERTING definition in Configuration.h needs to be flipped between true and false.

[ReaganLawrence]

Setting Z_MAX_ENDSTOP_INVERTING to false fixed it! Thanks for the help guys.

The printer is a DLP resin printer with the Z axis how the build plate moves, and the Y axis the projector movement. Currently X axis does nothing hence why I wanted to use the X endstop. The problem with just having a Z min was that people were going out the top and their machines and completely breaking them, hence the need for a Z max. We are implementing more features that will go on a secondary microcontroller so if a X endstop is ever needed (which it is with current R&D).

[Bob-the-Kuhn]

Don't go too cheap on your controller. It'll cause headaches down the road and is a very small part of the overall printer cost.

I suggest Atmel AVR2560 based boards as a starting point. They usually have all the I/O you'll need. A 2560 & a RAMPs board will costs about $20-$25.

If you need more computing power then consider LPC176x or Due based boards. Those will cost you in the $50 - $150 range.

If you're rolling your own controller then consider the LPC1778. Low cost, 32 bit, lots of I/O and with lots of compatible software already out there.

[ReaganLawrence]

Decided it would be best not to use the X endstop in case it is needed. Then tried connecting 2 microswitches in series and putting them both in the Z endstop, however the second microswitch acted as a min endstop (complete oversight).

Now trying to use the spare pins. Preferably don't want to use PWM, Tx or Rx, so that just leaves SCL and SDA. However I cannot find what pins these correspond to. Doing my research tells me SCL and SDA are 22 and 23 respectively, however this source has X/Y/Z endstop as 24, 25 and 26 respectively, yet the pins_SANGUINOLOLU_11.h had them as 18, 19, 20 so I don't think the source is reputable.

[kcheeeung]

Depending on how you configured the endstops, that should be expected. I believe even if you wired in parallel you would get the same result. (because you are still using the z_min).

Enable #define PINS_DEBUGGING in configuration_adv.h and run M43 on your printer host. You should see a list of all your pin configurations (PIN # = to whatever is assigned). Then, as for physically locating the pin itself, you will have to somehow look for a wiring/pin diagram of your board.

If you know what you're doing (not sure how safe this is, but this is what I do). You can manually "test" pins by using M42 and a voltmeter. Probe for pins with one end and another on the ground. M43 will also show you the state of each pin.

M42 P(pin_number) S255, which reads a HIGH signal
M42 P(pin_number) S0, which reads a LOW signal

[ReaganLawrence]

In parallel both switches needed to be triggered to stop the stepper i.e. series = or gate, parallel = and gate.

Will try that in the morning when I go in, but that seems to be exactly what I need, thanks!

[DerAndere1]

Hi, a feature to enable homing the 4th axis after homing XYZ would indeed be great.
@olhodneland, @mousey225 and others: I found the "e-stop" branch of @kcheeung 's Marlin fork at www.github.com: https://github.com/kcheeeung/Marlin/tree/e-endstop. It should be working as a good starting point according to the corresponding comment above by kcheeung from 27th Nov. 2017.

Keep everyone updated if you made progress, thx. For my liquid handling robot I will also need to repurpose the E axis and home it (use E-axis stepper motor for moving a syringe pump).

DerAndere

[mousey225]

@DerAndere1 Oh cool you are also making a Pipetbot! I ended up finishing mine in summer I would be happy to help you out with yours - I planned to put up the source files and marlin code on a website for public use but haven't got round to it yet due to being at university. I can send you it though if you like

[DerAndere1]

@mousey225 I would appreciate if I could have a look at your code. If it is acceptable that your code will be public, you may simply add a comment in the issue tracker of my repository "contact_DerAndere1" and attach your code using drag and drop.
If you don't have much experience with github and did not use version control software to adapt your Marlin firmware, you can still simply put your Marlin folder in a public repository at github.com (think of it as a dropbox on drugs):

1. left-click the + symbol in the menu at the top-right of the github.com homepage
2. left-click "New repository". Call it "Marlin1.1.y" or similar, and make sure "initialize with README" is selected. For any fork of Marlin, the license GNU General Public License v.3.0 has to be chosen.
3. After creation of the repository, left-click "Upload files".
4. Use drag & drop! to upload the contents (subfolders, original Marlin README, etc.) of your modified Marlin folder.

[DerAndere1]

The branch Marlin2ForPipetBot of my Marlin fork now allows a homing move for the XYZ and E axis using MIN-Endstops for each axis by issuing G-code G28 for cartesian setups.
However during development I boke the ability to do normal movement of the E-stepper when issuing "G1 E10" (even with cold extrusion). XYZ axes work as expected. Does someone see what code change prohibits G1 movement of the E-stepper? (Where is the difference between movement during homing and movement using G1?) The diff to original bugfix-Marlin2.0 is here. The Log file using DEBUG_LEVELING_FEATURE is: LOG.txt

;Test-Gccode Script: 
G91 ;relative
M302 S0 ;cold extrusion
M111 S32 ;debug
G28 ; home XYZE
G90 ;absolute
G1 X5 F300
G1 E10 F100
; end of g-code script

@Bob-the-Kuhn , @kcheeeung : Could you reopen this issue? The solutions publicly available seem to be incomplete or for old versions of Marlin.

[kcheeeung]

Hello friends. I will attempt to bring out my bare bones setup again to see what's going on. Admittedly, I couldn't fully get a complete solution previously, as there were some functionalities that were either "broken" or didn't work as anticipated. With more people interested, I think we can attempt to find a solution. @DerAndere1 and others who may still be interested.

Might be better to look at what @DerAndere1 has so far, as this has been a while back. I haven't kept up with the latest developments. I am also reviewing what I have in 1.1.x to see if there's some solutions.

[thinkyhead]

I can find no instance in Marlin (2.0) where it fetches or uses the E_AXIS element of homing_feedrate_mm_s or in a call to homing_feedrate. So that array can just contain X, Y, and Z.

[kcheeeung]

// #define EXTRUDE_MINTEMP 160
// #define PREVENT_LENGTHY_EXTRUDE
// #define EXTRUDE_MAXLENGTH 200

@DerAndere1 #8519 (comment) Maybe try this. I'm assuming that you might not need the hot-end and therefore need to disable it in configuration.h
Your G28 command is able to move the XYZE to the "home" positions? But when you try to move it forward through something like G1 E10, it doesn't work?

[DerAndere1]

Yey, My problem is fixed. I have a working proof of principle: For cartesian robots with four axes (one min endstop per axis, no z probe so far), the branch Marlin2forPipetBot of my Marlin 2.0 fork can home XYZ and also home the E axis with a simple G28. ENDSTOP_INTERRUPTS_FEATURE and SOFTWARE_ENDSTOPS for all those axes work, too. Thanks to @thinkyhead whose comment motivated me to go through the code some more times. And thanks to @kcheeeung who suggested to disable "Prevent lengthy extrude". During the next weeks I will try to put all changes inside #ifdefs so the functionality could be added to the original Marlin and only activated with some #define in configuration.h. For now I guess it makes sense to keep it as a seperate fork.
DerAndere

[DerAndere1]

I now have an e_homing branch which is ready for auto-merge with original bugfix-2.0.x, so I could create a pull request if desired. However I do not know how to deal with all the configuration.h files. Should I add the new options to all of them (but comment them out)?

Most changes are embedded in #if ENABLED(E_AXIS_HOMING) ... #else ... #endif blocks, so they are put into effect only when #define E_AXIS_HOMING is added to the file Configuration.h. A few sanity checks are added. Someone shoult test it with a normal 3d-printer while keeping E_AXIS_HOMING undefined.

[DerAndere1]

The approach discussed above is working well for me. More features can be made compatible with E_AXIS_HOMING in the future. However @thinkyhead pointed out that for introducing the functionality in original Marlin2.0, the concept of the "hangprinter" feature by @tobbelobb in Marlin 1.1.9 is better: Introducing optional additional axes (i called them AXIS_I, AXIS_J, AXIS_K) is a more flexible design (think 6 axis arms as 3d printer). I want to share my idea of introducing NON_E_AXES (the number of non-extruder axes that may benefit from endstops and homing) next to MOV_AXIS (the number of axes used for positioning / kinematics, <=NON_E_AXES). The remaining NON_E_AXES can be used for driving non-extruder tools such as strong grippers or pumps. Users/local devs would have to #define NON_E_AXES >= 3 and add pin definitions for the additional axes (for AXIS_I: define I_STEP_PIN, I_DIR_PIN, I_ENABLE_PIN and I_STOP_PIN (e.g. in pins/pins_MYBOARDS.h). Trying to implement it is early WIP, see this branch: at the moment, homing 4 axis does not work yet, only NON_E_AXES = 3 (XYZ) plus extruders. Otherwise, Smoothieware already supports > 3 axes + extruders as far as I have read.

[n9jcv]

DerAndere1,
I have a question in your comments you say the Emin homing will not work for Delta. Why is that?

I was looking at your changes at ;
bugfix-2.0.x...DerAndere1:e_homing

I have a delta and I want to be able to home an E axis, not for extruding. So would your changes work or is there something about deltas that would mean it will not work?

Thanks
Bruce

[DerAndere1]

@n9jcv Regarding #8519 (comment) :
Mainly because I did not (cannot) test on Delta. Possibly it is (almost) working as is. So far I really only looked at sections of code that apply to my setup with only basic features enabled (software endstops, endstop interrupts, babystepping, debug via M43/M111). Please submit an issue (feature request) for my fork over at https://github.com/DerAndere1/Marlin/issues and specify what features you really need (EEPROM? z-probe? what kind of bed leveling? Quick home? Any Display?) together with E homing or attach your configuration.h and configuration_adv.h files, so I can have a closer look if those settings are expected to interfere with the current implementation of E homing. In the same feature request also specify, which M-codes are most important to you, thanks.
IF you can code yourself, you may double check if the code does what you expect and then remove the relevant sanity check.
Soon I may try to change M114 so it also reports the E-axis position.

[boelle]

@kcheeeung

Please post your question either on discord: https://discord.gg/n5NJ59y or on facebook: https://www.facebook.com/groups/2080308602206119/
The issue list is for bugs and feature requests only
Please close this issue once you have posted it on one of the 2 links
Thanks :-D

[n9jcv]

Bo, I closed the 2 other issues.  This seems I can not close as I did not create.  There is no close button for me.  Sorry Bruce   Sent: Tuesday, February 19, 2019 at 4:54 PM From: "Bo Herrmannsen" <notifications@github.com> To: MarlinFirmware/Marlin <Marlin@noreply.github.com> Cc: n9jcv <n9jcv@mail.com>, Mention <mention@noreply.github.com> Subject: Re: [MarlinFirmware/Marlin] How to Re-Purpose XYZ (min/max) Endstops (#8519) @kcheeeung Please post your question either on discord: https://discord.gg/n5NJ59y or on facebook: https://www.facebook.com/groups/2080308602206119/ The issue list is for bugs and feature requests only Please close this issue once you have posted it on one of the 2 links Thanks :-D — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[boelle]

@n9jcv correct, only creator and @thinkyhead can close

[ersahozbahadir]

Here's the link to rev C of the 1.1.x E endstop code.

There's several more changed files plus an example Configuration.h file.

I was able to test this code.

Dear friend, I was searching about this issue and found your works here. But I couldn't download the files. Do you still have them?

[DerAndere1]

@ersahozbahadir you can try https://github.com/DerAndere1/Marlin/tree/2.0.x_E_homing if you like.

[ersahozbahadir]

@DerAndere1 Thank you for your reply, I’ve been trying to compile that and getting some errors like “E_MIN is not declared in this scope” at endstops.cpp . Also I tried your bf2_6axis_dev14 which gives error about “_TERN was not declared”. And I could not figure out what to change, where to start.Both E homing or non_e axis >3 Would really help but I couldn’t :(

I have mega2560 and ramps1.4 with 4 steppers, 4 min endstops.

[ersahozbahadir]

Hi @DerAndere1, just for info what I've done with bf2_6axis. I was very tired yesterday and today started from the beginning. the first error happened when I activated discounted full glcd. Then I found some missing "}" in menu_motion.cpp file. Then it worked for me. Now, when auto homing, X,Y works perfect but when Z starts, the printer halted error occurs. There must be some difference at pins. I'll check. Thanks much.

[DerAndere1]

@ersahozbahadir and other users: Each comment posted here takes away time from many people. Please do not discuss issues related to my code here. Instead, open new issue reports at https://github.com/DerAndere1/Marlin/issues. Most of the time those problems are related to existing issues listed at https://github.com/DerAndere1/Marlin/issues. My code can serve as a starting point for developers but is not production-ready as you have already noticed.

[github-actions]

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.