Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add endstop for trigger home position #81

Closed
slimline33 opened this issue Aug 30, 2016 · 10 comments
Closed

Add endstop for trigger home position #81

slimline33 opened this issue Aug 30, 2016 · 10 comments

Comments

@slimline33
Copy link

slimline33 commented Aug 30, 2016

endstop

Hi techninja,

is it possible to add a endstop for cnc machine? or some code to trigger it? I think it's usefull also for robopaint, because I can add there also a #improvement

I already ask brian at schmalzhaus for trigger one or two i/o...

Greetings Christoph

@oskay
Copy link
Collaborator

oskay commented Aug 30, 2016

Do you mean limit switches? The EBB does support digital inputs, but cncserver does not presently (so far as I know) have an API function that can query them.

@techninja
Copy link
Owner

Yup, CNCServer currently has no endstop trigger support. Stepper support works by internally assuming relative positions to extrapolate absolutes. Seeing as CNCServer has been built around only machines without these thus far, there's no real concept of it. It likely could be added around the existing API, but it couldn't be supported directly unless we had a specific machine in mind. Taking feedback from serial controller queries is extremely limited in current configurations and likely should be improved, but haven't had the need yet.

@oskay
Copy link
Collaborator

oskay commented Aug 30, 2016

I would say that it would be plausible to add a specific command that would query the state of a digital input, using the EBB (UBW) "I" command.

@techninja
Copy link
Owner

A "query" API endpoint seems very reasonable, though a little slow for what would be needed here. A "seek to home" command basically needs to check this after every movement step. I'm going to take a wild guess and say that @EmbeddedMan probably has some kind of firmware update that handles this use case a bit cleaner.

@oskay
Copy link
Collaborator

oskay commented Aug 31, 2016

It is not currently implemented in the firmware, although we are discussing some changes for a major firmware update in the near future. This would be a good one to put on the list--

Move in direction (x,y) until input (z) changes state?

@EmbeddedMan
Copy link

Yes, doing it in the firmware as a a single command is the only good way to
do it.

Would you really want to move both axis at once until a single input is
tripped?

It seems like it would be easier to do one axis at a time. There also needs
to be a timeout so that if the specified input doesn't change state in that
time an error is returned.

We may also want to have a speed in steps/s that you can optionally specify
for the command, so you could easily implement the "home fast, come off the
switch, then home slowly until the switch just trips" thing that a lot of
CNC machines do.

*Brian

On Tue, Aug 30, 2016 at 9:55 PM, Windell Oskay notifications@github.com
wrote:

It is not currently implemented in the firmware, although we are
discussing some changes for a major firmware update in the near future.
This would be a good one to put on the list--

Move in direction (x,y) until input (z) changes state?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#81 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAbeCLNtWOAo1ZsFBeHjXuuC05SsYZ31ks5qlO06gaJpZM4JwkVv
.

@oskay
Copy link
Collaborator

oskay commented Aug 31, 2016

If it can be specified in an arbitrary direction, then it allows for checking in XY or AB geometry, as well as upper and lower limits, without considering each case in particular.

As far as timeouts go... perhaps it would be best to implement this as an "SM" type command, but with an extra parameter indicates the digital input that will be monitored. That way, it would have a built-in timeout (and speed)-- if no limit is detected, it halts at the end of its given travel.

@EmbeddedMan
Copy link

Windell - yeah, I really like that idea a lot. A modified version of an SM
command, so you get a move duration, a number of steps, and you could move
both motors at the same time if you wanted to. In fact, what we could have
is a new command called "EL" (Enable Limits). It would take four
parameters. Axis1 limit switch port, Axis1 limit switch bit, Axis2 limit
switch port, Axis2 limit switch bit. Once you send that command, the next
SM command you send would check, in between each step, to see if the
specified ports and pins changed state. If so, that axis would stop moving.
After the SM command is done, you could send EL,X or something like that to
turn that mode off (or maybe it would automatically turn off after the SM
command is complete.) So the EL command puts the EBB into this 'use limits'
state, for just one SM command.

That actually doesn't sound very hard to implement in the firmware
actually. Just a few more instructions on each step.

*Brian

On Tue, Aug 30, 2016 at 10:13 PM, Windell Oskay notifications@github.com
wrote:

If it can be specified in an arbitrary direction, then it allows for
checking in XY or AB geometry, as well as upper and lower limits, without
considering each case in particular.

As far as timeouts go... perhaps it would be best to implement this as an
"SM" type command, but with an extra parameter indicates the digital input
that will be monitored. That way, it would have a built-in timeout-- if no
limit is detected, it halts at the end of its given travel.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#81 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAbeCLcBX80VVkbHpvXluH4jXZPFqHWWks5qlPFvgaJpZM4JwkVv
.

@oskay
Copy link
Collaborator

oskay commented Aug 31, 2016

Let's move the discussion about firmware implementations to the appropriate place: evil-mad/EggBot#58

For the moment, back to the original question: perhaps we should add an API endpoint for digital input queries?

@slimline33
Copy link
Author

nice to see there is a future plan 💃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants