Why use seperate input pins for a max and min stop?

Guys,

Just a thought. Sorry if someone else has come up with this.

Rather than using a separate pin for a max stop and an min stop on an axis why not use the same input and the direction of travel set on the stepper to calculate which stop we have hit.

i.e.

if we are moving the x axis left and a end stop raises a pin high we can only be at the min stop position.

if we are moving the x axis right and a end stop raises a pin high we can only be at the max stop position.

In this fashion rather than use 6 pins on the arduino you would only need 3 and could still have six stops.


Actually taking things further you could get away with using only two pins.
For everything.

Hooked to input pin 13 is Max and min X endstop + Max and Min Z endstop
Hooked to input pin 12 is Max and min Y endstop + Max and Min Z endstop

and use the following logic

If 13 goes high and 12 does not we have an X axis
{if stepper direction is 1 we have min stop, if direction is 0 we have max stop}

If 12 goes high and 13 does not we have an Y axis
{if stepper direction is 1 we have min stop, if direction is 0 we have max stop}

If 13 goes high and 12 goes high we have an Z axis
{if stepper direction is 1 we have min stop, if direction is 0 we have max stop}

regards

Stephen

you make a fine point. I'll try this out at some point and tell you how it goes

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Part of the point of and endstop is electronics level crash protection. I.E. if the min endstop is hit, the electronics won't allow the motor to turn anymore in that direction, even if the firmware says "keep going". Also the firmware level stuff is MUCH simpler to write with safety in mind that way.

Since the only real point in having a max endstop is safety, there's not much point in combining them - the extra complexity of code defeats most of the purpose.

Having said that, there's still situations where it WOULD be useful to have that. A small error in the complex code governing the endstops would still negate it's usefulness though.

Also keep in mind that just because one step forward hit the switch doesn't mean that one step back will "unhit" the switch. This'll make the code even more complex and error-prone, of course...

---

--
I'm building it with Baling Wire

This was discussed a while back and multiplexing based on direction was brought up.
[dev.forums.reprap.org]

The conclusion was, yes, there are a few clever ways to save pins on the endstops, but just removing the max stops works as well and is simpler. I haven't kept my max stops properly aligned and functioning well because I never hit them and I have bigger problems to solve.

---

---

Darwin clone, Gen 2 electronics, Arduino Duemilanove w/ AtMega328, 5D Firmware, Pinchwheel extruder
[www.codeerrors.com]

a simple NOR gate could eliminate the need for firmware and pins entirely.

tie the direction of the stepper to A and the endstop to B and Output to the enable on the stepper control. if a flag gets hit then the drive will only be able to move in the opposite direction.

obviously this assumes direction and endstop both go LOW when you want to stop the motor. you can also use a NAND gate with an inverter if the condition is both HIGH.

mfsamuel Wrote:
-------------------------------------------------------
> a simple NOR gate could eliminate the need for
> firmware and pins entirely.

The advantage of a pin -- the microcontroller can more effectively and efficiently zero the moter.

The NOR solution would require openloop, stepping the motor thru a significant distance to ensure it gets to the endstop, without actually knowing that it made it.

BeagleFury Wrote:
-------------------------------------------------------
> The NOR solution would require openloop, stepping
> the motor thru a significant distance to ensure it
> gets to the endstop, without actually knowing that
> it made it.

good point, and back to stephen's original post, we can run 6 stops off of 3 lines. with NOR gates you only need the min stops going to the controller to zero instead of max and min, and require less logic than stephen's original post.

the added advantage of the NOR gate is that it is not subject to firmware bugs and provides a nice hardware only check.

I'm planning to run my whole mendel from an arduino, so I simply don't have enough I/O lines for all 6 end-stops.

How about some logic gates on the direction line so the endstop input 'sees' the zero stop when moving towards home, and the max stop when moving away? We can then put an AND gate on the step line so we have electronic lockout as well as firmware notification.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> How about some logic gates on the direction line
> so the endstop input 'sees' the zero stop when
> moving towards home, and the max stop when moving
> away? We can then put an AND gate on the step line
> so we have electronic lockout as well as firmware
> notification.

that is what the NOR gate should do. 1 on the endstop 1 on the direction. i was handling the protection logic a little different, rather than adding the logic to the step line i was adding it to the enable pin, so if the direction and endstop were both triggered the whole chip would be disabled. wonder if it is better to disable the chip (will power down motor), or just prevent future steps towards the endstop (while keeping coils charged).

if we want to zero each axis one at a time we can tie everything together on a single line and use the software to test each motor one at a time. i'll make a simple circuit and post it to the forum as proof of concept.

this method would give us hardware protection against running the motors past the stops and allow zeroing each axis off a single line. programatically cycle through each axis and test the endstop line, then move a few steps off of the endstop to clear the line for the next axis.

> if we want to zero each axis one at a time we can
> tie everything together on a single line and use
> the software to test each motor one at a time.
> i'll make a simple circuit and post it to the
> forum as proof of concept.

indeed, this was what occured to me when discussion on 6 vs 3 pins for endstops.

So, question being, what is the minimal wiring/component count. I'd guess a 14 or 18 pin MCU would probably be competitive to dedicated boolean logic chips (I count at least 8 binary logic gates?) This arrangement also provide flexibility E.G, drive HBridge driver directly while still providing convenient EN+DIR+STEP translation.

hey guys,
does anyone actually know how to set up the firmware for 6 endstops??

i can get the min X and max X endstops to work, aswell as min Y.. but the rest is a myth...

it seems that max Y and Z dont want to get involved

any ideas????

Quote

...EN+DIR+STEP translation.

Probably trying to multiplex or use boolean IC to process STP or DIR would not be wise. These are suposed to be "de facto"-realtime. Any IC trying to alter their logic will just add delay into the signal processing. Now you have rise/fall times of uC, plus boolean IC input plus processing time, plus output time, etc. Each of the rise times has a certain "uncertanity" in its rise and fall time(s) and if all of those get added together, its safe to presume things will mess up. Stepper driver watches STP line closely to detect in terms of 10's or 100's nanosecs when and where to step. With uncertain delays you might end up in cases that it makes a step in the wrong direction because STP line change got too soon (or the other way around, DIR too late).
So, imo, i would keep using DIR and STP are to be just realtime, directly to stepper driver.

If you want to make economy in pins, simply just use one pin for all EN and tie all enables together. If you have a servo probing the buildplate height, then even Z will be on all the time (plate mapping will keep Z active). Otherwise could keep Z enable separate so Z can get disabled while x+y prints a layer.

And if you need to make more economy in pins for endstops, then you can pretty much print with no endstops at all. Teacup used to have that as a feature, and i think a very smart one. Just move the printhead where you want to start the print and print there. In start.gcode home command instead will set zero for all axes at that point, after that it can print the object from zero. For convenience slicers can be set to output the print with the zero point in the middle of the object. So endstops can be entirelly optional if a person is willing to eye-ball the print range instead. Another thought: there were cases where endstops would give false positives, and if you want to increase the length of the endstops wires, then shield them and ground the shielding, otherwise it just makes a bigger "antenna" to pick up interference.

Edited 2 time(s). Last edit at 08/26/2016 10:04PM by NoobMan.