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

Created on 22 Nov 2017  Â·  72Comments  Â·  Source: MarlinFirmware/Marlin

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.
untitled

Most helpful comment

Hey Gizmo6, check this out. I have also tested (the E_MIN_PIN) on my own system as well to make sure it works, and it does.
https://drive.google.com/drive/folders/1Gx6dZbY0tmwlZpTs4cCw9eQ199yqr_2p?usp=sharing

Based on the latest Marlin 1.1.x, can just move these files into your own folder. I'm not sure if making a tutorial would be that helpful because there's a lot of things to add and might be confusing to those who aren't familiar with the Marlin firmware itself.

Configuring: configuration.h

Depending on your endstop configuration set inverting to false/true.

False will be setup as COM to ground and NC to signal.

Configuring: pins_RAMPS.h

I have setup these files in a way that your Y_MAX_PIN and Z_MAX_PIN PORTS are the new X_MIN_PIN. The Y/Z_MAX_PIN was just moved to pin 2 to serve as a dummy. You can also remove or comment it, but you'll need to do the testing on that.

You can also change it to E/F_MAX_PIN instead, but this will change the way you write the g-code.

//
// Limit Switches
//
#define X_MIN_PIN           3
#ifndef X_MAX_PIN
  #define X_MAX_PIN         2
#endif
#define Y_MIN_PIN          14
#define Y_MAX_PIN           2//15
#define Z_MIN_PIN          18
#define Z_MAX_PIN           2//19

#define E_MIN_PIN          15// Uses the Y_MAX_PIN PORT
#define F_MIN_PIN          19// Uses the Z_MAX_PIN PORT

Homing your "additional" axes

These "axes" we created actually have a "shared instance" in that they all use the "E axis." Even if you change the "T0/T1 axis" the E position is actually still saved so you have to use G92 to set the position in order move the amount you intend. Earlier I have mentioned that whether you choose min or max as the pins you define will change the way you write the g-code. There isn't a direct way to use the G28 to "home" the new axes. We will just need to be clever in the way you write it.

Assume we use the MIN configuration (the axis position will move from LARGE to SMALL). The sequence you write will be:

T0; this selects the T0 stepper
G92 E999; set the axis to position E999
G1 E0; move to position E0
**(as it's moving, you will hit your endstop)**
**(motor stops)**
G92 E0; set the axis to position E0, your home.
**commands to move T0 however you want**

Let me know how it goes. And a lot of credits to Bob as well in helping me out originally.

All 72 comments

Is this for 1.1.x or 2.0.x?

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.

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

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.

I have not been able to test the changes.

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

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?

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.

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.

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.

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

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

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

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

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.

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.

@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.

Good news!

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

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?

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.

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?

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.

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.

image

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:

image

@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]

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.

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).

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.

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.

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

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!

Works perfectly! Thank you so much for your help guys.

Hi kcheeeung. I'm fascinated by this post of yours. I have been trying to achieve the same thing for a while now. But being completely new to 3D printing and coding in general this has been a massive undertaking for me. After reading all the comments from the yourself and the other posters I gather you were in the same position as me but with the help of everyone you have managed to get this to work.
Unfortunately whilst I understand you got it to work. Would you be so kind in explaining in detail what to edit in the marlin code to get the this additional functionality? I would like to add 2 additional axis using T1 and T0 steppers. If you could write a guide to doing this I'm sure it would help out a lot of people. Thanks a lot.

Hello @Gizmo6. I can very well help show you what files to change, but it might be helpful to describe what you would like to achieve with these additional "axes" so we can understand what works best. (in what application?)

