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

Working Limits... #63

Closed
1bigpig opened this Issue Feb 15, 2012 · 43 comments

Comments

Projects
None yet
10 participants
@1bigpig
Copy link

commented Feb 15, 2012

I have what appears to be grbl with working limit switches on my cnc router. This code has an alpha version of my debounce routine . I plan to do some extensive physical testing, but so far it seems to work. It is the Master .7d branch with the only changed files being the limit.c. Available on my fork.

Bruce

@chamnit

This comment has been minimized.

Copy link
Member

commented Feb 15, 2012

Thanks Bruce! The code looks solid, and I'll try to give a go of it this weekend. Hopefully soon after I work out the XON/XOFF flow contol.

@1bigpig

This comment has been minimized.

Copy link
Author

commented Feb 15, 2012

I went back and did just a minor bit of code beautification. I plan on extensively testing the homing and debounce routines today.

I can't wait for the XON/XOFF flow control!!!

chamnit: Do you want me to do a limits.c for version .8? I think there were a few minor code changes to make it work with your edge version, but I wanted to start with the master version first.

@chamnit

This comment has been minimized.

Copy link
Member

commented Feb 16, 2012

Sounds good. I'd rather not have to change the master version unless it has something to do with a bug fix. So, if you can, please make an edge version, so I can integrate it in officially. I've been thinking that there have been so many changes already with v0.8, that I may soon close development on it and move on to v0.9. Not sure when that will be exactly.

@1bigpig

This comment has been minimized.

Copy link
Author

commented Feb 18, 2012

chamnit: I was to start working on the .8 version of the limit.c file, but I want to add 2 variables to the EEPROM. First, I want to add a steprate (or at least some delay value) and I want to add a debounce delay. Right now, the steprate value is hardcoded into the routine and the debounce delay is just using the steprate delay, which might not be long enough for some switches.

Bruce

@chamnit

This comment has been minimized.

Copy link
Member

commented Feb 18, 2012

Sounds reasonable. Put these into the config.h file at the bottom. It's the location of temporary place-holders of settings that will may eventually be placed into EEPROM. I've been waiting on getting everything together before committing to a new EEPROM settings menu, mainly to prevent having to support multiple settings versions. This will be brought up as an issue topic when things have reached this point in development.

@1bigpig

This comment has been minimized.

Copy link
Author

commented Feb 23, 2012

I have updated the edge version of grbl to include the homing routine with switch debounce. It also required an update to the config.h file, as there are two values that should become user configurable and stored in EEPROM.

I am interested in seeing how the homing routine works for others. Changes can be found on my fork under "edge".

Bruce

@shapeoko

This comment has been minimized.

Copy link
Contributor

commented Feb 29, 2012

I'm interested in implementing this on one of my test rigs, Do you have any information on wiring available? Also, besides compiling your edge version what else needs to be done?

@1bigpig

This comment has been minimized.

Copy link
Author

commented Feb 29, 2012

You don't really need to do anything, but if it were me, I would download chamnit's edge version and then pull my limit.c and merge my config.h file into his latest build (exactly what I am doing right now). Then do a make clean and make all and you should have working homing switches.

As far as hardware, I am using existing limit switches on my machine. They are just pulling Port B pins 1,2,3 (Arduino D9, D10, D11) low when the switch closes. The homing routine sets the pins 'high' and the switches are normally open but pull the pins to ground on closure (machine touches the switch).

Hope my rambling is clear enough...

Bruce

IF you notice anything funny or wrong with the homing routine, please let me know. While it works 100% for me, it may not for someone else...

@shapeoko

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2012

Bruce,
That makes sense to me. Our machines don't have limit/home switches by default, but we're looking for an easy way to add them. I have a couple of cherry switches laying around from an old project (mame arcade) that I could use for testing.

Just so I'm understanding correctly: Wire one side of each switch to arduino 9,10,11 (X,Y,Z) and the other side to gnd.
Here's a simple diagram i drew: http://www.shapeoko.com/wiki/index.php/Home_switches

After that what's the process to actually home the machine?

@1bigpig

This comment has been minimized.

Copy link
Author

commented Mar 1, 2012

