Smoothieware not honoring min/max axes points?

[Morten Nielsen]

Hello all,

I come from Marlin where we have software endstops - which means it respects the limits of the axes defined, but Smoothieware is not honoring min/max axes points like that?

Printer Type:

Cartesian Ultimaker 2 clone

Setup:

I have MIN endstops/limitswitches, which I home to on XY and Homing to Z-max.

Issue:

After homing I can get the machiene to move in the minus direction, even though it IS reading as being on position 0 on XY.

My Z-axis is has Home on Z-max and the current position reads correctly. It faces same issues as X and Y just in reverse.

Machine gladly tries to move beyond the maximum x mm defined in config.

Tried:

Tried using the _limit_enable but that just results in the printer going into halt state when hitting a limit-switch, so not usefull

Please tell me it is my config and not "working as intended"

# ENDSTOPS
# Change pin to NC if Not Connected
# Add a ! to invert endstop output
endstops_enable                              true              # the endstop module is enabled by default and can be disabled here
# X
alpha_min_endstop                             1.24^   #
alpha_max_endstop                                 nc   # Default is 1.25^
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                                              214  # Default is 250 - this gets loaded after homing when home_to_max is set
# Y
beta_min_endstop                                    nc    # Default is 1.26^!
beta_max_endstop                               1.27^   #
beta_homing_direction            home_to_max  #
beta_min                                                      0   #
beta_max                                                 180   # Default is 250
# Z
gamma_min_endstop                                 nc   # Default is 1.28^!
gamma_max_endstop                            1.29^  #
gamma_homing_direction         home_to_max #
gamma_min                                                   0  #
gamma_max                                            193.5 #

[wolfmanjm]

soft endstops are NOT supported. However there are hard endstops that can be enabled in the config, check the wiki in the endstops section.

[Morten Nielsen]

I have read about every page on your wiki and everywhere else and have not found further information. Maybe you can provide a link?

When you say "hard endstops" you mean physical endstops?

Main problem is how the machine homes to the endstops and stops, but after that they do not honor the endstop position. I don't see how this is solved by adding mechanical MAX endstops?

I hope I just misunderstand something here, so home you can provide the link to wiki :)

Regards

[Morten Nielsen]

Just to clarify:

I seriously have read all the information on the smoothieware.org site. This includes but is obviously not limited to:

http://smoothieware.org/guide-endstops and http://smoothieware.org/endstops

Only thing I found that made the printer honor axis limts were _limit_enable (as I mentioned in OP) but that makes the printer go into HALT state and is not really usefull.

Just to prevent we do not talk past each other:

In my World limit-switches and Endstops are the same. Same goes for hard endstops and when I said Soft-endstops I really just meant the MAX and MIN distances of any axis in the Config.txt. Ie: printer accepting the software/config limits configured.

[Peter McCracken]

This has been going on for years... unfortunately one of the key developers appears to have "issues" so don't expect implementation any time soon, see below. There are other examples of similar discussions with the same person if you google some more...

https://github.com/Smoothieware/Smoothieware/issues/461

[Morten Nielsen]

Wow, that's just awfull.

The ability to specify size of machine is extremely usefull. In fact, I see it as a critical safety measure!

If Smoothieware at least honored the endstops and didn't try to move past those, we could make use of 6 endstops (total overkill), but that is not possible  now - unless you enable the HALT thing when endstop is hit - that Means powering off and on everytime, meaning it is not going to happen. Ever.

Or is my settings just wrong/have I misunderstood something in the configuration?

Why even spcify size of axes if the machine does not use it?

I can see wolfmanjm does not see the need behind this by skimming the thread on Github. It's been a while since that thread, so maybe some enlightenment has happened?

1) Lets just say: everyone else wants it, so that might be a huge pointer towards what's going on.

2) When homing to Z-max and you jog the bed back manually it is all too easy to accidentially SLAM the bed into the hotend when Smoothieware does not honor the coordinates.

