Dual endstops for X and Y

I've seen reference to using dual endstops to drive each Z motor (on separate drivers of course) to their own endstop, to level out a long axis.


On an MPCNC (popular CNC project using RAMPS), I'm running X and Y with second motors on E0 and E1 using FEATURE_TWO_XSTEPPER and FEATURE_TWO_YSTEPPER, works great and happy to see this in the FW, looked for it in vain on Marlin (or at least not done as simply).

Is there a way to use 2 X and Y endstops like the Z to square off the unit? On longer runs it's not uncommon to see the carriages at each end find their way to being up to a couple centimeters out of alignment after some usage.

Comments

  • Posts: 0
    No, there is no option for dual xy endstops. Z was only added since same stuff can happen if you have separate rods for z axis, which is quite common for 3d printers (prusa style).


  • edited April 20 Posts: 7
    Would I be able to easily adapt the Z code for X and Y, and if so, what would you quickly suggest I look at to get that done?  I took a dev fork to look at but haven't gotten dirty yet, thought maybe there was already a built in option that wasn't documented.
  • Posts: 7
    I'm going through and doing the XY versions to see if it's as trivial as it looks given the existing MULTI_ZENDSTOP_HOMING code I see there already.  

    I'll post back if I have any questions.
  • Posts: 0
    Mainly you add more dnstops in configuration and endstop class in printer.h/cpp and copy everything as you plan where MULTI_ZENDSTOP_HOMING  is used. The trick is simply in homing to stop only motor that is triggered and stop complete move if all endstops are triggered. Normal print does not use dual endstops.
  • Posts: 7
    Well, I had that code copypasta worked up in a couple hours and then rigged my extra endstops yesterday morning.  But I'm not getting what looks like independent sled motion and I'm really not sure why.  

    I've added a Pull Request if you get some time to look at it and see what mistake I've made here.  I've stared at it and obviously I'm not understanding something about the Z2 method.  

    I also don't quite see what the EXTENDED_ENDSTOPS and accumulator2 do in there, maybe that's where I'm going wrong.
  • Posts: 0
    EXTENDED_ENDSTOPS is just because endstops is a 8 bit field with 1bit per endstop. First covers 8 so has the most widely used. If you need new bits e.g. for X2/Y2 you have to store them in second endstop flag byte.

    If you look into printer.h you see the IDs how second x and y endstops are already defined for the extended endstop byte:

    #define ENDSTOP_X2_MIN_ID 1
    #define ENDSTOP_X2_MAX_ID 2
    #define ENDSTOP_Y2_MIN_ID 4
    #define ENDSTOP_Y2_MAX_ID 8
    #define ENDSTOP_Z2_MAX_ID 16
    #define ENDSTOP_Z3_MIN_ID 32
    #define ENDSTOP_Z3_MAX_ID 64

    so please use these in lastRead2, they are only missing in update function for endstops. Please also use both directions separately as planned.

    And one last wish so I can merge pull requests - please do not try to push your personal configuration.h version. After pulling it will be new default and that makes no sense. Just copy original before committing, also it might be already to late for this if git does not see it, but we will see.

    Except this I think it looks good.
  • edited April 23 Posts: 7
    I wondered about those defined stops, I couldn't find any places they were used but I didn't want to step on your toes if you had plans for them other than this particular purpose.  Seems like this is the purpose you had in mind.  Like an idiot, I didn't track down the size of the variable, I just figured most compilers will choke and throw an error if they don't like the attempt to stuff something too big into it, but since it didn't, I figured I was good to go.  I guess it just ignores it quietly since it doesn't know how much you're going to try to put into it at compile time.

    As for the config, I pushed it just so you had a reference, I did see your request to the last pull request about that, but since I knew this wasn't being merged, I thought I'd include it just in case I'd messed something else up endstop related.  Not quite sure how to remove it at this point from the request, I'm a complete noob at github, but I'll see what I can do, other than starting a new request.

    I'll see where EXTENDED_ENDSTOPS and swapping those IDs takes me then.  Thanks for the guidance.
  • edited April 25 Posts: 7
    OK, I've done another pull request with my somewhat working changes to the dual endstop code.

    As noted in the PR, Y is working properly, but for the life of me I can't see why X does not.  If I swap pins so the axis are swapped in firmware, the problem just follows the X axis, so it does not seem to be a hardware issue as I don't change anything on the board.  I must be missing something in X that I have in Y, but I've looked at all of the inserts several times and can't see any differences.

    Also, I've done all the dev in the first byte laststate, not laststate2, because I see the ENDSTOP_Z2_MINMAX_ID done there as well and I figured to reduce the potential troubleshooting, I'd stick with a known working byte.  Consequently I moved the X and Y MAX to EXTENDED_ENDSTOPS since they wouldn't be used anyway.

    I was also mystified what in my coding was causing it to act as if there were software min endstops acting on all axis, as Z will not go negative at all (since there's no endstop to home) and X and Y won't go back past where they were initialized as well, though it allowed me to home.  I pulled a clean copy of Dev and loaded up a config from a working Master, and it still acts like there are software endstops in force.  I have no clue why this is and couldn't trace the issue.

    I feel really close, but can't figure out these issues, so if you have a chance to check that PR again and make some suggestions about why X won't work but Y does, and why there is this software min going on even on a clean copy, it would be great to get some guidance on that so I can wrap this up and maybe try a couple of other additions.
  • Posts: 7
    I pushed the commits to that PR, if you get a chance let me know what you think, but at this point I'm pretty perplexed why it isn't working on X but works on Y.

    I might try coding it on the Master branch as a test because there's some behaviour in the Dev branch that seems related enough to potentially be an issue.
  • Posts: 0
    Please read github comment on this.
Sign In or Register to comment.