<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
	<title type="html"><![CDATA[SoliForum - 3D Printing Community — Could code be added to the firmware to test the actual position?]]></title>
	<link rel="self" href="https://www.soliforum.com/feed/atom/topic/843/" />
	<updated>2012-12-21T07:53:53Z</updated>
	<generator>PunBB</generator>
	<id>https://www.soliforum.com/topic/843/could-code-be-added-to-the-firmware-to-test-the-actual-position/</id>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7673/#p7673" />
			<content type="html"><![CDATA[<div class="quotebox"><cite>elmoret wrote:</cite><blockquote><div class="quotebox"><cite>ronsii wrote:</cite><blockquote><p>Or you could rip open an old optical mouse(with ball) and that will get you two axis&#039; of opto then just run then to a arduino or similar to keep track of the head position and just pol that micro for current pos.</p><p>I know there are plenty of articles around on how to do it because I was going that route with a cnc router a long time ago, sorry don&#039;t have links right now but I am sure google could find then for you.</p></blockquote></div><br /><p>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&#039;s off the shelf solutions for $40.</p></blockquote></div><br /><p>Yep, know all about that :-) my design used some toy plastic gears glued on to the quadrature wheels for the mouse so I had&nbsp; more than 10:1 ratio.. forget the actual number but I remember having more than 360 counts per rev on the stepper. There is an article somewhere on cnczone that is similar to mine, the guy got a bit more elaborate than myself as I was trying to keep things as cheap as possible... he used gecko&#039;s and I used a 30 dollar 4 axis board from ebay. The machine actually worked pretty good for a few months then I got bigger steppers for it and put mach3 on it and sold it <img src="https://www.soliforum.com/img/smilies/sad.png" width="15" height="15" alt="sad" /></p><p>Did have one problem with using the optical sensors on it since I didn&#039;t really make housing that were sealed dust would get in it and start messing with it and every once in a while it would trip ferror on emc , so I found the main use for the feedback was in setup.</p>]]></content>
			<author>
				<name><![CDATA[ronsii]]></name>
				<uri>https://www.soliforum.com/user/296/</uri>
			</author>
			<updated>2012-12-21T07:53:53Z</updated>
			<id>https://www.soliforum.com/post/7673/#p7673</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7672/#p7672" />
			<content type="html"><![CDATA[<div class="quotebox"><cite>elmoret wrote:</cite><blockquote><p>I have to say I disagree with most every point you made.</p><p>As far as I can tell, that magnetic pot is just a magnet sliding on a variable resistor. That will wear, in time. There&#039;s a reason the tolerance is listed as +/- 20%. Yes, the life cycles are listed at 1M, but that doesn&#039;t mean the output is constant over those 1M cycles. Also, just because there sensor is rated at a temperature does not mean its output/accuracy is unaffected by temperature. The resistance of a resistor varies WRT temperature. This is how thermistors work, though they are designed with materials that amplify these effects.</p><p>You don&#039;t need indexed encoders and you definitely don&#039;t need absolute encoders in this application. Let me explain.</p><p>When you home/zero the printer, you reset both the local coordinate system (this is what gcode uses) and the encoder count. Then, you start printing. Optical encoders simply return the fact that a count forward or a count backwards has occurred. It is up to the microprocessor to maintain a count - the encoder simply give a &quot;+1&quot; or a &quot;-1&quot; for each degree... but the microcontroller is already doing this for the steppers! When you command +10mm, for instance, that is converted to a number of steps, and the microcontroller generates pulses until the desired count is reached. Then, all the microcontroller has to do is compare the number of steps commanded to the number of counts sitting in the counter register on the microcontroller.</p><p>You can do it cheaply with optical encoders. You don&#039;t have to count microsteps. Stepper motors don&#039;t lose microsteps, just steps... even when they are being microstepped. You may not achieve the desired position precisely, but the step is not &quot;lost&quot;. It is simply not perfect due to mechanical friction/hystersis/backlash. The next step/microstep does not carry the error of the last one - the effect is only cumulative if an entire step is missed.</p><p>Does any of this make sense?</p></blockquote></div><p>So, basically, you are going for something completely different than I am.&nbsp; I am looking to know, from power on to power off exactly where the printhead is located, without homing.&nbsp; In the situation you suggest, sure, I can see exactly your use of the system and how you can achieve it.&nbsp; Still have to home to know where you are though. Unfortunately, it wont help in my situation.&nbsp; Just different goals. Might not be able to achieve it using my current approach either though. Wont know till I test it out.</p><div class="quotebox"><blockquote><p>The next step/microstep does not carry the error of the last one - the effect is only cumulative if an entire step is missed.</p></blockquote></div><p>I did not know that steppers don&#039;t lose microsteps.&nbsp; That is an interesting point and curious.&nbsp; So, if you end up on a missed step (or microstep) the next step is only partial to correct for the error? Is that what you are saying?<br />Naturally, that doesn&#039;t account for belt slippage (a huge problem on my RepMan z axis). </p><p>As I mentioned, though, I havent tested the actual resolution of the sensor, so I can&#039;t actually say that it is suitable, just that it is something I purchased to try out (actually, I purchased the contact sensor). </p><p>Their site states the following with regard to temperature:</p><p>Temperature Coefficient Of Resistance<br />The unit change in resistance per degree celsius change from a reference temperature, expressed in parts per million per degree celsius as follows:</p><p>T.C. = ((R2 - R1)/R1(T2 - T1)) * 106</p><p>Where:<br />R1 = Resistance at reference temperature in ohms.<br />R2 = Resistance at test temperature in ohms.<br />T1 = Reference temperature in degrees celsius.<br />T2 = Test temperature in degrees celsius.</p><p>So, it seems like it would be something I could quantify.&nbsp; <br />In any case, I still think I am better off prototyping with something cheap and simple. You just have different goals than I do.</p>]]></content>
			<author>
				<name><![CDATA[cephdon]]></name>
				<uri>https://www.soliforum.com/user/339/</uri>
			</author>
			<updated>2012-12-21T07:39:43Z</updated>
			<id>https://www.soliforum.com/post/7672/#p7672</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7661/#p7661" />
			<content type="html"><![CDATA[<div class="quotebox"><cite>ronsii wrote:</cite><blockquote><p>Or you could rip open an old optical mouse(with ball) and that will get you two axis&#039; of opto then just run then to a arduino or similar to keep track of the head position and just pol that micro for current pos.</p><p>I know there are plenty of articles around on how to do it because I was going that route with a cnc router a long time ago, sorry don&#039;t have links right now but I am sure google could find then for you.</p></blockquote></div><br /><p>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&#039;s off the shelf solutions for $40.</p>]]></content>
			<author>
				<name><![CDATA[elmoret]]></name>
				<uri>https://www.soliforum.com/user/221/</uri>
			</author>
			<updated>2012-12-21T06:15:35Z</updated>
			<id>https://www.soliforum.com/post/7661/#p7661</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7660/#p7660" />
			<content type="html"><![CDATA[<p>I have to say I disagree with most every point you made.</p><p>As far as I can tell, that magnetic pot is just a magnet sliding on a variable resistor. That will wear, in time. There&#039;s a reason the tolerance is listed as +/- 20%. Yes, the life cycles are listed at 1M, but that doesn&#039;t mean the output is constant over those 1M cycles. Also, just because there sensor is rated at a temperature does not mean its output/accuracy is unaffected by temperature. The resistance of a resistor varies WRT temperature. This is how thermistors work, though they are designed with materials that amplify these effects.</p><p>You don&#039;t need indexed encoders and you definitely don&#039;t need absolute encoders in this application. Let me explain.</p><p>When you home/zero the printer, you reset both the local coordinate system (this is what gcode uses) and the encoder count. Then, you start printing. Optical encoders simply return the fact that a count forward or a count backwards has occurred. It is up to the microprocessor to maintain a count - the encoder simply give a &quot;+1&quot; or a &quot;-1&quot; for each degree... but the microcontroller is already doing this for the steppers! When you command +10mm, for instance, that is converted to a number of steps, and the microcontroller generates pulses until the desired count is reached. Then, all the microcontroller has to do is compare the number of steps commanded to the number of counts sitting in the counter register on the microcontroller.</p><p>You can do it cheaply with optical encoders. You don&#039;t have to count microsteps. Stepper motors don&#039;t lose microsteps, just steps... even when they are being microstepped. You may not achieve the desired position precisely, but the step is not &quot;lost&quot;. It is simply not perfect due to mechanical friction/hystersis/backlash. The next step/microstep does not carry the error of the last one - the effect is only cumulative if an entire step is missed.</p><p>Does any of this make sense?</p>]]></content>
			<author>
				<name><![CDATA[elmoret]]></name>
				<uri>https://www.soliforum.com/user/221/</uri>
			</author>
			<updated>2012-12-21T06:12:42Z</updated>
			<id>https://www.soliforum.com/post/7660/#p7660</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7656/#p7656" />
			<content type="html"><![CDATA[<div class="quotebox"><cite>elmoret wrote:</cite><blockquote><p>Resistance based sensors will lose calibration with wear and temperature variations. Optical is the way to go, IMO.</p></blockquote></div><p>Yeah, thats why I listed the non-contact version of the sensor.&nbsp; According to the specs, it lists over 1 million cycles for durability and an operating temperature up to 50C.&nbsp; I don&#039;t really know for sure, but I am guessing that the ambient temperature of my 3D printer wont go above that 50C.&nbsp; Also, I will probably upgrade both my printer and/or sensor by the time I reach 1 million cycles.</p><p>Mostly, it simplifies the programming.&nbsp; 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).&nbsp; 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.&nbsp; So the encoder might be saying your position is 24 while it is really 1080 (depending on starting position).&nbsp; Now, if you turn off the machine and come back to it later, you don&#039;t know where you are in space.&nbsp; 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.&nbsp; 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.&nbsp; Let say that you have a good resolution (I have one that is 0.9 degrees / step) and a 1/16th micro stepping mode.&nbsp; At normal steps, it takes 400 steps to make one complete revolution, right?&nbsp; and with 16th micro stepping, you get a total of 6400 steps per revolution.&nbsp; 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.</p><p>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.<br />It will likely be very expensive.&nbsp; Alternatively, you have to count the number of times you make one complete revolution and do some internal math to find current position.&nbsp; Maybe even store the information in an eeprom so that you can get the position again at startup.&nbsp; You would have to store it there on every move, though, or you would lose the position if the power were lost unexpectedly.</p><p>The linear pot is just read for resistance and compared to a location table, similar to how temperatures are measured.&nbsp; Mostly, the code is already written.</p><p>Thats a little back of the napkin, but seems right as far as I can tell. What do you think?</p><p>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&#039;t know and haven&#039;t tested it).&nbsp; On the encoder side, you have more cost and slightly higher complexity but possibly greater reliability.&nbsp; I tend to like prototyping on the low cost side and upgrading as I need, though.</p>]]></content>
			<author>
				<name><![CDATA[cephdon]]></name>
				<uri>https://www.soliforum.com/user/339/</uri>
			</author>
			<updated>2012-12-21T05:39:26Z</updated>
			<id>https://www.soliforum.com/post/7656/#p7656</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7633/#p7633" />
			<content type="html"><![CDATA[<p>Or you could rip open an old optical mouse(with ball) and that will get you two axis&#039; of opto then just run then to a arduino or similar to keep track of the head position and just pol that micro for current pos.</p><p>I know there are plenty of articles around on how to do it because I was going that route with a cnc router a long time ago, sorry don&#039;t have links right now but I am sure google could find then for you.</p>]]></content>
			<author>
				<name><![CDATA[ronsii]]></name>
				<uri>https://www.soliforum.com/user/296/</uri>
			</author>
			<updated>2012-12-21T02:07:22Z</updated>
			<id>https://www.soliforum.com/post/7633/#p7633</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7630/#p7630" />
			<content type="html"><![CDATA[<p>Here&#039;s one for $39:</p><p><a href="http://www.usdigital.com/products/encoders/incremental/rotary/kit/E4P">http://www.usdigital.com/products/encod … ry/kit/E4P</a></p><p>You can get 360 counts per rotation, plenty to detect a missed step on our motors.</p><p>They also have linear encoders for $40:</p><p><a href="http://www.usdigital.com/products/encoders/incremental/modules/em1">http://www.usdigital.com/products/encod … odules/em1</a></p><p>The tape that goes in the linear encoders is like $1/inch, with ~0.05mm resolution. So I guess that&#039;s a workable solution, OP.</p>]]></content>
			<author>
				<name><![CDATA[elmoret]]></name>
				<uri>https://www.soliforum.com/user/221/</uri>
			</author>
			<updated>2012-12-21T01:52:21Z</updated>
			<id>https://www.soliforum.com/post/7630/#p7630</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7625/#p7625" />
			<content type="html"><![CDATA[<div class="quotebox"><cite>elmoret wrote:</cite><blockquote><div class="quotebox"><cite>caswal wrote:</cite><blockquote><p>I wonder what the stall dynamics on stepper motors are like, it might be detectable with watching the current draw. If it draws too much current then the motor is stalled. But steppers are nothing like normal motors.</p></blockquote></div><p>You definitely can. Industrial drivers do this:</p><p><a href="http://www.ni.com/pdf/manuals/P70530manual.pdf">http://www.ni.com/pdf/manuals/P70530manual.pdf</a> (Section 3.7)</p><p>The trouble is you need a very good model of the motor, and an sensitive monitoring circuit. We won&#039;t see it at the $400 price point, that&#039;s for sure.</p><p>You can get suitable optical encoders for about $50/axis, but you&#039;d need another microcontroller. The ATMega 644 doesn&#039;t have enough inputs left.</p></blockquote></div><p>What optical sensors would these be, might be interested for other projects.</p>]]></content>
			<author>
				<name><![CDATA[caswal]]></name>
				<uri>https://www.soliforum.com/user/351/</uri>
			</author>
			<updated>2012-12-21T01:07:30Z</updated>
			<id>https://www.soliforum.com/post/7625/#p7625</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7598/#p7598" />
			<content type="html"><![CDATA[<div class="quotebox"><cite>cephdon wrote:</cite><blockquote><p>I have thought about this quite a bit and actually purchased the non-magnetic version of this:</p><p><a href="https://www.sparkfun.com/products/9072">https://www.sparkfun.com/products/9072</a></p><p>To test the idea in one of the other printers I am building.&nbsp; 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.&nbsp; Now, that said, I don&#039;t know if it would provide the resolution we would need. Might be too much overlap between microsteps to be of real value.</p><p>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.&nbsp; That would give you a perfect lookup table and also show you if there were overlaps.&nbsp; During runtime, you just lookup the location based on the steps and use the resistance to tell you when you get there.&nbsp; Probably need to deal with acceleration/deceleration issues so that farther distances could move faster but shorter distances would move slower, etc.</p><p>Its pretty standard stuff for feedback, as I understand it.&nbsp; The upshot is, that servo based CNC machines do basically this same thing.&nbsp; 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.&nbsp; Since anything is possible with enough money, I am sure you could engineer your way out by purchasing some very expensive sensors or whatever.</p><p>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.&nbsp; 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.</p><p>That was my thought on it anyway.</p></blockquote></div><br /><p>Resistance based sensors will lose calibration with wear and temperature variations. Optical is the way to go, IMO.</p>]]></content>
			<author>
				<name><![CDATA[elmoret]]></name>
				<uri>https://www.soliforum.com/user/221/</uri>
			</author>
			<updated>2012-12-20T18:30:50Z</updated>
			<id>https://www.soliforum.com/post/7598/#p7598</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7597/#p7597" />
			<content type="html"><![CDATA[<div class="quotebox"><cite>caswal wrote:</cite><blockquote><p>I wonder what the stall dynamics on stepper motors are like, it might be detectable with watching the current draw. If it draws too much current then the motor is stalled. But steppers are nothing like normal motors.</p></blockquote></div><p>You definitely can. Industrial drivers do this:</p><p><a href="http://www.ni.com/pdf/manuals/P70530manual.pdf">http://www.ni.com/pdf/manuals/P70530manual.pdf</a> (Section 3.7)</p><p>The trouble is you need a very good model of the motor, and an sensitive monitoring circuit. We won&#039;t see it at the $400 price point, that&#039;s for sure.</p><p>You can get suitable optical encoders for about $50/axis, but you&#039;d need another microcontroller. The ATMega 644 doesn&#039;t have enough inputs left.</p>]]></content>
			<author>
				<name><![CDATA[elmoret]]></name>
				<uri>https://www.soliforum.com/user/221/</uri>
			</author>
			<updated>2012-12-20T18:28:35Z</updated>
			<id>https://www.soliforum.com/post/7597/#p7597</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7564/#p7564" />
			<content type="html"><![CDATA[<p>I have thought about this quite a bit and actually purchased the non-magnetic version of this:</p><p><a href="https://www.sparkfun.com/products/9072">https://www.sparkfun.com/products/9072</a></p><p>To test the idea in one of the other printers I am building.&nbsp; 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.&nbsp; Now, that said, I don&#039;t know if it would provide the resolution we would need. Might be too much overlap between microsteps to be of real value.</p><p>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.&nbsp; That would give you a perfect lookup table and also show you if there were overlaps.&nbsp; During runtime, you just lookup the location based on the steps and use the resistance to tell you when you get there.&nbsp; Probably need to deal with acceleration/deceleration issues so that farther distances could move faster but shorter distances would move slower, etc.</p><p>Its pretty standard stuff for feedback, as I understand it.&nbsp; The upshot is, that servo based CNC machines do basically this same thing.&nbsp; 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.&nbsp; Since anything is possible with enough money, I am sure you could engineer your way out by purchasing some very expensive sensors or whatever.</p><p>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.&nbsp; 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.</p><p>That was my thought on it anyway.</p>]]></content>
			<author>
				<name><![CDATA[cephdon]]></name>
				<uri>https://www.soliforum.com/user/339/</uri>
			</author>
			<updated>2012-12-20T02:45:12Z</updated>
			<id>https://www.soliforum.com/post/7564/#p7564</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7510/#p7510" />
			<content type="html"><![CDATA[<p>I wonder what the stall dynamics on stepper motors are like, it might be detectable with watching the current draw. If it draws too much current then the motor is stalled. But steppers are nothing like normal motors.</p>]]></content>
			<author>
				<name><![CDATA[caswal]]></name>
				<uri>https://www.soliforum.com/user/351/</uri>
			</author>
			<updated>2012-12-19T16:34:34Z</updated>
			<id>https://www.soliforum.com/post/7510/#p7510</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7505/#p7505" />
			<content type="html"><![CDATA[<p>The idea is basically a check to see if you&#039;re losing steps.&nbsp; Like the problem I had where the tip of the hot end was hitting the plastic of the last layer and being held up.&nbsp; If you&#039;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.&nbsp; Or possibly it could back up and increase speed to do the same movement.&nbsp; The idea there being that you could get past a small hump with some more force.</p>]]></content>
			<author>
				<name><![CDATA[JustSomeGuyTN]]></name>
				<uri>https://www.soliforum.com/user/96/</uri>
			</author>
			<updated>2012-12-19T16:14:08Z</updated>
			<id>https://www.soliforum.com/post/7505/#p7505</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7493/#p7493" />
			<content type="html"><![CDATA[<p>I don&#039;t think there are any optical sensors with that sort of resolution, that are affordable anyway.</p><p>I would imagine a long slider, like used on an audio desk would have the sort of resolution/tolerance required. Would also remove the need for end stop switches. The main issue is that the Atmel 644P has a 10 bit ADC, which would give a resolution of around 0.14mm, that is also based on the assumption that you have a resistance track that uses the whole range available. I.e 0v at 0mm, 5v at 150mm. Although I can&#039;t even find a slide potentiometer that long for sale, other than a couple of places that require quotes. So it is going to be expensive.</p><p>The whole point of stepper motors is to avoid this sort of feedback mechanism in the first place. As long as they are sized correctly for the application, they can rely on the fact than 1 step = 0.1mm or some other fixed amount.</p>]]></content>
			<author>
				<name><![CDATA[caswal]]></name>
				<uri>https://www.soliforum.com/user/351/</uri>
			</author>
			<updated>2012-12-19T15:28:38Z</updated>
			<id>https://www.soliforum.com/post/7493/#p7493</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: Could code be added to the firmware to test the actual position?]]></title>
			<link rel="alternate" href="https://www.soliforum.com/post/7488/#p7488" />
			<content type="html"><![CDATA[<p>What problem does this solve?</p>]]></content>
			<author>
				<name><![CDATA[cmetzel]]></name>
				<uri>https://www.soliforum.com/user/78/</uri>
			</author>
			<updated>2012-12-19T15:06:32Z</updated>
			<id>https://www.soliforum.com/post/7488/#p7488</id>
		</entry>
</feed>