3) When Building machines and doing lots of Work on them all the time, which LOTS of people do, it is imperative you do not accidentially make the motors try to go past the physical max posibile...

No,I'm not being negative.. I'm just giving usefull constructive pointers and inputs from an Expert 3D builder and user, but new to Smoothieware.

[Peter McCracken]

I would have to agree with you this is an inherently useful feature and should be implemented, however I wouldn't expect any sort of "enlightenment" to occur anytime soon.

On the upside as this is open source we do have full access to the source code and I have been looking into adding some functionality I need with respect to the BLTouch, it should be fairly trivial to add in support for software endstops as well...

[DrRon]

How do you configure endstops for downward travel on a Delta ?

If all three towers go down together,endstops could prevent table impact.

However if I send it to X0 Y200 Z0 I will have one tower go way below that point, in relation to the other two towers ?

So far with the machines I built, I have not needed or wanted endstops at the table, or at the towers preventing the downward movement of my printhead.

Once I properly configured my Home endstops (at the top of my delta) and got everything set, I have never hit the table , or felt like I was going to

I do not wish to enter into a criticizing argument, nor spend days uselessly discussing something that is fully opinionated, I am simply curious about the point you would set endstops to on a delta ?

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

[John Gelnaw]

My delta doesn't like moving down unless it's already homed-- The behavior originally requested by whosawhatsis in the smoothieware thread.

Once the delta is homed, it (theoretically) knows where "0" is, and won't move below that (firmware "soft" limit, which isn't a software endstop so much as it is the printer refusing to move outside of "sane" coordinates).  

People who've manually calibrated delta printers know, however, if your delta is miscalibrated, and you send G1 Z0 F5000, it's possible you're in for a spectacular head crash.

To make things more confusing, for auto-probing, deltas have X/Y/Z max endstops (which are columns A/B/C, and have no relation to XYZ axes), and a Z-Min endstop (which is the actual Z-axis).

As you point out, the A/B/C column position will vary depending on the X / Y / 0 location, so hardware endstops aren't really practical except for the Z-probe endstop.

As someone who manually calibrates their delta printer, the fact that smoothie ignores the Z=0 plane as a boundary means it's slightly easier to calibrate the XYZ offsets (well, ABC-- or perhaps Z1/Z2/Z3?), but it also makes head crashes on a calibrated delta possible, so I'm not sure the trade-off is worth it.

[David Crocker]

On a delta you don't set individual limits on the towers, but most other firmwares do allow you to set a lower limit for the allowable nozzle Z value, such as 0.0 or -0.5mm. Having a lower limit can be a nuisance when doing manual calibration, so it can be useful to temporarily disable the limit e.g. using M564.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[DrRon]

Thank You , good answers :-)   Have a good one !

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Arthur Wolf]

Hey.

unfortunately one of the key developers appears to have "issues"

As far as I know he just doesn't want to spend his free time working on it.
And finds the implementation is not as simple a thing to do as one might expect ( which I agree with ).

That's not really "issues" ... unless I'm missing something.

None of us is entitled to anybody else's free time ...

The ability to specify size of machine is extremely usefull. In fact, I see it as a critical safety measure!

 

If safety is the real issue, you definitely want limit switches, which we do support.

If the issue is "convenience", then yes you probably want soft endstops.

Why even spcify size of axes when Smoothieware does not use it?

Because you can choose to home to min or home to max ( home to max being the standard on deltas ), and because soft endstops is a planned feature.

I can see wolfmanjm does not understand/see the need behind this by skimming the thread on Github

I don't believe you are reading the thread correctly. He's explained his position on this several times already.

Implementing soft endstops *in a clean way*, is not a trivial thing. He does not need it so he won't spend time on figuring it out.

If anybody wants to work on implementing soft endstops, I will put a lot of effort into helping them as much as possible.

And wolfmanjm will help by reviewing their code when pull request time comes, and making sure it's up to Smoothie's standard, and won't break anything.

it should be fairly trivial to add in support for software endstops as well...