That is exactly correct on the homing switches. As for the switch type, Cherry micro is the exact switches I have on my router. My router is not home built (a Larken 15/15 -- http://www.larkencnc.com/cam15/index.shtml ) that I originally retrofitted with Mach3 and now I am trying grbl.

Once you have the switches hooked up, you would either type G28 or G30 (both are the same in current grbl) and the machine starts the homing routine. Right now, Z is move in the positive direction until the switch is closed and then both X and Y move in a negative direction until those switches are closed. Once all 3 switches are closed, the routine then slowly moves all the axis off the switches at 1/5 the homing rate. Debounce is currently implemented and seems to work pretty well for me. Also, as of current versions, it displays the status of the limit pins in an 8 bit binary number. The little endian bit is the "stepper enable" and the next 3 are the status of the limit switches. A "1" means the switch is open and as soon it closes it goes to "0". Once all the axis are homed, it sets the global machine coordinates to 0,0,0 and then says "ok".

Let me know how it works for you and if you have any other questions, please ask.

@shapeoko

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2012

Thanks for the feedback. I dug the switches out last night and wired them up. Tonight I'll hook everything together and give it a go!

@dmmedia

This comment has been minimized.

Copy link

commented Mar 10, 2012

Thank you for your work.

I have a sudden question about homing process.
What happens, if my machine has only 1 or 2 axes? (I am building the machine myself and it has yet only a single axis, but already capable making half its job)

While for Grbl it is not important, you just don't issue Z coordinates in G-code, but as I have read from the code, and your description here, the homing routine relies on Z axis and will probably hang the controller if Z axis not present, trying to find inexistant home/limit switch, woun't it?

Denis

@chamnit

This comment has been minimized.

Copy link
Member

commented Mar 10, 2012

I've been mulling over this type of problem for the past week or so. At this point, the movements are hard coded into the limits.c source file and only support 3-axis. The idea right now is to make this as simple as possible for people to edit and to change to whatever needs that they have. While Bruce got the homing cycle work restarted, I think some things may need to be amended, like accounting for different axis step resolutions and adding a simple way to do accelerations without having to use the main stepper code. (This will be useful for jogging too).

For your application, I would recommend that you download the source and edit that limit.c file to what you need. Until then, I'm working on updating this code.

@dmmedia

This comment has been minimized.

Copy link

commented Mar 10, 2012

Thank you. I'll try editing the code.

@shapeoko

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2012

Could you just hard wire a switch in for the z-axis. If you wired it as NC, then when the z-axis routine was called to do the homing it would see that the switch was already closed and proceed to the next axis? Don't know if that's true, but if it were it might be easier than hacking the code.

@aldenhart

This comment has been minimized.

Copy link

commented Mar 10, 2012

The way I handled this for TinyG was to specify the axes you want homed in the G28.1 command.

A 3 axis homing command is G28.1 X0 Y0 Z0
2 axes (XY) is G28.1 X0 Y0

I had 6 axes to worry about, so there are a lot of possibilities.

@chamnit

This comment has been minimized.

Copy link
Member

commented Mar 10, 2012

Ed: Good point. You could add a manual momentary switch to the Z-limit pin. I think all you would have to do is hit it once or twice to get it to skip the z-axis homing.

Alden: Maybe we can add this into the list of EEPROM settings. Like what axes to home and in what order.

@dmmedia

This comment has been minimized.

Copy link

commented Mar 10, 2012

Thank you all for advices.
I will try the switches. Have just few hanging around. Need to fix electronics part a bit before next run.

@chamnit

This comment has been minimized.

Copy link
Member

commented Mar 17, 2012

Hey all. Reviving this conversation. So, I've been reviewing Bruce's homing code and have been looking to hard limits during non-homing operations. Separately, I've also been looking into pinning out the runtime control functions for physical buttons. All of these need some kind of debouncing routine to accurately detect the state of a switch. Bruce's approach work fine with the delay calls, since homing is completely independent of everything else. But, while Grbl is running and a switch is hit, we can't use the delay calls. It would really mess things up.

I've been researching debouncing techniques and haven't come up with much. Just about everyone uses some kind of timer count, which isn't easily portable. Does anyone know of a way to software debounce without a timer? Or any ideas on trying to circumvent this problem altogether?

@aldenhart

This comment has been minimized.

Copy link

commented Mar 18, 2012

A couple of solutions come to mind. The first is to use the real time clock on the chip. This takes an interrupt and that may be scarce. The second is to build your own counter register somewhere, as debouncing does not really need to be very exact. You could increment something every stepper interrupt. Put a reader in the main protocol loop. Alternately, how often does the main loop get entered?

@dmmedia

This comment has been minimized.

Copy link

commented Mar 18, 2012

Do we need the software debouncing at all?
Hardware debouncing with 2 resistors, 1 cap and schmitt trigger is pretty cheap and reliable solution.

@chamnit

This comment has been minimized.

Copy link
Member

commented Mar 18, 2012

dmmedia: Good point. So do we need software debouncing at all? I'm not sure. This why I'm bringing this up. There are many ways to do hardware debouncing or just use non-mechanical switches, like optical, to remove the problem. But I'd like to make sure that most new users don't run into this problem unknowingly and that we have a solution in place.

Another question is whether or not we can design grbl to be resistant to a bouncing signal? For example, say we have the cycle start pinned out and user hits a mechanical switch. Does it matter if it signals that pin multiple times? It shouldn't. Or say that a hard limit switch is hit, the same could be said here. So, in what cases does this matter? I can see a jogging switch input as a possible issue.

Alden: Thanks for ideas. I'd like to avoid using a clock, but it might be impossible for a software debounce. Not a bad idea with the step interrupt, but it would be difficult to predict how quick its going. Although, there might be a way to use this idea in a different way. Also, it's hard to say how many times the main loop gets entered, but I would say infrequent when streaming, especially when there is always data in the serial buffer.

@aldenhart

This comment has been minimized.

Copy link

commented Mar 18, 2012

My preferred way of software debouncing is not to do an integration (which delays the onset of the signal), but to introduce a lockout of somewhere between 20 - 200 ms after switch onset - depending on the bounciness of the switch. Some applications do not work with this approach, but it should work OK for the cases discussed here. So the question is, is there a way to set a flag on switch closure (or opensure - in the case of NC switches) such that you can be reasonably assured that it won't be cleared for at least 20 ms. What events can be found in the system that are in this range?

@dmmedia

This comment has been minimized.

Copy link

commented Mar 18, 2012

There should be a way to set the flag using external interrupt.
And then you disable the interrupt for a period of time and read input state on timeout.
But this way it takes lots of time to read the button which may mean a lot in terms of safety (if we talk about software stop button).
Hardware debouncing allows to process things faster.
Maybe there should be a config switch between using hardware or software debouncing.
Or even better - compile time option. That saves some memory for more features.

@jgeisler0303

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2012

Here are some thoughts:
If you want to go hardware debouncing you WILL have a delay because the RC circuit is a first order low pass.
So, if you are willing to accept this delay you might as well program a digital first order low pass and the schmitt trigger. But you still need to count the time between filter updates.

If you want a super fast response you need to read the switch in a pin change interrupt. If you have a non hardware debounced switch that interrupt will be called at a high frequency while the switch is bouncing. So, the calculations here should be kept to a minimum.

Do we need debouncing at all?:
For limit switches, all we really need is a lockout. For this, a delay may be used because nothing should be moving after a limit switch is hit or after it is cleared.
For jogging, we might do something like this: start jogging upon first impulse and move a certain distance (e.g. 0,1mm); when the move would start deceleration, check if button is still pressed, if yes: move another 0,1mm, if no: stop and then wait for next impulse. This way the lockout is implied in the machine timing.
Same goes for Cycle Start/Stop: a machine state is toggled and any retriggering is ignored.

@chamnit

This comment has been minimized.

Copy link
Member

commented Mar 19, 2012

Interesting points all.

I'm starting to lean toward requiring hardware debouncing for bounce-prone mechanical switches. I'd rather not add another layer of complexity with a software debounce, if we can. It is sounding like there is not a simple solution without the use of a timer or delay, and we can design around this problem for the most part.

Jens: I've been re-thinking how to implement homing and jogging motions without the use of the planner, and you're solution may be the way to go. Basically, I'd create a static planner block that the stepper routine would repeatedly process until there is a state change. I will likely have to refactor the stepper module a little to make it simple and modular, but this could the way to implement simple ac/de-celeration motions for jogging and homing without needing the planner.

@dmmedia

This comment has been minimized.

Copy link

commented Mar 19, 2012

Jens: I haven't said, the hardware debouncing will not have any delay. I've stated, that the delay can be much smaller, than with the software.

chamnit: here, you can compare different hardware and software debouncing techniques: http://www.ganssle.com/debouncing-pt2.htm
Also there are maths that can help to choose right component values for given switches.

Jens again: I do agree with you about jogging, but not about limit switches. Software can hang or malfunction. I am now making my limit switches to stop hardware and notify software. I want the switches to switch off stepper driver output enabling signal for the direction of the switch, allowing to continue movement in the opposite direction at the same time. This should serve two purposes: 1) will not lock the hardware when the switch is hit and in pressed condition and 2) will allow to stop the motion in case Arduino will hang or malfunction. My emergency switch will be hardware only and will simply cut the stepper drivers power off.

I have just seen the malfunction and following hanging, when did not changed the defaults for axes Y and Z, while having only X axis on my CNC, which is in construction now. And default values combined with my X axis speed rate gave total of 44kHz step rate. I have written G-Code using inexistent Z axis just to make my X axis stop between commands, which lead arduino to behave strangely, making random motions on X axis, hitting limit switches, stalling motor, losing steps and hanging at the end.

@chamnit

This comment has been minimized.

Copy link
Member

commented Mar 19, 2012

Thanks Denis. I've seen this page before. It has a lot of good stuff there. I think I'll put it up in the Wiki FAQ about debouncing limit switches.

Anyhow, I think the problem here is that the de-bouncing requirement, either hardware or software, is very machine/user dependent. I was hoping that there was some already established simple software solution, but it's looking like it's going to be involved to get a clean, portable, universal solution, that is if we need it. I'm starting to get a feeling that Grbl may not need to support this or this could be pushed back to a v0.9+ development item. I say this, because the current version of Grbl has no input pins other than the limit switches that require any form of debouncing. The homing routine Bruce has, or something similar, should work fine for v0.8.

So my thinking is, unless another maintainer has some time to work on it, we should push this issue back to the next development version and finish v0.8. I think the only remaining (major) things are wrapping up the homing routine, jogging routine, advanced settings, and status reports. Anyone agree?

@jgeisler0303

This comment has been minimized.

Copy link
Contributor

commented Mar 21, 2012

I Agree. Lets not get too entangled. Concise quality releases should be the way to go. Once a feature is in it's hard to get out. And if it was not thought through well enough it can become a real pain.

Another argument for requiring hardware debouncing when needed: the average user of grbl is probably a hacker who has built or modified his or her machine. So, he (or she) should be able to tinker some RC circuit. For the rest and as grbl and CNCing becomes more mainstream, maybe grbl shield v2.0 will include debounced switches (or does it already?).

@Shadyman

This comment has been minimized.

Copy link

commented Apr 21, 2012

Sorry to bump an old issue;
Would there be any benefit to having two limits per axis to prevent inadvertent machine damage? I'd imagine with the right coding, each axis' min and max switch could simply be run in parallel to the same pin, and which limit it has reached is determined by the motor direction.

@chamnit

This comment has been minimized.

Copy link
Member

commented Apr 21, 2012

No it wouldn't be that hard to do. The issue is whether or not you care that Grbl knows where it is after it happens. This is the problem with open-loop control, the stepper motors provide no real-time feedback to the controller. If you stop the machine immediately with a limit, you lose position.

I'm of the opinion that the stepper motor sizes that Grbl generally supports do not have enough torque to cause any damage to the screw or motors. I personally think that it would be easier to install 'soft' limits that are set in software. It would require the user to do a homing cycle to make use of them, but this would allow Grbl to perform a controlled deceleration to a stop and keep its positioning.

@chamnit

This comment has been minimized.

Copy link
Member

commented Oct 1, 2012

(Updating an old thread)

The limit routine has just been updated to include acceleration and correct motions for multiple axes, but other than that, it should behave similar to how it did before. It's the first commit, and there is much more to do. Right now, I'm looking at coming up with a simple way for a user to set up the limit switches, i.e. normal high/low, switches that don't exist.

I'm also looking at creating a hard stop limit interrupt that basically does an e-stop, when a limit switch is triggered during normal operation. It will force Grbl to shutdown all motors and spindles and then go into an infinite loop and lock out all other processes. Only a physical reset of the Arduino will restart Grbl. This would work for any multiple limit switch per axis setup. Also, a user should be able to wire an e-stop switch into any of the limit pins to get e-stop functionality.

Please let me know if you all would like to me to change it up a bit or see any issues. Thanks!

@komradebob

This comment has been minimized.

Copy link

commented Oct 5, 2012

A bit mask would be easy enough way to set up the presence/non presence and direction of a pin. 8 bits gives you enough to cover 4 axis.

