Re: [Emc-users] A axis and spindle
On 5 July 2012 05:18, Jon Elson el...@pico-systems.com wrote: Rollover is a non-issue within the lifespan of most machines Not necessarily. Assume 3000 RPM and a 1000 cycle/rev encoder. Typical 24-bit encoder counters will roll over on a bit over a minute (16 mil/12 mil). That gets overflowed to 32 bits, so it would take 358 minutes to overflow the 32-bit count. I think all the encoder counters on LinuxCNC currently use a 32-bit count internally. Having checked, it seems you are correct. The software stepgen uses 64-bit accumulators, and the Mesa Resolver module uses a 64-bit accumulator too. For some reason I thought all the other encoder-like functions were using 64 bit internal representation. I can't help feeling that they ought to. The software stepgen holds position data in a floating-point (double) representation which will lose precision rather than wrap as the counts increase as long as the 32-bit counter wrap is handled carefully. I think I worked out that it would take an awfully long time for the encoder position to become significantly innaccurate. (assuming that we want a position accuracy of 0.0001 and a float has 15 places of decimal precision, then the notional axis can travel 10^11 notional inches before not being able to represent 0.0001. At a travel rate of 1000 in/min that is 190 years. My initial impression is that the software encoder does not handle the wrap as well as it might. It probably ought to add delta_counts * scale to the position, not recalculate the position from total counts. The magic of twos-complement means that calculating deltas on signed integers handles the wrap automatically. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
On 4 July 2012 22:08, andy pugh bodge...@gmail.com wrote: There is (somewhere) a config for aligning a milling spindle for tool change, so it's a solved problem. I just couldn't find it. Ah, here it is. (Note that we currently have two almost-identical threads on this subject) http://www.linuxcnc.org/docs/html/man/man9/orient.9.html -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
On Thursday 05 July 2012 08:42:02 andy pugh did opine: On 5 July 2012 05:18, Jon Elson el...@pico-systems.com wrote: Rollover is a non-issue within the lifespan of most machines Not necessarily. Assume 3000 RPM and a 1000 cycle/rev encoder. Typical 24-bit encoder counters will roll over on a bit over a minute (16 mil/12 mil). That gets overflowed to 32 bits, so it would take 358 minutes to overflow the 32-bit count. I think all the encoder counters on LinuxCNC currently use a 32-bit count internally. Having checked, it seems you are correct. The software stepgen uses 64-bit accumulators, and the Mesa Resolver module uses a 64-bit accumulator too. For some reason I thought all the other encoder-like functions were using 64 bit internal representation. I can't help feeling that they ought to. Probably. But at what cost in time used? Enough of this hunt for perfection and the code begins to bloat and slow. On this box its largely moot as it is a 64 bit box, but... The software stepgen holds position data in a floating-point (double) representation which will lose precision rather than wrap as the counts increase as long as the 32-bit counter wrap is handled carefully. I think I worked out that it would take an awfully long time for the encoder position to become significantly innaccurate. (assuming that we want a position accuracy of 0.0001 and a float has 15 places of decimal precision, then the notional axis can travel 10^11 notional inches before not being able to represent 0.0001. At a travel rate of 1000 in/min that is 190 years. I'm not inclined to push the panic button. The machine will have worn itself out to a lot more slop than .0001 long before that. Shrug. My initial impression is that the software encoder does not handle the wrap as well as it might. It probably ought to add delta_counts * scale to the position, not recalculate the position from total counts. The magic of twos-complement means that calculating deltas on signed integers handles the wrap automatically. Humm, but what happens when 'scale' is itself a floating point value? My ancient mind says there will be a visible loss of precision at the rollover point. I'll get me coat. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene is up! Put cats in the coffee and mice in the tea! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
On Thu, Jul 5, 2012, at 01:08 PM, andy pugh wrote: My initial impression is that the software encoder does not handle the wrap as well as it might. It probably ought to add delta_counts * scale to the position, not recalculate the position from total counts. The magic of twos-complement means that calculating deltas on signed integers handles the wrap automatically. I respectfully disagree on this part. Counts are counts, and integers can be accumulated indefinitely with no error. Floating point math can be imprecise, and accumulating counts times scale, where scale is a float, could result in accumulating errors. Thinking about it a bit more, it definitely will result in accumulating errors. Suppose your scale is 3 counts per inch. So the amount you want to add to the accumulator each count is 0.3. In either scheme there will be some error, since that number cannot be exactly represented as a float. Floats have a resolution of 24 bits (the other 8 are used for the exponent). So the basic error will be 1 part in 2^24, which isn't bad (for example, 3.6 micro-inches on a 60 long travel). If you are accumulating counts as an integer, and then multiplying by the scale factor, the error will always be 1 part in 2^24, regardless of how far you travel. But it can be a lot worse if you are accumulating chunks of 0.3 as floats. Suppose the axis has moved 35 inches. On the next count, you will be adding 0. to 35.. The 0.33 value starts out with 2^24 resolution, but it gets shifted right during the add, because the exponents have to match before you can actually perform the addition. In this case, the shift is 20 bits, leaving the scale factor with only 4 bits of precision. Working the example in decimal floating point notation makes it easy to see. Floats have about 7 decimal digits of resolution. So the scale factor would be represented in decimal as 3.33e-5. The current axis position is 3.50e+1. To add them together, the scale factor gets shifted right 6 digits, so it becomes 0.033e+1. So on every count, you miss 1% of your actual travel. The situation gets much worse if you travel further. Consider what happens when the axis reaches 1000 inches (in the decimal case). Axis position is 1.00e+3, so the increment of 3.33e-5 needs to be shifted 8 positions. The result is 0.00e+3. Adding (or subtracting) that from the accumulator will have no effect, so the output of the encoder block will never change - even if you start moving back towards zero. It will simply be stuck. By comparison, if you are accumulating integer counts and then converting to float, you might reach a point where you don't see a change in the float value on each count, but the counts _are_ being recorded, and the float output will continue to increase every couple of counts, when its resolution permits. And when you reverse and start moving back towards the origin, the accumulator will correctly track the position. There is another issue, which could be considered good, bad, or irrelevant, depending on your point of view. HAL allows anything (including scale) to be changed at any time. Suppose you move an axis for a while, then change scale, move it some more, then change scale back to the original value. The current implementation will have a position jump when you change scale. But it will always know where it is, because it is accumulating counts. If you change scale back to the original value, your position will be correct, even if you moved while the scale was wrong. The proposed implementation avoids the position jump when scale changes, but if you move after changing the scale, you lose track of your original position. The accumulator now contains some motion at the original scale factor, and some motion at the new scale factor. Avoiding the jump might be considered good. Losing your absolute position is bad. And the whole issue is probably irrelevant since few people change scale on the fly. But I prefer the current implementation, and would think hard before changing it. If there is a concern about rollover, then change the accumulator to 64 bits. But it should still be an integer recording counts, not a float or double recording scaled length increments. -- John Kasunich jmkasun...@fastmail.fm -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
On 5 July 2012 15:13, John Kasunich jmkasun...@fastmail.fm wrote: It probably ought to add delta_counts * scale to the position, not recalculate the position from total counts. I respectfully disagree on this part. Counts are counts, and integers can be accumulated indefinitely with no error. Floating point math can be imprecise, and accumulating counts times scale, where scale is a float, could result in accumulating errors. I agree with your disagreement. The problem you describe is likely to particularly acute in cases where someone has a 1:3 pulley ratio and only bothers to type in the scale factor to as many significant figures as they feel necessary. What does work (and what the resolver module does) is to consider the counts delta of the 16-bit data from the Mesa card and add that to a 64-bit accumulator, then multiply that by the scale. There is still a problem if the scale has fewer significant figures than the total revs. For example engraving text, machining an OD then going back to underline the text might not work. Re-indexing and zeroing the encoder counts is likely to work better. It is worth noting that zeroing the encoder doesn't change the actual counts (rawcounts) -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
John Kasunich wrote: I respectfully disagree on this part. Counts are counts, and integers can be accumulated indefinitely with no error. Floating point math can be imprecise, and accumulating counts times scale, where scale is a float, could result in accumulating errors. snip If you are accumulating counts as an integer, and then multiplying by the scale factor, the error will always be 1 part in 2^24, regardless of how far you travel. Yes, if what we are talking about is the rolling over of a smaller counter (possibly in hardware) to a wider position value, then a raw count value has to be maintained as an integer, and converted to float every cycle. Different floating point formats will have different thresholds of minimum guaranteed precision, but accumulating a series of products will be guaranteed to eventually accumulate significant error. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
andy pugh wrote: I agree with your disagreement. The problem you describe is likely to particularly acute in cases where someone has a 1:3 pulley ratio and only bothers to type in the scale factor to as many significant figures as they feel necessary. Nope, doesn't really make any difference. There are numbers that can be exactly represented in floating point. These are combinations of power of two fractions, such as 1/2, 1/4, 1/8, etc. But, there are many more values that have no EXACT representation, such a the 1/3 you mention. This is not a great problem for a one-time computation, the error is quite small, depending on the number of mantissa bits in that FP format. BUT, there will be error EVERY TIME the computation is performed. If you do this at the servo rate of 1 KHz, you are summing this tiny error a thousand times a second, it won't take long at all for this to accumulate to a large and totally unpredictable magnitude. In other words, one day the errors may nearly all cancel out, the next day, when the machine sits in a different position for a few minutes, the error could become vast. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
On 5 July 2012 18:12, Jon Elson el...@pico-systems.com wrote: I agree with your disagreement. The problem you describe is likely to particularly acute in cases where someone has a 1:3 pulley ratio and only bothers to type in the scale factor to as many significant figures as they feel necessary. Nope, doesn't really make any difference. There are numbers that can be exactly represented in floating point. These are combinations of power of two fractions, such as 1/2, 1/4, 1/8, etc. But, there are many more values that have no EXACT representation, such a the 1/3 you mention. This is not a great problem for a one-time computation, the error is quite small, depending on the number of mantissa bits in that FP format. BUT, there will be error EVERY TIME the computation is performed. Perhaps I wasn't clear enough in saying that I now realise that computing a new floating-point delta every time is a stupid idea. I was talking about a different issue, that a million turns * 0.33 will have a huge error even if it looks like typing the ratio to 6 decimal places in the HAL file looks like it ought to be OK, and probably would be for a typical linear axis. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
On 4 July 2012 15:00, Kasey Matejcek someo...@lkm.bz wrote: I want to be able to turn down the part then change the tool to drimal type cutter tool and cut a pattern into the peace with one gcode file Is this possible? It is possible. It isn't especially easy. It is probably easier with servos than with steppers though. The solution is probably to have two separate PID controllers in the HAL file, one taking a command from axis.3.motor-position-cmd and one taking an input from motion.spindle-speed-out (pin names from memory, not from the docs). You would then use a mux2 HAL component to send one or other of the PID outputs to the PWM generator. You could switch the mux2 on the basis of motion.spindle-on. Then M3 / M4 would disable A-axis control. The main complication to this simple scheme is that the A-axis PID will try to unwind all the lathe-mode rotations when you switch to lathe-mode. To counteract this you would need to force the encoder.N.index-enable pin high when the mode changes. This will take a slightly complex array of HAL functions, an edge-detector (HAL oneshot) to set the index, and a HAL tristate_bit to set the encoder index-enable. You would probably (this is untested) simply setp the tristate-bit.0.in to 1, and net the oneshot output to tristate-bit.0.enable. The behaviour would then be that the axis would move in A-word control until an M3 or M4, at which point the mux would direct the speed PID to the PWM generator. On M5 the mux would switch to the old A-axis position control, the oneshot would trigger, loading a true to the encoder.N.index-enable pin. Because the spindle is many turns away from it's required position the A-axis PID controller will be maxed out, so the spindle will do at least one turn past the index. When it passes the index the encoder counts will go to zero, the PID will no longer be saturated, and the spindle should return to the last commanded angular position. http://www.linuxcnc.org/docs/html/hal/intro.html http://www.linuxcnc.org/docs/html/man/man9/mux2.9.html http://www.linuxcnc.org/docs/html/man/man9/oneshot.9.html http://www.linuxcnc.org/docs/html/man/man9/tristate_bit.9.html -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
andy pugh wrote: The behaviour would then be that the axis would move in A-word control until an M3 or M4, at which point the mux would direct the speed PID to the PWM generator. On M5 the mux would switch to the old A-axis position control, the oneshot would trigger, loading a true to the encoder.N.index-enable pin. Because the spindle is many turns away from it's required position the A-axis PID controller will be maxed out, so the spindle will do at least one turn past the index. When it passes the index the encoder counts will go to zero, the PID will no longer be saturated, and the spindle should return to the last commanded angular position. And, how to do this without causing a momentary huge following error that either causes a following error abort or a servo amp trip is not clear. I think it needs some kind of gradual gain change to allow the servo to catch up gradually before going to full gain. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
On 4 July 2012 21:00, Jon Elson el...@pico-systems.com wrote: And, how to do this without causing a momentary huge following error Ah, yes. Good point. Given that, I think it has got to the point where a custom HAL module is called for which mediates the position feedback. (though another mux to short-circuit the feedback would work, connecting axis.M.pos-feedback to either position-command or encoder-position as required. (possibly triggered by a timedelay component). The spindle doesn't have an f-error problem. I guess you could just ignore f-error on A too, and short-circuit the feedback. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
I dont know how this is done on newer lathes but Ive seen older ones with an electric clutch on the spindle that engages and a seperate servo motor that does the milling or positioning moves then disenguages for normal lathe turing. Could an encoder be put on a the servo(except for the index pulse) this way the servo encoder would not have the wrap up from turning operations as it would be disengaged most of the time? I am sorry that this is probably not helping this person but I am thinking about doing this to a lathe of mine and this topic reminded me of my question Terry - Original Message - From: Jon Elson el...@pico-systems.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Cc: Sent: Wednesday, July 4, 2012 3:00 PM Subject: Re: [Emc-users] A axis and spindle andy pugh wrote: The behaviour would then be that the axis would move in A-word control until an M3 or M4, at which point the mux would direct the speed PID to the PWM generator. On M5 the mux would switch to the old A-axis position control, the oneshot would trigger, loading a true to the encoder.N.index-enable pin. Because the spindle is many turns away from it's required position the A-axis PID controller will be maxed out, so the spindle will do at least one turn past the index. When it passes the index the encoder counts will go to zero, the PID will no longer be saturated, and the spindle should return to the last commanded angular position. And, how to do this without causing a momentary huge following error that either causes a following error abort or a servo amp trip is not clear. I think it needs some kind of gradual gain change to allow the servo to catch up gradually before going to full gain. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
It is really a C axis lathe being described I believe (spindle rotates about Z), and a C axis live tooled lathe is such a mainstream machine in the industrial world that it seems a shame not to have a robust, well-thought-out LinuxCNC configuration for this application. My thought is that it should use the C encoder all the time, but with a velocity mode for normal turning, threading, and CSS. Encoder rollover would be needed, but 64 bits should handle an awful lot of revolutions of the spindle. -- Ralph From: andy pugh [bodge...@gmail.com] Sent: Wednesday, July 04, 2012 1:15 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] A axis and spindle On 4 July 2012 21:00, Jon Elson el...@pico-systems.com wrote: And, how to do this without causing a momentary huge following error Ah, yes. Good point. Given that, I think it has got to the point where a custom HAL module is called for which mediates the position feedback. (though another mux to short-circuit the feedback would work, connecting axis.M.pos-feedback to either position-command or encoder-position as required. (possibly triggered by a timedelay component). The spindle doesn't have an f-error problem. I guess you could just ignore f-error on A too, and short-circuit the feedback. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
On 4 July 2012 21:37, Ralph Stirling ralph.stirl...@wallawalla.edu wrote: My thought is that it should use the C encoder all the time, but with a velocity mode for normal turning, threading, and CSS. Encoder rollover would be needed, but 64 bits should handle an awful lot of revolutions of the spindle. Rollover is a non-issue within the lifespan of most machines (5 million years at 3000rpm and 2048 counts per rev) There is (somewhere) a config for aligning a milling spindle for tool change, so it's a solved problem. I just couldn't find it. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
andy pugh wrote: Given that, I think it has got to the point where a custom HAL module is called for which mediates the position feedback. Yes, that sounds right. The spindle doesn't have an f-error problem. I guess you could just ignore f-error on A too, and short-circuit the feedback. Right, going from axis to spindle shouldn't be a big problem, just freeze the encoder position so it doesn't think C is moving. But, going from spindle mode to axis mode is trickier, as it has to gently engage the position servo. When the spindle is being positioned, technically is is a C axis, as in rotating parallel to the Z axis. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
Terry Christophersen wrote: I dont know how this is done on newer lathes but Ive seen older ones with an electric clutch on the spindle that engages and a seperate servo motor that does the milling or positioning moves then disenguages for normal lathe turing. Could an encoder be put on a the servo(except for the index pulse) this way the servo encoder would not have the wrap up from turning operations as it would be disengaged most of the time? I am sorry that this is probably not helping this person but I am thinking about doing this to a lathe of mine and this topic reminded me of my question If you need really rigid holding of the spindle then what you describe is probably the only way to do it on a home shop budget. If it is for very light work, then maybe a single motor can do it without it being massive. Then, it mostly becomes a software problem. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] A axis and spindle
andy pugh wrote: On 4 July 2012 21:37, Ralph Stirling ralph.stirl...@wallawalla.edu wrote: My thought is that it should use the C encoder all the time, but with a velocity mode for normal turning, threading, and CSS. Encoder rollover would be needed, but 64 bits should handle an awful lot of revolutions of the spindle. Rollover is a non-issue within the lifespan of most machines (5 million years at 3000rpm and 2048 counts per rev) There is (somewhere) a config for aligning a milling spindle for tool change, so it's a solved problem. I just couldn't find it. Not necessarily. Assume 3000 RPM and a 1000 cycle/rev encoder. Typical 24-bit encoder counters will roll over on a bit over a minute (16 mil/12 mil). That gets overflowed to 32 bits, so it would take 358 minutes to overflow the 32-bit count. I think all the encoder counters on LinuxCNC currently use a 32-bit count internally. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