I believe you are incorrect there.

If this was a trivial matter, it'd have been done a long time ago.

There is a reason why it isn't.

But you can prove me wrong anytime with a pull request !

Cheers !

Courage et bonne humeur.

[Morten Nielsen]

* None of us is entitled to anybody else's free time ... (and issues)

I actually thought it was a Commercial product which someone did for a living - that said, I did not demand anything of anyones time, I merely asked if I had 1) malconfigured something, or 2) it was working as intended. If 2 why?

Maybe people just would like a clear answer like: I don't have time/dont want to do it? :)

* if safety is the real issue, you definitely want limit switches, which we do support.

Problem is that smoothieware does NOT stop at limitswitches unless I have setup the function where the machine goes into HALT mode (or what you call it), and forces us to turn it off/on before contining..

- main safety issues are really for lots of configuring and setting up, Building, reparing machines.. it is critical the machine respects the defined axes without going into HALT mode or the need of switches.

- Many setups run entirely without endstops.. where you manually set it to HOME/ORIGIN... none of those system could use Smoothieware as is...

* If the issue is "convenience", then yes you probably want soft endstops.

It's not convenience.. but I guess it just underlines how the "cons" can't see the need.
Convenience and importance here can be debated, but I'm glad soft-endstops are planned :)

* I can see wolfmanjm does not understand/see the need behind this by skimming the thread on Github

* I don't believe you are reading the thread correctly. He's explained his position on this several times already.

* Implementing soft endstops *in a clean way*, is not a trivial thing. He does not need it so he won't spend time on figuring it out.

- I might not have read it correctly. I DID say I "skimmed" it. The Things I read he just seemed very baffled by the very need/wish to have this function :)

- The "He does not need it, so he..." that is really the BIG problem with many Projects.. many Projects doesn't cater to the majority and Thus never get full viability among the masses... even though it might be a spare-time proejct (I did not know this) there is a lot of Money and time put into it, so doing as much as possible to ensure continued success should matter. Even if the developer/s doesn't use the features themselves (I know they listen to people's wishes for the board)

- I know you said it was free time, but I'm working at automating systems .. systems being usefull for the masses have a much higher successrate in the long run, than systems being limited to only the most technical minded people.

Summed up

The lack of this feature just stunned me.. it's been in Marlin for, I don't know how long, and just naturally expected it to be in Smoothieware.

Lots of people and 2 shops are waiting for inputs regarding the Smoothie-system, but it's hard to endorse without basic functions like this!

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Arthur Wolf]

Hey.

On Tue, May 3, 2016 at 7:23 AM, Morten Nielsen <mort...@gmail.com> wrote:

* None of us is entitled to anybody else's free time ... (and issues)

I actually thought it was a Commercial product which someone did for a living -

Smoothieboard is sold as a commercial product.

Smoothieware is free.

Both are mainly designed and maintained by a community of volunteers, and are fully Open-Source.

A part of the money from board sales does go to paying my salary ( as well as Logxen's for US's sales ), and we both happen to also be contributors to the project.

And part of that money goes to sending free boards to contributors, paying contributors for specific features, paying for proto runs of new hardware etc.

But that doesn't mean that buying a board or using the firmware entitles anybody to specific features being implemented, that's not how this works.

This is an Open-Source project, if you want to be entitled to things, don't hesitate to go buy something from Samsung instead.