I guess I see estop and limit as very separate functions. E-stop is e stop, but a limit switch hit might cause a recalibration for example. Limit switches make good inputs for homing and calibration. As such, you definitely want to code the behavior of limit switches in software. E stop either needs to be interrupt, power cutoff or both.

If you happen to have closed loop control, I think the separation gets even more important. Given a recent discovery I found of arduino code to read I-gauging quadrature sensors, closed loop would not be that far a leap. It might require multiple processors, however, compute cycles is the cheapest part of this. I could easily see the grbl controller interrogating the sensor controller for position in near real time.

@chamnit

This comment has been minimized.

Copy link
Member

commented Oct 5, 2012

Thanks for the input! Much of this has already been discussed quite a bit.
The bit mask is likely the way setting limits active and the normal states
will be done. Just need to come up with a nice tidy package that will store
well into memory and still be not too cryptic.

Estop and limits are separate true, but they share a lot of same behavior.
A true estop is hard wired to shutdown everything. In general it's
recommended to wire the estop switch directly into the arduino reset pin.
Limits will serve two functions. Homing and hard limits. Hard limits will
perform similar to an estop and automagically stop everything once
triggered. This is because position is lost as the steppers have no
feedback and must stop immediately. Either way estop/hard limit behaves
about the same.

The other thing that will be added is soft limits. Once machine zero is
known by homing, a user can set a work volume. If it comes close to an
actual physical limit, we can have grbl do a controlled deceleration
without losing position. This just needs grbl to abort the buffered actions
and soft reset.

LCD support would be nice but not high priority in my view. It would likely
see limited use. Although having an i2c type interface option could open
the door for things like this as an external package.

On Oct 4, 2012, at 9:14 PM, komradebob notifications@github.com wrote:

A bit mask would be easy enough way to set up the presence/non presence and
direction of a pin. 8 bits gives you enough to cover 4 axis.

I guess I see estop and limit as very separate functions. E-stop is e stop,
but a limit switch hit might cause a recalibration for example. Limit
switches make good inputs for homing and calibration. As such, you
definitely want to code the behavior of limit switches in software. E stop
either needs to be interrupt, power cutoff or both.

If you happen to have closed loop control, I think the separation gets even
more important. Given a recent discovery I found of arduino code to read
I-gauging quadrature sensors, closed loop would not be that far a leap. It
might require multiple processors, however, compute cycles is the cheapest
part of this. I could easily see the grbl controller interrogating the
sensor controller for position in near real time.


Reply to this email directly or view it on
GitHubhttps://github.com//issues/63#issuecomment-9164271.

@chamnit

This comment has been minimized.

Copy link
Member

commented Oct 5, 2012

OK so I'd like to pose a question that I'm not 100% sure of the answer.

From what I've read many many times, the Arduino Timer0 shouldn't be used because some of the libraries depend on its availability. After looking into it more, this should only be limited to when using the Arduino IDE, not avrgcc. So, if this is true, I'd like to see what you all think about how to use Timer0.

One thing that needs to be remembered is that adding another asynchronous interrupt, i.e. the stepper pulse train and the serial r/w interrupts, can cause collisions, where one can delay the other by a few microseconds. This may not sound like a lot, but if we want to ensure the stepper pulse train is as clean and dependable as possible, we can't add another high frequency interrupt into Grbl.

So, I've been thinking that we can use Timer0 as a debounce timer for any pinned out switch, like a cycle start, jog, feed hold, etc. The way I see this working is to have each switch call a pin change interrupt upon detecting a change and then enable the Timer0 overflow timer to timeout after a debounce delay set period. If the switch in question is still at the same level, it's confirmed to be triggered. Afterwards, Timer0 is disabled, until the next pin change event.

If you all think this will work, I'll start working on it. Just wanted to do a sanity check before committing a lot of time to this.

@csdexter

This comment has been minimized.

Copy link

commented Oct 5, 2012

You are right about Timer0 being used only by the Arduino core (millis() and micros() use it as a wallclock). avr-libc -only does not touch it in any way (or any other AVR peripheral, for that matter) so it's all yours for the taking.

@simen

This comment has been minimized.

Copy link
Member

commented Oct 5, 2012

Go for it! I saved Timer0 for PWM control of spindle speed. It turns out connecting the spindle to your arduino is a very bad idea, so that didn't play. The Lasersaurus people uses it for dynamic laser power control to compensate for speed variation, but I think they forked away from us a long time ago and this would not be a problem.