Hi Kcheeeung, Thanks very much for replying! Ok the best way to describe my custom machine is it's very similar the types of vending machines you find with the XY axis product picking arm. (Not the ones with coils) only in my machine I also use the T0 and T1 as axis's in order to push the product out to a buyer and to push a new product forward into the old ones space. I am running a Ramps 1.4 board with all the endstop MIN ports taken to be used for the standard XYZ. What I would like to do is have the T0 and T1 behave in the same way as as their XYZ counterparts. I have no heating elements in my machine so all the hot end and hot bed settings have been disabled. (Using the dummy temp settings) My machine is currently working (using hand typed G-code scripts) but the T0 and T1 is simply just counting steps backwards and forwards this means my machine, over time or error loses its T0 and T1 home position ( I need to manually position :( ) What I would like to achieve is for example to be able to use G28T0 and G28T1 to home the additional axis's before the machine starts so it can be aware and adjust its original position. All my endstop MAX are free.

I am running a configured version of Marlin 1.1 for my distinct needs.

From reading your OP it sounds like it's very similiar to what you were trying to achieve and managed it. Any help would be greatly appreciated.

Like yourself I was just looking through the endstop.ccp but as I have no coding experience this is beyond my ability.

Any help at all would be fantastic! I've searched this topic so much and so many people asked the question but you are the first I have come across that seems to have managed it. I look forward to any advance you can give me :) (in the form of a tutorial would be best if its not too much to ask)

Thanks a lot.

Hi Kcheeeung, Not sure if you have had time to take a look at my provided information yet. But any help would be appreciated. Thanks.

@Gizmo6 Sorry for the delay. I was a bit busy, but I will have something for you soon. (Some things have changed in the code so I need to see what's different)

It sounds like is that:
You will need 2 endstops because there are two motors (one pushing in and one pushing out). I will be using the latest Marlin 1.1.x file as the base file.

Thats great. yes I already have it all at hand and so whenever you are ready that would be great. Thanks a lot.

Hey Gizmo6, check this out. I have also tested (the E_MIN_PIN) on my own system as well to make sure it works, and it does.
https://drive.google.com/drive/folders/1Gx6dZbY0tmwlZpTs4cCw9eQ199yqr_2p?usp=sharing

Based on the latest Marlin 1.1.x, can just move these files into your own folder. I'm not sure if making a tutorial would be that helpful because there's a lot of things to add and might be confusing to those who aren't familiar with the Marlin firmware itself.

Configuring: configuration.h

Depending on your endstop configuration set inverting to false/true.

False will be setup as COM to ground and NC to signal.

Configuring: pins_RAMPS.h

I have setup these files in a way that your Y_MAX_PIN and Z_MAX_PIN PORTS are the new X_MIN_PIN. The Y/Z_MAX_PIN was just moved to pin 2 to serve as a dummy. You can also remove or comment it, but you'll need to do the testing on that.

You can also change it to E/F_MAX_PIN instead, but this will change the way you write the g-code.

//
// Limit Switches
//
#define X_MIN_PIN           3
#ifndef X_MAX_PIN
  #define X_MAX_PIN         2
#endif
#define Y_MIN_PIN          14
#define Y_MAX_PIN           2//15
#define Z_MIN_PIN          18
#define Z_MAX_PIN           2//19

#define E_MIN_PIN          15// Uses the Y_MAX_PIN PORT
#define F_MIN_PIN          19// Uses the Z_MAX_PIN PORT

Homing your "additional" axes

These "axes" we created actually have a "shared instance" in that they all use the "E axis." Even if you change the "T0/T1 axis" the E position is actually still saved so you have to use G92 to set the position in order move the amount you intend. Earlier I have mentioned that whether you choose min or max as the pins you define will change the way you write the g-code. There isn't a direct way to use the G28 to "home" the new axes. We will just need to be clever in the way you write it.

Assume we use the MIN configuration (the axis position will move from LARGE to SMALL). The sequence you write will be:

T0; this selects the T0 stepper
G92 E999; set the axis to position E999
G1 E0; move to position E0
**(as it's moving, you will hit your endstop)**
**(motor stops)**
G92 E0; set the axis to position E0, your home.
**commands to move T0 however you want**

Let me know how it goes. And a lot of credits to Bob as well in helping me out originally.

Hi kcheeeung, THANKS A LOT FOR THIS!!! I will have a play with this set up and come back to you. Even though its not a tutorial it's very well laid out and I very much appreciate your efforts :) Thanks again.

Hi Kcheeeung. Thanks a lot for this. However it won't compile for me. Please see the error message.

**Arduino: 1.8.2 (Windows 10), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"
sketch\stepper.cpp: In static member function 'static void Stepper::isr()':
stepper.cpp:433: error: 'class Planner' has no member named 'discard_continued_block'
               if (!planner.discard_continued_block())   // Discard next CONTINUED block

                    ^
exit status 1
'class Planner' has no member named 'discard_continued_block'

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.**

As I didn't understand what you had changed i'm not sure where to go from here. I have attached my working version of marlin, Maybe if you have some time you could check the issue?

The attachment is my own configurations without your additional files.

Marlin-1.1.x - TFT SCREEN UPDATE - CURRENTLY WORKING - Copy.zip

I know I'm asking a lot but if you have some time its much appreciated.

Check the google drive link again. I have updated to use your version of the Marlin. Copy/paste the files into your folder now. The guide is still the same. I was able to compile it, but haven't tested it. It's very likely that it should work.

The compile error came from the difference between versions, specifically the latest 1.1.8, and the developers have changed some features/code since then. The first edits I have done are specific to 1.1.8 and usually "mixing and matching" files across versions don't work.

To easily see the difference between the edited files, if you have git (do a git diff) or just use an online diff checker.

Hi kcheeeung,

Thank you very much you have been extremely helpful. I managed to get it working as in the endstop will stop the motor movement but what I cannot do it to get the endstops be separate controllers. No matter how I change the settings they all behave as one. Is there a way I can use one as a MAX and one as a MIN? I understand that the E will be seen by the system as a single unit but what I would like to do is to see if I can have them engaged separately. So I can position it in a way where for example a MAX could stop T1 and the MIN could stop T0. If you have explained it already above I do apologies for my noob questions. I really do appreciate your help so far.

Three backticks ``` for multi-line comments. Please read the link:

image

Hi kcheeeung,

Thanks a lot for your help. I just wanted to update you on my findings. Firstly thanks a lot for your assistance. I never did get the switches to behave properly as a max and a min. Both switches operate as one no matter what configurations I set. This is not a huge problem as I have written the G-code so that the T0 spin until it hits the endstop then backs away. This leaves the firmware to believe the endstop open which allows for T1 to trigger its endstop. (By moving the away from the endstop it resets it for the next) it works GREAT. ....

BUT it only works when the rest of the axis (ZXY) have not been homed yet. Once they have been homed the T0 and T1 Endstops no longer works and I'm back to square one. I could get around this by doing the T0/T1 homing first before homing the rest, but currently I need to reset the system before the T0/T1 endstops work again.

Do you have any ideas on how to address this?

Marlin-1.1.x - CURRENTLY WORKING E-Endstop compiled with issues.zip

@Gizmo6 You just have to change the word from MINto MAX in RAMPs.h (the code that is already written in). Axis position moves from SMALL to LARGE with a max configuration.

pins_RAMPs.h

// Two slashes comments a line of code out in C/C++

#define E_MIN_PIN           0 // You have E_MIN enabled.
//#define E_MAX_PIN         0 // See the "//" in the front. The E_MAX is disabled because it's commented out.
//#define F_MIN_PIN         0 // Disabled.
#define F_MAX_PIN           0 // You have F_MAX enabled.

Thanks for pointing out and confirmed you findings. Homing the XYZ first will render the "E axes" unable to home with the E_MIN/MAX_PINS. On a fresh reset, homing the "E axes" is possible. I haven't tested in extensively as I'm using a minimal test board.

My knowledge might be limited in terms of the Marlin firmware, but I will attempt to understand and find a fix or new implementation for this endstop/E axis that can be used in conjunction with the XYZ axes. It would be more functional with the ability to properly home XYZ, then the E axes or even make it behave like a XYZ does when it homes.

@kcheeeung Thanks a lot. For your reply. Just wanted to let you know your input has been much appreciated. :) please update me if you manage to find anything.

@kcheeeung Hi, Did you ever manage to find a solution to the E Axis issue? I would be curious to know. :)

@Gizmo6 Sorry for the long delay. I was trying to see what I could do on the 1.1.x, but I don't think I quite got it unfortunately.

Hey guys. What do you guys think in terms of making the E_AXIS behave like the XYZ in terms of homing? In the previous method, we found that the e_min/max_pin would outright not work anymore if XYZ is homed first.

What I was thinking was to follow the X_AXIS codes in its homing ability (via G28) and copy/add some of that over to the E_AXIS, responding to the e_min/max_pin. I was able to get the file to compile, but on testing, the E_AXIS motor just stutters. Is there a better solution and I must have missed a place or improperly edited some of the code?

Hey guys. What do you guys think in terms of making the E_AXIS behave like the XYZ in terms of homing? In the previous method, we found that the e_min/max_pin would outright not work anymore if XYZ is homed first.

I think I would like this. As part of my ending GCode in Slic3r, I have it retract 5mm or 10mm of filament. Assuming the nozzle is hot, I think I would like to see it prime the nozzle. But that is a big departure from what has been done in the past and would need some discussion.

Hey @kcheeeung, seems like a good idea. One quick thing, I too am stuck on this issue as I am working on a project that requires 4/5 axes with end stop capabilities. I just wanted to ask if you had a download of the required files to implement this? All the links posted previously on this thread seem to be broken.

Thanks for any help!

@Roxy-3D And yea, it would be very cool if you could enable a feature that would allow you to home both of the extruder axes, it would open up a whole new set of possibilities beyond just 3D printing too

How can i find the modified marlin code for an extra axis with endstop? The link to rev.C did not work. @Bob-the-Kuhn

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

@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

@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.

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.

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.

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.

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

@DerAndere1 https://github.com/MarlinFirmware/Marlin/issues/8519#issuecomment-456045063 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?

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

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.

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.

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 ;
https://github.com/MarlinFirmware/Marlin/compare/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

@n9jcv Regarding https://github.com/MarlinFirmware/Marlin/issues/8519#issuecomment-464561867 :
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.

@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

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.

@n9jcv correct, only creator and @thinkyhead can close

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?

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

@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.

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.

@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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

StefanBruens picture StefanBruens  Â·  4Comments

modem7 picture modem7  Â·  3Comments

jerryerry picture jerryerry  Â·  4Comments

Matts-Hub picture Matts-Hub  Â·  3Comments

Kaibob2 picture Kaibob2  Â·  4Comments