( note : board sales do entitle you to customer support, warranty etc. I'm not denying that, and we are actually exceptionally good at that part ).

 

Maybe people just would like a clear answer like: I don't have time/dont want to do it? :)

It's not just lack of time or not wanting to do it. It's more complicated than you expect to do *right*, is the main issue.

Wolfmanjm has a very long track record of implementing things all by himself, including things he doesn't personally need.
He'd very likely have done this by now if it were as simple as you expect.

 

* if safety is the real issue, you definitely want limit switches, which we do support.

Problem is that smoothieware does NOT stop at limitswitches unless I have setup the function where the machine goes into HALT mode (or what you call it), and forces us to turn it off/on before contining..

You don't need to reset your board, just send M999.
 

- main safety issues are really for lots of configuring and setting up, Building, reparing machines.. it is critical the machine respects the defined axes without going into HALT mode or the need of switches.

- Many setups run entirely without endstops.. where you manually set it to HOME/ORIGIN... none of those system could use Smoothieware as is...

I've actually run a system like that for a long time without any trouble, so you are definitely wrong on the "none of" part of your statement.

Soft endstops is actually a feature we get asked for very rarely, surprisingly.

As far as I know, some host software actually makes sure not to send offending commands, so that may be part of why people don't even realize we don't have that feature.

* I can see wolfmanjm does not understand/see the need behind this by skimming the thread on Github

* I don't believe you are reading the thread correctly. He's explained his position on this several times already.

* Implementing soft endstops *in a clean way*, is not a trivial thing. He does not need it so he won't spend time on figuring it out.

- I might not have read it correctly. I DID say I "skimmed" it. The Things I read he just seemed very baffled by the very need/wish to have this function :)

- The "He does not need it, so he..." that is really the BIG problem with many Projects.. many Projects doesn't cater to the majority and Thus never get full viability among the masses...

Yeah if you knew anything about Smoothie you wouldn't be thinking that's what's going on.

What's actually happening here is wolfmanjm gave the Smoothie project a very high quality requirement for new features/code.

That, combined with the fact that soft endstops are more complicated to implement than folks expect, and the fact that Smoothie supports many different situations ( arm solutions, modules etc ), results in soft endstops being hard to implement *right*

That's the story here, not "main contributor is grumpy".

Smoothieware does cater to the majority, even more than other projects, that was in from the start, but with time we learned that having a high requirement for code quality is even more important in the long term if we want to get anywhere.

There has actually been two separate contributors that tried their hand at implementing this and gave up.

If somebody wants to try, I will help them as much as I possibly can.

Cheers.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[DrRon]

I am glad I am not the person that answers all of the things that are posted on the smoothie boards, I would end up ripping people so often that business would suffer.

I admire the patience you guys have often displayed when people get overly demanding or critical of the efforts.

I am also amazed at the number of people that I have seen attempting to over engineer things for reasons I do not always understand.

I have gotten so tired of some of the back and forth about certain subjects that I have to stop reading for a couple of days until it passes. :-)

I for one appreciate and admire the work the contributors put into this, and realize that they could walk away at anytime, but do not.

I also think a heck of a lot of people that post could use a bit more respect and common courtesy when asking for and receiving free advice, consultations, code reviews and all of the other things that require a persons time, and that time never comes back, you used his minutes on this planet, you should be forever grateful for that.

nuff said

[Morten Nielsen]

Seriously.. I never ever demanded anything. Neither did anyone else here.

I politely ASKED wheter I had setup something wrong or if it was working as intended.

I then tried to explain why I thought it of paramount importance.

A HUGE problem is when some people, developers included, totally downplay the genuine need by the people making suggestions instead of recognizing it.. In this particular case the soft-endstops seems to be planned.. just say so and cut the argumentations short...

Observating and understanding the consumer masses is my main talent.. this is where I spend my time... and this my way of contributing. Don't anyone for a second doubt the effor I, and a lot of other non-developers, spend trying to help this and many other Open-source Projects.

Just often seems like the hands-on developers (for many open-source proejcts and not pointed strictly at Smoothieware) has a huge stick up the arse and take every single input as personal affront.

I take it the actual programmers like and feel something for Smoothieware, or they wouldn't spend so much time on it. (emotionally and/or economically)

I and other people are making constructive helpfull suggestions and in order to further the goal of Smoothieboard AND Smoothieware, it should be common sense to listen to what the masses want and need.

Just tired of having to defend myself and being subject to derogatery comments every single time I dare stick my nose in the open-source community.

Hey.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[DrRon]

