EXCELLENT post and explanation of why its the way it is John! I would nominate this going into a Wiki somewhere.
As for the different speeds causing different "phase delays", couldn't LCNC calculate the delay and advance the Z code the reqd amt. It knows the accel limit so it could calculate the delay and 'start early' w/ respect to the spindle location so the threads always stay in phase. I can see kinematics modules causing that calculation to get hairy but its straightforward on 99% of lathes I suspect. Thanks for the post again! Stephen On Fri, Jun 8, 2012 at 1:56 PM, John Kasunich <[email protected]>wrote: > > > On Fri, Jun 8, 2012, at 09:20 AM, gene heskett wrote: > > On Friday, June 08, 2012 08:58:16 AM Eric Keller did opine: > > > > > On Thu, Jun 7, 2012 at 9:39 AM, gene heskett <[email protected]> > wrote: > > > > I did notice yesterday while cutting that 4mmx0.7 thread, which btw > > > > came out real nice, that the spindle speed you start at should not be > > > > changed during the run as it will widen the cut thread, leaving a > > > > distorted profile at the root of the thread. > > > > > > I think you are asking too much of the controller. When you are going > > > after precision, there is some sacrifice to be made in speed. This is > > > especially true when the machine is less than perfect. You could > > > potentially tune the controller a little better. > > > Eric > > > > G76 is a canned cycle. It can be made to work the way I've described, > > probably in less than 10 minutes time if I had the source, which I > > haven't had since 2.2 days. I did build it once just to see if I > > could do it, most of a decade back up the log. > > > > As it is, the only way I can fix it is to un-tune the controller by > > removing the backlash comp & letting that slack be taken up in the air, > > or by writing it all as a loop that does do what needs to be done > > using G33. But that only fixes my problem, why not fix it once, for > > everybody? > > Because backlash isn't really the problem (although backlash can > make the problem worse). Re-writing the program to use G33 won't > fix it either. > > The real problem is the time (and distance) it takes the Z axis > to accelerate once the index comes around. Even a perfectly tight > machine with no backlash still has an acceleration rate limit. > > This will be easier to explain if I use a concrete example. > Apologies in advance to those who live in the metric world. > > I also apologize for the length - this is an obscure issue, so > the explanation has to go into some details... > > Assume your machine has a Z acceleration rate of 5 inches per > second per second. Also assume you are cutting a 10 threads > per inch pitch. > > First lets see what happens with a spindle speed of 240 RPM, > which is 4 revs per second. Since the pitch is 10 TPI, Z will > have to move at 4 revs/sec divided by 10 revs/inch = 0.40 > inches/second. The Z axis accel rate is 5 in/sec/sec, so it > will take 0.40 inch/sec divided by 5 inches/sec/sec = 0.080 > seconds for Z to get up to speed. In that 0.080 seconds, the > spindle will have rotated 4 revs/sec times 0.080 seconds = 0.32 > revolutions, which is 115.2 degrees. > > Now do the same calculations for a spindle speed of 300 RPM, > or 5 revs/second. Z speed is 5 revs/sec divided by 10 revs/inch > = 0.50 inches/sec. Accel time is now 0.50 inch/sec divided by > 5 in/sec/sec = 0.100 seconds, and the spindle will have rotated > 5 revs/sec times 0.100 seconds = 0.50 revolutions, or 180 degrees. > > If you rough the thread at 240 RPM and try to finish it at 300 RPM, > the finish passes will be 180 minus 115.2 = 64.8 degrees delayed > relative to the roughing passes. At 10 TPI, or 0.1000 inches per > turn, that is 0.100 inches * (64.8 deg / 360 deg) = 0.018 inches. > That will be a messed up thread. > > But this problem ONLY happens if you change spindle speed > between passes. If you keep the speed the same, the delay angle > is also the same, and the thread will be fine. > > When G33 spindle synchronized motion was first added to > LinuxCNC, it didn't have this problem. It had a worse problem, > one that would show up even if you didn't change the spindle > speed. > > The original G33 had an "internal" Z position reference that > would begin moving at the proper speed to cut the desired pitch > the instant that the index pulse arrived. Because this internal > Z started moving instantly, it didn't matter how fast the spindle > was turning - the thread would always be right. Unfortunately, > real motors can't accelerate instantly, so the "external" Z > command that actually runs the motor still needed to have > acceleration limits applied to it. > > Lets work through what happened, using the same machine and > thread as in the previous calculations, at 300 RPM. > > As soon as the index arrives, the internal Z starts moving at > 0.50 inches/sec. The external Z has accel limiting, and we've > already calculated that it takes 0.100 seconds to reach 0.50 > inches/sec. The average speed during that accel is 0.25 > inches/sec, so the distance traveled is 0.100 times 0.25 = > 0.025 inches. Meanwhile, in the first 0.100 seconds, the > internal Z has been moving at a constant 0.50 inches/sec, > and has moved 0.100 times 0.50 = 0.050 inches. > > That means the external Z is lagging behind the internal one > by 0.025 inches. So LinuxCNC tells it to keep accelerating. > > Over the next 0.0707 seconds, the internal Z keeps accelerating > at 5 inches/sec/sec, reaching a speed of 0.8535 inches/sec. > During this 0.0707 second period, it averaged 0.677 inches/sec, > and it moved 0.0475 inches. Meanwhile the internal Z is still > cruising along at 0.50 inches/sec, and moved 0.035 inches. > So during this 0.0707 seconds, the external Z gained 0.0125 > inches on the internal one - half of the distance it needed > to make up. > > But now it is moving too fast. So LinuxCNC tells it to slow down. > For the next 0.0707 seconds, it decelerates at 5 inches/sec/sec, > finally ending up back at 0.50 inches/sec, where it needs to be. > The average speed for this period is 0.677 inches/sec, and > the distance traveled is 0.0475 inches, while the internal > Z only moved 0.035 inches. So external Z has finished > catching up, both position and speed are matched, and we can > begin the cut. > > This whole process took 0.2414 seconds from index arrival to > the point where it was safe to begin cutting. That is more > than twice as long as it takes to accelerate to the desired > speed. It also takes more than twice the Z distance, which > might mean the first part of the thread is the wrong pitch > if there isn't enough of an air cut. > > The real problem is that the peak Z axis speed was 0.8535 > inches per second, even though the thread we are cutting > only needs 0.50 inches per second. > > What if we are running very close to the machine limit? > Suppose the machine is only capable of 0.52 inches per sec. > In theory we should be able to cut the thread at 300 RPM, > since we only need 0.50 inches/sec. Lets walk through > one more set of numbers. > > For the first 0.100 seconds things are exactly the same. > External Z accelerates to 0.50 inches/sec, and falls > behind internal Z by 0.025 inches. > > In the next 0.004 seconds, external Z reaches its top speed > of 0.52 inches/sec, and stops accelerating. During that > time, the average speed is 0.51 inches/sec, and it moves > 0.00204 inches. Meanwhile internal Z moves 0.00200 inches, > so external Z gains 0.00004 inches. Since it started out > 0.025 inches behind, it now 0.02496 inches behind. > > Now external Z is cruising along at 0.52 inches per second. > It is slowly catching up to internal Z which is only going > 0.50 inches per second. After 1.246 seconds of this, it > has caught up to within 0.00004 inches of where it should > be, and starts slowing down. As it slows back down to 0.50 > inches/sec, it makes up that final bit of distance. > > In this example, it takes 1.354 seconds and 0.677 inches > of travel for the Z axis to come into sync and be ready to > cut a proper thread. Compare that to the 0.100 seconds > and 0.025 inches that it needs simply to accelerate to > the proper speed. > > I first observed this problem on my lathe a few months > after G33 was added. I could hear strange noises as the > motor first accelerated to higher than the proper speed, > then decelerated again. I also got bad threads on the > end of my part, because the sync process was using a lot > more Z distance than it should. I described the problem > to Chris Radek (who implemented G33) and he worked out > the following fix, which is in there now: > > At the beginning of each G33 pass, LinuxCNC uses the spindle > speed and the machine limits to calculate how long it will > take Z to accelerate, and determines how many degrees the > spindle will rotate during that time. It then adds that > angle to the index position and computes the Z position > using the corrected spindle angle. That means that Z will > reach the correct position just as it finishes accelerating > to the proper speed, and can immediately begin cutting a > good thread. Z will never have to move faster than you > would expect given the spindle speed and thread pitch. > > The downside of this fix is that the offset is different > if the spindle speed is different. I was worried about > that at the time, and argued with Chris about it. But > I couldn't come up with a better way to solve the problem. > It has been at three or four years now (maybe longer?), > and this is the first time someone has been bitten by > this particular behavior, so I think Chris was right. > > -- > John Kasunich > [email protected] > > > > ------------------------------------------------------------------------------ > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
