I just set up a MKS SBase 1.2 I have everything figured except for two things. I have searched and read lots of posts but nothing fixed the issue.
First, my endstops are supposed to be working properly (checked with M119), but when homing one of the axis’ (random) will just keep going and crashing into the endstop. To test, I have pressed one of the endstops with a finger and have moved the connected axis (in both directions) without the endstop stopping movement. TO further test, I tried ALL of the motor axis and they all move when holding the same endstop, so its not just that I have them crossed. I have edited the config and tried with and with out the ! on the axis’. If I enable the 3 “limit switches” lines, the printer does stop when the switch is hit, but then I have to reset. If I disable the 3 “limit switches” lines, it goes back to not stopping when the switch is hit. These are mechanical Makerbot 1.2 endstop switches.
The other question I have is how to use the E1 driver to drive my second Z motor on my Prusa i3. Will it burn up the driver if I connect both motors to the same driver? I would like to have them separate for auto level but I may try to join them on the same driver.
My config can be found here: pastebin.com / zJZ4SLBx
Endstops
endstops_enable true # the endstop module is enabled by default and can be disabled here #corexy_homing false # set to true if homing on a hbit or corexy
alpha_min_endstop 1.24^ # add a ! to invert if endstop is NO connected to ground
alpha_max_endstop nc # NOTE set to nc if this is not installed
alpha_homing_direction home_to_min # or set to home_to_max and set alpha_max
alpha_min 0 # this gets loaded after homing when home_to_min is set
alpha_max 200 # this gets loaded after homing when home_to_max is set
beta_min_endstop nc #
beta_max_endstop 1.27^ #
beta_homing_direction home_to_max #
beta_min 0 #
beta_max 200 #
gamma_min_endstop 1.28^ #
gamma_max_endstop nc #
gamma_homing_direction home_to_min #
gamma_min 0 #
gamma_max 200 #
optional order in which axis will home, default is they all home at the same time,
if this is set it will force each axis to home one at a time in the specified order
#homing_order XYZ # x axis followed by y then z last
optional enable limit switches, actions will stop if any enabled limit switch is triggered
alpha_limit_enable false # set to true to enable X min and max limit switches
beta_limit_enable false # set to true to enable Y min and max limit switches
gamma_limit_enable false # set to true to enable Z min and max limit switches
Because this is a MKS board and not a community-supported board, you want to contact your seller before trying to get help from the community.
If the seller is unable to help you, feel free to ask again here.
All of my attempts to contact any support have ended up with nonsensical responses in broken English that did not address the issue I am having. A friend sent this board to me, I thought it was going to be a real SmoothieBoard until i took a look at it. If I get this figured out, I am going to buy a board from you guys to put in my k40 laser.
In reading posts on the forum about endstops, it looks like endstops on Smoothie may not work the way I expect them too. The post copied below says the end stops only work for homing. Is this true? I need the endstops for homing AND to let the board know when it has reached the start of the axis, and that the other end is 200 mm in the other direction(software endstop).
Below is a link to a video I shot testing all of the axis’ against one of the endstops. The endstop did not stop any movement in any direction. This was without ANY USB plugged in and using the touch screen to move.
youtube . com / watch?v=r8IndlYyA_0 (remove spaces)
***
Re: (Kossel) Alpha axis crashes into end stop AFTER successful homing
tailgunner30uktailgunner30uk 12 Aug 2014, 12:50
Glad to hear that things are moving along.
As supplied, the endstops are only configured as home switches, in effect, once triggered, you can manually step, or drive the head past them. If you configure them as limit switches then you cannot step past them once triggered. A caveat, you can resume the program (play), however the carriage that triggered the limit, will continue on through the limit switch, also, all endstops will be disabled at this point, until the printer is reset. If you enable an axis with limit switches, you also need to ensure that the axis-minimum is set to NC to avoid a false trigger of the limit as the carriage is backed off the switch.
We do not have software endstops, we are working on implementing those ( it’s more complicated than you’d expect, it’s the only major feature we are still missing ).
Endstops are used only for homing, and for limit switches, at the moment.
Does that answer your question, or was there more to it ?
About drivers. You can connect two motors to a single driver, that’s no problem, it’s how most people do it on i3-type machines.
Bonjour à tous,
Si je puis me permettre d’après votre fichier config vous n’avez pas de butées beta mini donc pour la prise d’origine je pense que cela doit poser un problème pour le réference de vos déplacements, je dis peut être une co…….! bon courage
So to make it clear: Smoothieware does not support software endstops aka. a logical comparison agains a stored min and max value (set on homing) which prevents the machine over- and under-running its axis dimensions? Really? This is sad… and dangerous for the mechanical integrity of a machine… This should be implemented asap!!!
A second issue I have, is that after homing (which works fine) the config flag “move_to_origin_after_home” is ignored / not executed. Having my beta-endstop at the max position of my Y-axis I would love to see the bed moving to its logical origin.
Yes, this is not supported. It’s something that is being actively worked on. The thing is : it’s much more difficult to implement than it seems ( or it’d be in already ).
In the meantime, if your machine is capable of harming itself, please install min and max endstops and enable limit_switches.
move_to_origin_after_home worked last time I tried it ( and it was with a beta axis homing to max too ). Are you using the latest firmware ? Is the line uncommented ?
I wanted to get a status on the progress in the area of the endstop functionality. Have you implemented the functionality you referred to earlier in this tread?
Have you been able to implement endstops similar to the way they work in Marlin? I found the way the limit switches are implemented (machine full stop) to be overly dramatic for my use case. As said before, I need the endstops for homing AND to let the board know when it has reached the start of the axis, and that the other end is 200 mm in the other direction without coming to a full stop because the end stop was hit.
I have had my 5x board for a while now because everything can make it blow up and I didn’t feel there is enough information to get it right. I finally said screw it, if I break it I break it! (though I really want it to work on my i3 prusa homemade clone)
As expected things go wrong. I have endstops that I bought from makerbot because they have “protection” and let me know when they are triggered. They are not configured just like the smoothie wiki because they are NO when plugged in… That’s when I add the “!” invert and M119.(I do not understand all the terms.) I clicked the z-axis movement in Pronterface many times to get it to the endstop and my machine runs the y axis into the bed nonstop until it ripped the couplings off the z motors. In Pronterface I couldn’t find a stop machine from killing itself button. I did end up disconnecting which stopped the motors but when I reconnected it started up anew.
So from this conversation, I am understanding that only Homing works?
If I would have homed the Z axis instead of clicking it many times it would have stopped my machine?
Or I can enable limit switches which pause the machine… sure it paused which is good but the machine is useless at this point until I turn everything off and back on.
How do others use this correctly?
I feel that the machine has a nebulous idea of where the machine is at. I home it and it finds a corner… then in the config file I say it is 200mm from the home position. If I am wrong then the machine tries to make it to 200mm by brute force! Or if I click the move motor buttons pronterface will move it to whatever I want regardless of a switch.
I think I had the wrong idea of what an endstop did as well.
Same problem here for me as @Dytoractor, I have 6 Normally Open (NO) endstops (one at min and max of each axis), configured with “!” in order to be inverted.
Homing functions works correctly, BUT, after homed (all home_to_min, so min_endstops are triggered), if I ask the printer to go further backwards … it tries to go further even with the endstop triggerred (which, for me, is a complete NONSENSE! ) … worse for max_endstops : even triggered, it tries to go further, hitting the max_endstop does NOT even stop the movement, and does NOT protect the printer.
I have took a look to the limit_enable thing => it is clearly too drastic ! halting the entire printer is not what I want : I just want the axis to stop at hardware endstop and do not go further on the endstop direction if triggered …
I may understand that software endstop are not yet implemented, BUT, AT LEAST, is it possible to have hardware endstops working correctly ?
May be there is an explanation for this behaviour, I would be glad to know it, could someone explain that ?
Thanks a lot.
PS: @Dytoractor : did you found a way to avoid this ?
Thanks for replying, but, like I already said on my last message :
“I have took a look to the limit_enable thing => it is clearly too drastic ! halting the entire printer is not what I want : I just want the axis to stop at hardware endstop and do not go further on the endstop direction if triggered …”
Following your own link :
"A reset will be required to continue, or sending M999, make sure you move away from the endstop though before trying to move. "
This, is clearly too drastic, so useless in my case …
EDIT:
Please can someone confirm : to resume, on smoothieware, hardware endstops only work for homing action, or as a kill switch.
If yes, why is it not simply and clearly written like that on the documentations ?
The hard endstop result in a halt state yes, which then requires M999 to get out of.
However, you can use the soft endstops feature ( with the halt option disabled ) to tell the machine to stop when it’s at the end of the axes ( so you can set it up so it stops right before the endstop ).
Soft endstops is in a separate branch for now because it’s not documented yet, but we expect it’ll get integrated very soon ( we looked at it just a few days ago again )
Still not a complete and straight answer, but, we can deduce the following :
to resume, FOR NOW on smoothieware, hardware endstops only work for homing action, or as a kill switch.
Since this project is not new (smoothie is around for about 4/5 years now), why is it not simply stated like this on the documentation ?
I’ve chosen this solution for building my first 32bit printer because of the features it has, BUT, if I knew that from the beginning, I may not have done that choice. All primary/basic features are already handled by 8bit arch 3d printer controllers, I was search for some new features and enhancements (SD card config, network, speed …), but not in sacrifice of primary/basics ones.
By reading the documentation, we can deduce that software end-stops are not implemented (by soft end-stops, I mean what any other 3d printer architecture means : limiting max distances), BUT, hardware end-stops (limiting movement by hardware eg. with mechanical or optical end-stops) is mandatory while building printers.
Please, update your documentations, state the things has they are not has they will in a potential future, and don’t leave misunderstandings on it. it will only lead people to feel fooled once those kind of troubles are discovered.
Well I’m sorry I do my best to make my answers complete and straight. If you don’t find them to be don’t hesitate to ask further questions.
I want to insist that « hardware endstops only work for homing action, or as a kill switch. » is incorrect.
You can have “hitting end of axes causes the movement to be ignored”, which is what you asked for ( correct me if I misunderstood ).
The way this is done is by homing the machine so it knows where it is. Then the machine is able to ignore moves that would go out of the machine area. This is functionally identical to “hitting the actual endstop stops the axis”.
@Ulysse31 I’m confused about what you are trying to achieve and would really like to understand the rationale behind your request?! I worked on number of big professional cnc machines and when you issue a move that goes outside of the workspace every single one of them will halt and turn on the warning light?! What else would you expect machine to do if your code try to operate outside of machine range (hence the code is obviously generated wrongly).
What would you expect on a mill or a fdm printer to do for a move that goes outside of the workspace?
It’s me again, was away for a long time … my projects were on stanby for some problems I had …
Anyway, I’m trying to get it working again, and since you say that it works (“which Smoothie can do.”), I would be glad to know what I need to enable/activate to do so.
Because, for now, after homing all the axis (which it does correctly, stoping once hitting mins endstops), if I say to smoothie to go backwards on any axis (which obviously physically cannot do since it is on the endstop min) it still force like a dull, by the way eating my belts on the motors pulley teethes … same for max endstop.
Could you please explain what I should do ?
@arhi: what I want ? it is simple => a 3d printer behaviour (not cnc) => on any axis, when you hit an endstop in min you can not go any further backwards, but you can still operate and go forwards. when you hit an endstop in max, you cannot go any further forwards, but you can still operate and go backwards. this is 3d printer hardware protection basics. Implemented in many other firmware like marlin or teacup …
UPDATE: HURRAY !!! Documentation has been updated since the end of February !! I’ll download the latest edge firmware and configure the soft endstops as documented ^^ !! This is great, following what is written on the documentation, it seems to do exactly the expected behaviour I was talking about !
UPDATE2: lol … looking to the revisions for the endstop page documentation is … hilarious … modifying it and adding soft endstops, and simply replying here “which Smoothie can do.” without any “Hey we added the feature”, or “hey we updated the documentation” … no simply a “smoothie can do” … that’s not really a honest behaviour …
So I’m not honest now ? Most additions to the wiki are related to requests by users, every time I see something that isn’t documented and that is talked about in a forum/mailinglist/G+ etc, I try to add it to the documentation. No dishonesty there, just a lot of hard volunteer work. You’ve been very agressive towards people who are giving you their free time as a present, I can’t understand it, and I think you need to read : http://smoothieware.org/troubleshooting#i-m-very-upset-at-something-everyone-is-mean-and-nobody-listens-to-me