I was not implying that you did anything. I was commending the smoothie folks. This is why I shouldn't comment. My apologies if you took me as anything but complimentary. Every time I speak, flames seem to erupt. bye bye, I have been silenced.

Hey.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

[Arthur Wolf]

On Tue, May 3, 2016 at 2:25 PM, Morten Nielsen <mort...@gmail.com> wrote:

Seriously.. I never ever demanded anything. Neither did anyone else here.

That ( the rant about entitlement ) was not an answer to you, but to Peter's comment.

Sorry if I mixed folks up, hard to keep track sometimes.
 

I politely ASKED wheter I had setup something wrong or if it was working as intended.

I then tried to explain why I thought it of paramount importance.

A HUGE problem is when some people, developers included, totally downplay the genuine need by the people making suggestions instead of recognizing it.. In this particular case the soft-endstops seems to be planned.. just say so and cut the argumentations short...

Observating and understanding the consumer masses is my main talent.. this is where I spend my time... and this my way of contributing. Don't anyone for a second doubt the effor I, and a lot of other non-developers, spend trying to help this and many other Open-source Projects.

Just often seems like the hands-on developers (for many open-source proejcts and not pointed strictly at Smoothieware) has a huge stick up the arse and take every single input as personal affront.

Or maybe you are not so bad, but there are other folks that are real bad, and you are paying for those ...
http://opensoul.org/99ways/#1

I take it the actual programmers like and feel something for Smoothieware, or they wouldn't spend so much time on it. (emotionally and/or economically)

I and other people are making constructive helpfull suggestions and in order to further the goal of Smoothieboard AND Smoothieware, it should be common sense to listen to what the masses want and need.

We do. I assure you we do.
 

Hey.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[John Gelnaw]

So what is considered the "right way"?

Personally, unless you're intent on making soft endstops a standalone module, I would think it would go into the motion planner, specifically, the sanity checking routine-- any generated coordinates should be sanity checked, and if "volume limits" (which seems like a better term than "soft endstops") is enabled, then the motion planner isn't allowed to generate coordinates less than zero, or greater than the max value for each axis.

Now, what to do with bad coordinates is another issue-- do you ignore moves that generate coordinates outside the limits?  Do you move to the limit and stop?  That's pretty easy for Cartesian, but more complicated for Delta (but only slightly, if you assume a cylinder of constant diameter).

It still only seems like about 30 lines of code to me (I'd truncate all moves at the boundary, and drop any move that existed completely outside the boundary).

[Peter McCracken]

Hi Arthur,

I don't want to continue to perpetuate the arguments around this but I don't think any of my statements point to a sense of entitlement, let me be very clear that I am under no illusion that I am entitled to demand any particular piece of functionality in a product. What I may have implied is a certain amount of cynicism for the stance of a specific contributor on this issue, if you have comments implying that he does not want to implement it because he personally has no need for it, then one would have to question their specific reason / goals for contributing to the project.

It's all about perspective as well, at the end of the day Smoothieboard IS a commercial product and without Smoothieware it will have limited usefulness, moreover without any sort of firmware sales of the board would also be fairly limited. In that sense owners and users of Smoothieboard should be listened to and certainly taken seriously, ergo the inclusion of "soft endstop" functionality should not be contingent upon the specific viewpoint of an individual contributor. Whilst known demand for this specific feature may be deemed to be low this is certainly not the first time this topic has been raised, at a minimum there are a handful of Smoothieboard users who would welcome this feature and it is certainly something that should be included on the release roadmap. On that specific point is there an updated release roadmap available anywhere, I can only find one from 2014.

The previous response from John Gelnaw seems very constructive, I will certainly invest time to look at what changes would be required in the code and see if a viable solution is possible.

Best regards, Peter.

Hey.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

This message was written with recycled letters.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Morten Nielsen]

Seems my simple question took off in an unwanted direction!

 

Whilst known demand for this specific feature may be deemed to be low this is certainly not the first time this topic has been raised, at a minimum there are a handful of Smoothieboard users who would welcome this feature

