Could code be added to the firmware to test the actual position?

What problem does this solve?

The idea is basically a check to see if you're losing steps.  Like the problem I had where the tip of the hot end was hitting the plastic of the last layer and being held up.  If you're losing steps badly rather than waste filament on an already ruined print the firmware could do an emergency stop and power down the heaters.  Or possibly it could back up and increase speed to do the same movement.  The idea there being that you could get past a small hump with some more force.

I have thought about this quite a bit and actually purchased the non-magnetic version of this:

https://www.sparkfun.com/products/9072

To test the idea in one of the other printers I am building.  I have not had time to test it on a machine yet, but doing measurements and performing the math on paper shows that it is really as linear as they say. You can predict the resistance based on distance from the end.  Now, that said, I don't know if it would provide the resolution we would need. Might be too much overlap between microsteps to be of real value.

My idea was to attach an i2c eeprom or other storage device. Then run through a calibration routine where every tiny step on each axis is visited and store the resistance found there.  That would give you a perfect lookup table and also show you if there were overlaps.  During runtime, you just lookup the location based on the steps and use the resistance to tell you when you get there.  Probably need to deal with acceleration/deceleration issues so that farther distances could move faster but shorter distances would move slower, etc.

Its pretty standard stuff for feedback, as I understand it.  The upshot is, that servo based CNC machines do basically this same thing.  The problem is that because of imperfections in the linearity of the sensor, you can get jitter... where the feedback on position is not perfect and the servo oscillates back and forth between two positions because the desired location is somewhere in the middle and unreachable.  Since anything is possible with enough money, I am sure you could engineer your way out by purchasing some very expensive sensors or whatever.

To get around the problems with servos (jitter) and steppers (missing steps) you add feedback to the stepper.. just use it as a hybrid. If you ask to move 5 steps and the system thinks it moved 5 steps but you only moved 3 steps according to the sensor, maybe you are not far enough.. keep going.  But if you ask to move one step and the system still reads 1 step away, that could be just an imprecise sensor so trust the stepper... something like that.

That was my thought on it anyway.

Resistance based sensors will lose calibration with wear and temperature variations. Optical is the way to go, IMO.

Here's one for $39:

http://www.usdigital.com/products/encod … ry/kit/E4P

You can get 360 counts per rotation, plenty to detect a missed step on our motors.

They also have linear encoders for $40:

http://www.usdigital.com/products/encod … odules/em1

The tape that goes in the linear encoders is like $1/inch, with ~0.05mm resolution. So I guess that's a workable solution, OP.

Yeah, thats why I listed the non-contact version of the sensor.  According to the specs, it lists over 1 million cycles for durability and an operating temperature up to 50C.  I don't really know for sure, but I am guessing that the ambient temperature of my 3D printer wont go above that 50C.  Also, I will probably upgrade both my printer and/or sensor by the time I reach 1 million cycles.

Mostly, it simplifies the programming.  Lets assume you have an encoder hooked up to track the position of the print head as you turn the stepper. Realistically, you want it on the idler so that you can detect an actual movement rather than just counting the motions on the motor (incase of the belt slipping and the motor turning).  Now, you get an encoder that can count 360 positions per turn and then you move the head so that you make 3 turns of the head.  So the encoder might be saying your position is 24 while it is really 1080 (depending on starting position).  Now, if you turn off the machine and come back to it later, you don't know where you are in space.  Depending on the type of encoder you use, you might have a location from the most recent reading that is returned, but it tells you very little with regard to a real position.  In order to fix this, you need to size your encoder so that it can count at the absolute maximum for the resolution of your micro-stepping mode and total possible distance.  Let say that you have a good resolution (I have one that is 0.9 degrees / step) and a 1/16th micro stepping mode.  At normal steps, it takes 400 steps to make one complete revolution, right?  and with 16th micro stepping, you get a total of 6400 steps per revolution.  If it takes 30 revolutions to move you from one side to the other, the minimum resolution you would need is 192000 counts. It would need to be geared so that you make one complete revolution on the encoder for the entire distance from one side to the other.

At that point, an absolute encoder would be able to tell you exactly where you are at power up and you could never miss a single step.
It will likely be very expensive.  Alternatively, you have to count the number of times you make one complete revolution and do some internal math to find current position.  Maybe even store the information in an eeprom so that you can get the position again at startup.  You would have to store it there on every move, though, or you would lose the position if the power were lost unexpectedly.

The linear pot is just read for resistance and compared to a location table, similar to how temperatures are measured.  Mostly, the code is already written.

Thats a little back of the napkin, but seems right as far as I can tell. What do you think?

In any case, there are likely to be drawbacks to any system... with resistors, the resolution might not be high enough to discern each step (don't know and haven't tested it).  On the encoder side, you have more cost and slightly higher complexity but possibly greater reliability.  I tend to like prototyping on the low cost side and upgrading as I need, though.

You absolutely can. Unfortunately, the optical sensors in ball mice are generally low resolution (~20 counts/rev). They get away with this by using a small roller against the ball, giving a gearing of sorts, increasing the effective resolution. You could do this in this application, but it just increases complexity when there's off the shelf solutions for $40.