On the other hand I could see some uses for a regular "system tick" kind of interrupt for more low frequency timing things (useful for homing cycles and dwells perhaps). Could this somehow be combined? Perhaps by sampling the inputs every system tick and requiring two identical readings before taking action. (I mean: no reason to use interrupts to read them if you are going to wait for a debounce confirmation anyway). On the other hand, this might make stepper pulses slightly irregular, and we wouldn't want that!

@komradebob

This comment has been minimized.

Copy link

commented Oct 5, 2012

Might be useful for a number of purposes. Keyswitch scan, watchdog timer
both come to mind.

On Fri, Oct 5, 2012 at 4:03 PM, Simen Svale Skogsrud <
notifications@github.com> wrote:

Go for it! I saved Timer0 for PWM control of spindle speed. It turns out
connecting the spindle to your arduino is a very bad idea, so that didn't
play. The Lasersaurus people uses it for dynamic laser power control to
compensate for speed variation, but I think they forked away from us a long
time ago and this would not be a problem.

On the other hand I could see some uses for a regular "system tick" kind
of interrupt for more low frequency timing things (useful for homing cycles
and dwells perhaps). Could this somehow be combined? Perhaps by sampling
the inputs every system tick and requiring two identical readings before
taking action. (I mean: no reason to use interrupts to read them if you are
going to wait for a debounce confirmation anyway). On the other hand, this
might make stepper pulses slightly irregular, and we wouldn't want that!


Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-9187984.

@chamnit

This comment has been minimized.

Copy link
Member

commented Oct 5, 2012

Hmm, there's a lot we can do with this. The system tick idea could work with the runtime command module and send status reports to GUIs at regular intervals too. Like simen said, we'd have to figure out a way to do it without using interrupts (at least too much)... There's much to think about. So, I'll plan on pushing through getting some of these user settings and status reporting cleared up and then move the edge branch to master. (It seems about the right time.) And then plan on starting the Timer0 stuff on the new edge branch.

Perhaps it might be a good idea to get a list of things we would want a system tick to do and plan out how we'd like to proceed?

@komradebob

This comment has been minimized.

Copy link

commented Oct 10, 2012

Downloaded and compiled. Much better than before.

Comments:
Wasn't the z axis homing cycle + until limit rather than -? On my machine it is going -.

An additional thing to report from the '?' Cmd would be the status of the limit switches. Handy for debugging.

On Oct 5, 2012, at 19:59, Sonny Jeon notifications@github.com wrote:

Hmm, there's a lot we can do with this. The system tick idea could work with the runtime command module and send status reports to GUIs at regular intervals too. Like simen said, we'd have to figure out a way to do it without using interrupts (at least too much)... There's much to think about. So, I'll plan on pushing through getting some of these user settings and status reporting cleared up and then move the edge branch to master. (It seems about the right time.) And then plan on starting the Timer0 stuff on the new edge branch.

Perhaps it might be a good idea to get a list of things we would want a system tick to do and plan out how we'd like to proceed?


Reply to this email directly or view it on GitHub.

@chamnit

This comment has been minimized.

Copy link
Member

commented Oct 10, 2012

Ah good catch. I need to apply the invert mask to it. I'll update it later tonight.

To get the limit status to print, just place this line in the protocol_status_report() function in protocol.c:

print_uint8_base2(LIMIT_PIN);

This should print the binary of the state of the upper digital pins.

@komradebob

This comment has been minimized.

Copy link

commented Oct 10, 2012

Ah, ok. I thought I was loosing it or swapped the motor leads in my sleep :)

Thanks for the info on the pin status print.

On a related note, I was looking at my table going back and forth this
afternoon, hitting the limit(min) switch and thinking if one were to wire
the two limit switches in parallel, you could sens which one you hit by
looking at the direction being traveled at the time a change was sensed.
Might be a poor man's solution to having max and min limit switches without
adding any more pins.

On Wed, Oct 10, 2012 at 7:43 PM, Sonny Jeon notifications@github.comwrote:

Ah good catch. I need to apply the invert mask to it. I'll update it later
tonight.

To get the limit status to print, just place this line in the
protocol_status_report() function in protocol.c:

print_uint8_base2(LIMIT_PIN);

This should print the binary of the state of the upper digital pins.


Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-9323853.

@chamnit

This comment has been minimized.

Copy link
Member

commented Oct 11, 2012

Fixed. Should ok now.

@chamnit chamnit closed this Oct 30, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.