This is the exact reason why developers should listen to people more in touch with end-consumers and non-prousers... Seems like the DEVs (and other hardcore users) talk a lot to each other and not so much the broader (larger) (potential) userbase.

I know a couple of hundred people in my user Groups WHO are dependant upon this very feature. Same goes for the Temperature switch which was expected to be direct replacement for Marlins Automatic fan control for Hotend and Controller cooling (it's not atm, but listed to be fixed).

They do not come in here and ask about the features, which is the reason why you do not see a lot of demand for them.

Many of said users sit and await my initial leap into Smoothieware (firmware) as the hardware part is very, very interesting, but people are worrying about new firmware.

The average user do not seperate the Hardware and firmware part.. Hardware is very nice but it is rather worthless without a good firmware to take advantage of it.

If Smoothieware had more of the common features it would be seen as a much more viable path for both new users and users wishing to move beyond 8bit controllers or controllers using marlin ports.

Sure, these might not be essential to the DEVs or other hardcore technical people, but regular people depends on these features for every day use and light DIY. These people make up a potential very large Customer base.

I'm still baffled by the attitude of DEVs and similar minded when input is given... I've taken part in many semiars etc with Microsoft and other large firms... I've not ever seen a DEV behaving like he/she is given a personal critisim when a constructive input (or even a critcal one) to the project the person is working on.

Same goes for lots of people jumping in and start "defending" the DEVs... it's totally inappropriate. Just leads to arguments instead of a constructive dialogue.

I personally feel like people have a right to expect certain features when buying a Premium priced Smoothieboard. I don't care if the Smoothieware part is open-source and not a direct Financial part of it.. but maybe it should be.

[Arthur Wolf]

On Wed, May 4, 2016 at 10:48 AM, Morten Nielsen <mort...@gmail.com> wrote:

 

Whilst known demand for this specific feature may be deemed to be low this is certainly not the first time this topic has been raised, at a minimum there are a handful of Smoothieboard users who would welcome this feature

This is the exact reason why developers should listen to people more in touch with end-consumers and non-prousers... Seems like the DEVs (and other hardcore users) talk a lot to each other and not so much the broader (larger) (potential) userbase.

I think you are misunderstanding what is going on here.

The conversation about soft endstops has already been had long before you brought it up, both with the community, and amongst the firmware devs.

Nobody is being ignored, and it is a planned feature. I'm not sure what more we can do here ...

I also think you are completely misrepresenting our reaction here, by saying in essence " I just gave input, and the devs misbehaved ".

Input is extremely welcome, you can go through years of mailing list, github and IRC log and see that has always been the case.

But sometimes the *way* that input is given can ruffle feathers.

That's what was wrong here and what caused a reaction.

I personally feel like people have a right to expect certain features when buying a Premium priced Smoothieboard. 

 

Then you do not understand what the Smoothieboard and the Smoothie project are. I will buy your board back from you if you want.

And I'd love for you to name a single other open-source cnc controller board for which you have the same expectation ... once we have a name we'll go ask the project's maintainers, and I'm pretty sure they'll be saying the exact same thing I am ( note : I'm saying this in confidence because it actually happened before ).

Also, Smoothieboard is absolutely not Premium-priced.

Let me finish by repeating : if anybody is interested in implementing this, I will gladly help them as much as I can.

[Arthur Wolf]

On Tue, May 3, 2016 at 3:38 PM, John Gelnaw <jge...@gmail.com> wrote:

So what is considered the "right way"?

Personally, unless you're intent on making soft endstops a standalone module, I would think it would go into the motion planner, specifically, the sanity checking routine-- any generated coordinates should be sanity checked, and if "volume limits" (which seems like a better term than "soft endstops") is enabled, then the motion planner isn't allowed to generate coordinates less than zero, or greater than the max value for each axis.

Now, what to do with bad coordinates is another issue-- do you ignore moves that generate coordinates outside the limits?  Do you move to the limit and stop?  That's pretty easy for Cartesian, but more complicated for Delta (but only slightly, if you assume a cylinder of constant diameter).

