So, how is this being done? And can it be replicated in the Atmel space? I would enjoy not ever having to hook up endstops ever again…
https://www.youtube.com/watch?v=kB22GvtcAO8
Very cool. I’m guessing they are using feed back of some sort from the motors stalling.
The driver chips are SPI, so probably sensing the change in current and providing feedback to the Beaglebone.
They could measure the current draw to tell when the travel is stalled. The hardware necessary for that has other benefits to make it worth it: Collision detection, sanity monitoring, warning that lube is needed.
Probably a good way is to run it to one stop under low power (assuming the power can be modulated). With current monitoring it can know that it reached the stop without just trying longer.
It may be possible to verify motion by monitoring the voltage of the un-energized phases (speculation). This would have the added benefit of monitoring and stopping when part of the driver failed.
My motors have 6 wires, two of which are unused. I wonder if observation of those two wires wouldn’t give some feedback on how the motor is working?
@Mike_Miller – it’s very likely that you have unipolar stepper motors, wired as bipolar motors, so those two wires are just center taps for the motor windings.
In the industrial CNC space this is done using absolute linear encoders on the axes. As soon as the machine powers up it knows exactly where it is (and by reference, where its hard limits are.) That’s the right way to do it, but it’s also really expensive.
Well. Expensive today. I power up my Digital Caliper and it has a pretty good idea of how open the Jaws are, and while a good one is still $200, the Harbor Freight ones are $10-$20. Now, if only they fed back into my Rumba…
I doubt this would work for Z though, unless your bed and couplers have zero flex.
Looking at the board they have positions for encoders, which would be nice.
Too bad its so absurdly large.
@Mike_Miller Those Harbor Freight calipers do have a serial output hidden inside. I’ve seen a project somewhere where they were used as a kind of linear encoders.
Yeah, almost all of them have a four line serial protocol: power, ground, and differential signals. Finding a connector to attach to them is a bear: it’s easier to just solder on. You can pull the battery and power from the reader, and there are software packages to interface them with computers. I use two on my lathe as a digital readout, via the shumatech hardware/software package.
The output from digital calipers isn’t fast enough to close the control loop on a motion axis, unfortunately.
Note there are two different difficult things about absolute encoders. 1: expense and fussiness of getting the linear encoder attached accurately and interfaced correctly. 2: doing something with the data. Most hobby CNC (and all diy 3d printers I’m aware of) operate open-loop. They decide “g0 x1 y1” and calculate how many steps that is and send out the steps to the motor and assume they’re now at x1 y1. High end cnc machinery works through closed-loop servo control: they say “we’re at x1, y1, and we want to be at x2, y2: drive the x and y motors, and watch the encoders until we get there.” They never lose position, but the math involved in closed-loop control is fairly different than in open-loop. Linuxcnc is capable of operating closed-loop. I don’t know about most common 3d printer software.
There were one or two kickstarter printers that used brushed DC motors and encoders instead of steppers for their linear drives. It’s definitely not something our firmwares can do right now, but since all other pieces of software (including the slicer and host) don’t care much about how the machine is driven, the effort for that would at least be limited to a firmware fork.
Regarding the original question; some stepper drivers have a fault output that triggers when it detects a stall or the like. If you use that instead of an endstop, you can just crash your axis into one end and for the firmware it’ll be just the same as if you had an endstop. But then again, you can already do that on any other 3D printer, even without ever telling the firmware that the axis has now reached its end.
A friend of mine @Joshua_MalaMaker_Mal is doing a project to use encoders based off the same tech as those calipers and read them with arduino. Could have some possibilities.
This isn’t using encoders, etc. They wouldn’t be calling it sensorless if it did.
It’s using stall detection in the stepper motor driver chips, which communicate this back via SPI.
It’s nice, but you then need to not suffer any damage doing that constantly, which I don’t really think most machines are designed for. Also, depending on your parts, your end of axis may not be repeatable (eg: springiness of the bed, flex in the Z couplers, etc).
@Stuart_Young , luckily that wouldn’t matter much for X/Y - obviously it would for the Z though, but still. Looking for drivers which support this. 
@ThantiK TMC260’s do, and a number of other TMC drivers, plus the L6470PD. BUT: They need to be programmed by SPI first (before you talk to them with Step/Dir). This means that currently, no Atmel firmwares support them AFAIK.
The BAM/DICE setup from @2PrintBeta might support the TMC chips soon (they support the L6470PD), but (AFAIK) not currently, and even then, firmware still needs to be written. https://www.indiegogo.com/projects/bam-dice-the-new-open-standard-for-arduino-based-3d-printers-and-more
FWIW: So you won’t be able to just drop one of these in place of an A4988 Pololu on your RAMPS board.
For any printer where the print bed drops off suddenly, couldn’t you use a light based feedback method for x,y endstops?