Read/act on limit switches

[GoogleCodeExporter]

I'm using the EBB to drive a laser cutter, with good success.  However, with 
this platform, the ability to use limit switches to find a "home" position 
would be particularly useful.  The laser cutter already has
the limit switches (actually optical sensors) that provide a signal
when the gantry has reached the minimum X and Y positions.  This is
also one of the possible "hacks" discussed on the EggBot wiki: 
http://wiki.evilmadscience.com/Hacks

There
would be several ways to attack this with the EBB, depending on how
automatic and configurable it's worth being.  The fanciest approach
would have a command to specify the X and Y limit switch I/O pins, logic levels,
and motor directions, and have a "home" command to run the steppers
until the limits were reached.  The most trivial one would have a
command to read a known I/O pin or two, and the host code could
alternate between small moves and running that command to find the
home position.

A logical compromise might be to have a command to run a single axis
until an I/O pin changed to a particular logic state.  The direction,
distance, speed, I/O pin, and logic state could be fixed or configurable.

Original issue reported on code.google.com by jreh...@gmail.com on 17 Feb 2011 at 7:09

[GoogleCodeExporter]

I meant for this to be an enhancement request, not a defect, but I don't know 
how to change it.

Original comment by jreh...@gmail.com on 17 Feb 2011 at 7:11

[GoogleCodeExporter]

Original comment by windell@oskay.net on 17 Feb 2011 at 7:47

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

My impression is that what you are asking for is already completely possible, 
at least in the "trivial" version that you describe.   If you can find a 
specific reason that this is NOT the case, please say so.

The EBB command set is essentially a superset of the UBW command set, so you 
can set up the board to read known I/O pins, and have the host execute minimal 
steps until the switch closes.   As you will want to travel *slowly* while 
seeking the home position, this is likely to be acceptably fast as a solution.  

See also:
http://www.schmalzhaus.com/EBB/EBBCommands.html
http://www.schmalzhaus.com/UBW/Doc/FirmwareDDocumentation_v145.html

It is possible that a "move until limit" command could be built into the 
firmware, but as you note, there are a lot of parameters to set, and the 
benefits would be (at best) an increase in speed.

Please indicate if you have specific reasons that the "trivial" solution is not 
an acceptable resolution.  Otherwise, I recommend that this issue is marked as 
closed.

Original comment by windell@oskay.net on 17 Feb 2011 at 8:01

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Slow speed of making a single step and testing switch status in a loop may be a 
showstopper for some applications, where you need to home the system after each 
cycle and there is a possibility of motor stall, therefore position information 
is lost.

Increasing the speed of homing by traveling more than one step at the time 
deceases the accuracy of found home position. Additionally, approaching the 
limit switch in start/stop mode adds a position noise due to system inertia, 
flexibility, preload and general slack.

Homing function is a standard feature of any industrial motion control system.

Original comment by pup...@gmail.com on 10 Jul 2011 at 8:43

[GoogleCodeExporter]

>Homing function is a standard feature of any industrial motion control system.

True.  But a motion control system typically consists of both hardware and 
software.   A straightforward software solution presently exists.

Since this issue was first opened, we have ourselves acquired a (rather large) 
CNC machine.  For zeroing, it first advances rather quickly towards the end 
with the limit switch.  It then backs up slightly from there and advances in 
microsteps until it reaches the limit switch.   This is a good solution. It 
solves the slow-speed "showstopper" problem as you describe it, and ensures 
that when you are doing the fine setting, there's no significant error due to 
inertia. 

I strongly disagree with your contention that advancing one microstep at a time 
*increases* noise due to inertia, flexibility, preload, or slack.  It should 
actually reduce error to a level significantly below what you can get by 
zeroing while under rapid motion.    The position is genuinely *known* at every 
microstep, with the highest resolution available to the system. 

If there is a compelling reason to add limit switch detection to the firmware, 
you're welcome to say what that is, or even to write and contribute the patch 
yourself.

Original comment by windell@oskay.net on 10 Jul 2011 at 9:39

[GoogleCodeExporter]

Closing due to a lack of activity and/or interest.

Original comment by windell@oskay.net on 30 May 2012 at 6:40

• Changed state: WontFix