You have a pretty good idea of what's going on, yes.

One other basic problem is : are we printing or not ?

If you are just jogging, it's likely fine to just "truncate" moves that go outside the bounds.

But if you are printing/cutting, then it can be dangerous to automatically truncate anything that goes outside the bounds. You most likely want to HALT instead.

So you need to act differently depending on if the user is jogging, or if a print is going on, but we have no way to know which one is the case at any given moment.

On deltas, a cylidner is not really the size of the print bed, but I guess it could be used as a "good enough" approximation. An additional difficulty on deltas, is that you don't want to constrain just on the effector, but also on the actuators on the linear rails.

There is also the problem of G92, and the WCS, where we need to make sure we keep track of where we are relative to the homed position, and not of the user-defined zero position. I'm not sure what the current state of the WCS is, maybe it'd just work out of the box, but that's something that needs to be checked.

There are some other gotchas, but those are those I remember off the top of my head.

It still only seems like about 30 lines of code to me (I'd truncate all moves at the boundary, and drop any move that existed completely outside the boundary).

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter McCracken]

Arthur,

Is there a published roadmap for planned features or has that not been formalized at this time ?

Best regards, Peter.

 

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Arthur Wolf]

I don't believe there is a published list.

Right now, the main features planned/being worked on for v1 are :

* 7th-order/S-curve/time-based acceleration and planning ( which Jim is currently working on )

* Increased thermistor safety with new detection methods ( which is slowly progressing with several folks looking into it )

* Soft endstops ( which nobody is working on right now, but several folks tried before )

* New SD card driver with DMA and CRC ( which Adam Green is working on )

* New spindle control methods ( Bouni working on that, though it's in a pause now )

* Move delta grid to cartesian ( I think that's been done, but is maybe not as tested as it could be )

Aside from that, there is a lot of working going on on v2 ( both firmware and board )

Cheers.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[David Crocker]

One other basic problem is : are we printing or not ?

If you are just jogging, it's likely fine to just "truncate" moves that go outside the bounds.

But if you are printing/cutting, then it can be dangerous to automatically truncate anything that goes outside the bounds. You most likely want to HALT instead.

Not necessarily. I have sliced models where the model itself fits on the bed, but the skirt doesn't if I use my normal skirt separation difference. I could have re-sliced the model using a smaller skirt separation distance. But it was easier to use my normal slicing parameters, and rely on the soft motion limits to prevent the head moving outside the safe area while printing the skirt.

[Dev Doc]

I take it this feature has not been released as of yet?  I hate to have this as my first conversation in the group but I just drove myself nuts wondering why the firmware wouldn't stop at the endstop when jogging.  What I was doing was simply testing out a new build and wups grrrrrind.  I guess I just expected it as I havent used a firmware that didnt include this such as Marlin, Sailfish,  Repetier etc.  I thought it was kind of a standard thing,  but after reading this I am guessing Smoothieware is really more catered to Deltas and whatnot.  I purchased the board because I saw it as a tremendous leap forward for controllers and heard that the firmware was fantastic.  Its kind of a blind leap when you can only use one.  In any event excellent job with the flashing,  initial configuration,  and most everything else I have used thus far.  Again,  I will just need to change my mindset and be more mindful of what I am doing or simply auto home I suppose..  

[Arthur Wolf]

The thing is with all the super features we have added to Smoothie ( *many* of which other firmwares don't have ), and with the stellar code structure and quality, it makes it very difficult to do "soft endstops" *right* ( understand if Smoothie was more "basic" like the other firmwares it'd be easy and we'd have it already, but because Smoothie is *much* more complex and well designed, it makes this particular feature very difficult to implement correctly, and we only implement things if we can implement them correctly ).

We will end up doing it, but it's going to be a lot of work.

In the meantime, if you add physical endstops, Smoothie knows to stop at those. They are very cheap and not too difficult to install.

Documentation on hard endstops : smoothieware.org/endstops

A bit of background : https://docs.google.com/document/d/1U6nzx1boqF-J2GGPWF4yIaaVib0JNodVWSKBfwiyp_M/edit#heading=h.79oxultkpcgc

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Larry Ciscon]

So I don't mean to get into the middle of this religious argument, but I did have one question/thought:

I could be wrong on this, but I'm assuming what makes this difficult to implement is that the soft endstop check has to be called inside the robot code.  But given the way the code is set up the endstop module is a plug-in tool and not part of the robot.  So the endstop code can't get access to the right information to do the check at the right time without fundamentally breaking the modularity.  

But why could you add a softendstop_solutions interface just like you have an arm_solutions interface and use this to call a single routine at the right point(s) of the robot code to do a soft limit check?  Then the Endstops module could install a solution to this interface to execute just this one (very minimal) procedure.  The test parameters for the routine are static so this should be thread-safe.  And this should not impact the real-time behavior.  Finally this doesn't seem (on the surface) to break the modularity you've put in place.

If this approach makes sense I might be willing to draft the change for review.

Just one idea....

[Arthur Wolf]

On Sun, Mar 5, 2017 at 5:32 PM, Larry Ciscon <lci...@gmail.com> wrote:

So I don't mean to get into the middle of this religious argument, but I did have one question/thought:

I could be wrong on this, but I'm assuming what makes this difficult to implement is that the soft endstop check has to be called inside the robot code.  But given the way the code is set up the endstop module is a plug-in tool and not part of the robot.  

No that's not it. This sort of problem we know how to solve pretty easily, we do for other things already.

The problems have to do with knowing where a command is coming from ( user, file, host software ), and whether we are currently printing, or jogging, etc.

Smoothie is currently unaware of this, and to implement soft endstops correctly, it would have to learn to be aware of all this, which is much more difficult than it seems.
 

So the endstop code can't get access to the right information to do the check at the right time without fundamentally breaking the modularity.  

But why could you add a softendstop_solutions interface just like you have an arm_solutions interface and use this to call a single routine at the right point(s) of the robot code to do a soft limit check?  Then the Endstops module could install a solution to this interface to execute just this one (very minimal) procedure.  The test parameters for the routine are static so this should be thread-safe.  And this should not impact the real-time behavior.  Finally this doesn't seem (on the surface) to break the modularity you've put in place.

If this approach makes sense I might be willing to draft the change for review.

Just one idea....

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Larry Ciscon]

Ah ok.  Makes sense.

On Monday, March 6, 2017 at 4:18:09 AM UTC-6, Arthur Wolf wrote:

On Sun, Mar 5, 2017 at 5:32 PM, Larry Ciscon <lci...@gmail.com> wrote:

So I don't mean to get into the middle of this religious argument, but I did have one question/thought:

I could be wrong on this, but I'm assuming what makes this difficult to implement is that the soft endstop check has to be called inside the robot code.  But given the way the code is set up the endstop module is a plug-in tool and not part of the robot.  

No that's not it. This sort of problem we know how to solve pretty easily, we do for other things already.

The problems have to do with knowing where a command is coming from ( user, file, host software ), and whether we are currently printing, or jogging, etc.

Smoothie is currently unaware of this, and to implement soft endstops correctly, it would have to learn to be aware of all this, which is much more difficult than it seems.
 

So the endstop code can't get access to the right information to do the check at the right time without fundamentally breaking the modularity.  

But why could you add a softendstop_solutions interface just like you have an arm_solutions interface and use this to call a single routine at the right point(s) of the robot code to do a soft limit check?  Then the Endstops module could install a solution to this interface to execute just this one (very minimal) procedure.  The test parameters for the routine are static so this should be thread-safe.  And this should not impact the real-time behavior.  Finally this doesn't seem (on the surface) to break the modularity you've put in place.

If this approach makes sense I might be willing to draft the change for review.

Just one idea....

--