Hello Guest it is September 17, 2019, 09:15:56 AM

Author Topic: Problems threading on the lathe  (Read 330106 times)

0 Members and 1 Guest are viewing this topic.

Offline Hood

*
  •  25,849 25,849
  • Carnoustie, Scotland
    • View Profile
Re: Problems threading on the lathe
« Reply #240 on: April 20, 2009, 04:49:17 PM »
Is this PP only as I have an encoder, I have the A+ A- B+B- I+I- all connected to Mach via port 3 on the SS.
Hood

Offline ART

*
  • *
  •  1,698 1,698
  • Tough as soggy paper.
    • View Profile
Re: Problems threading on the lathe
« Reply #241 on: April 20, 2009, 08:05:50 PM »
Hi Hood:

 Yup, Printer port only,. the SS really doesnt need this level of correction I dont think.
Thogh if it works Ill pass on the greag exactly what Im doing in case he'd liek to duplicate
the method.

Art

Offline John S

*
  •  111 111
  • Nottingham England
    • View Profile
Re: Problems threading on the lathe
« Reply #242 on: April 20, 2009, 08:25:13 PM »
Hood,
i was under the impression that the ab channels weren't working on the SS for threading ?

John s.

Offline Hood

*
  •  25,849 25,849
  • Carnoustie, Scotland
    • View Profile
Re: Problems threading on the lathe
« Reply #243 on: April 21, 2009, 01:56:03 AM »
Art, Ok thanks.

John
 No they dont work for threading, the Index pulse can be used but at this time that is all. Greg was thinking that at some point he might be able to get the Spindle and Z axis in sync with the full encoder for things such as rigid tapping or even just normal G95 so I have them hooked up just in case ;)
Hood

Offline simpson36

*
  •  1,374 1,374
    • View Profile
Re: Problems threading on the lathe
« Reply #244 on: April 21, 2009, 04:05:46 AM »
Art,

I have a disk on my spindle and I am am willing to drill more holes in it to test your driver. How many holes (slots) and how mch larger does the main slot have to be? You can answer in ms if that's what Mach is looking at.  I'll calculate the appropriate slot size for my disk dia. and RPM.


I also am expecting a servo motor, encoder and Gecko 320 to arrive today. I plan to use it as the spindle motor for my 4th axis, so testing is as a spindle will be perfect for my purposes.

Serendipitously, I am testing a newly designed breakout board and PWM speed controller from Peter Homann as I write this. So far I am just stressing it with a looped program in Mach3, but it is dead rock steady on the output. I was unable to achive this with either his earlier DC06 or the CNC4PC speed controllers.

To anyone reading this, please note that the problem might have been with noise in and around my mill, and not the fault of the speed controllers, so I'll need to get the new setup installed in order to really know if the issue is resolved, but so far so good.

I will have a second parallel port in a couple days to hook up the second breakout to the computer. That will give me a bunch of extra pins to use.









« Last Edit: April 21, 2009, 04:07:57 AM by simpson36 »

Offline ART

*
  • *
  •  1,698 1,698
  • Tough as soggy paper.
    • View Profile
Re: Problems threading on the lathe
« Reply #245 on: April 21, 2009, 07:47:20 AM »
Hi:

   The idea of having one slot larger than the others is not implemented as before. In this current testing
you need to have two inputs. One from the TIMING input, which simply has the sensor looking at slots,
and one for INDEX.

   An encoder on Encoder 3 can replace the TIMING input, but the INDEX input is needed either way. So
the slotted wheel should have all slots sized the same. As to the number of slots? Hard to say. Steve willl
be testing , as I think John will , with a 90 slot wheel. The way the driver is written it will count the slots
and adjust its reading based ont he number of slots it reads, the plugin will display a DRO showing how many
slots have been seen per rotation, it should be rock steady unless theres a problem.

   The number of slots will affect maximum speed available. For example, Craig recently reported he can read up to
240,000RPM with just the index pulse, so a 90 slot wheel will likely read 2666RPM as a maximum speed all things
considered. If you use a 64 slot wheel, then about 3750 woudl be the theoretical max.

  If you attempt to use a 2000count encoder, then Id expect 120RPM is the max. SO its important
to try to use as few slots as you think you can, but there are things to be considered.

  I wrote this test assuming that 64 slots woudl be the minimum slot number, which would make the system sense
speeds 64 times per rev. This shoudl in theory make things track 64 times better than before. Having less slots will
make the correction average over more than 1 rev, which may or may not work, we'll need data to see.

   Currently, the test only tests the RPM sensing for stability. Once thats done Ill implement the correction of slowdown.
There are a couple ways I can do that, with instant time evaluation on a per slot basis, or a rolling avergage of slot times.
Im still not sure which will be best. PResently, the RPM is very stable, on mine at 0.2RPM at 400RPM, but the driver is using
a rolling 64 slot average to make it this stable. Wether we use the same 64 slot rolling average as a ratio to a locked average at
thread start, OR use a instant 1 slot time against that rolling average time is the question. Secondarily the issue will be if either
will track toghtly enough to make a good trhead over long time domains is important.

 I can guarentee nothing here. What we know is that short threads seem fine using 1 rev count time locked at thread start,
and slowing based on instantaneous following 1 slot times as a ratio. Thats what we've been using. But the variability of those times
seems to force a slow time degradation, its my hope that by making the system time average out the errors that everything will
lock in much tighter. It will be interesting to see. The idea of a dual ratio bresenham division ration for control came to me a few
months ago, the numbers seem to crunch well and Im very curious to see if it works as well in reality as it does in theory.

  Since most will thread at speeds no faster than 1000RPM, a 90 slot wheel seems ideal, or a 25 line encoder (100 counts per rev),
I just wouldnt increase it much higher than 250 counts per rev myself, as that will limit you to about 1000RPM.

   Now those numbers are all at 25Khz kernal. At 45Khz your maximums shoudl be almost double the stated values.

For those curious as to the issue, or why EMC for example seems to have a more exact responce, Ill explain just how they do it, vs
how I do it.

 In EMC, the trajectory planner runs at a servo rate that is in real time. As one slot passes by the system calculates how far the Z
should have moved in that time frame, and advances it by that amount. This is exact and real-time. But in Mach3, the motion is already
precalculated and buffered for up to 2 seconds. There is no time machine that allows me to go back and correct the time. SO, what I have
always done is check the rotation time, and knowing the time the pulses were prepared for, I slow the stream by the average differential,
and this works well for short threads. But over time an error is creeping in. Its my hope that by averaging out the slot times I get a much more
representative time measurement without the small variations caused by some sensors or systems that fluctuate slowly. The error seems caused
by random fluctations in the time measurement, thus the 5RPM variability shows in the display. Since I now get a very exact reading, its should be
possible for m to better identify the slowdown caused by the spindle itself, and negate the slowdown caused by system responce.

  In this method you cannot actually stop the spindle, it will correct down to a very slow speed , perhaps 90% slowdown, but stopping would
cause a stream overshoot ( but then that was always so. ). The overshoot previously could be as much as 1 rev, but in the 90 slot scenario, the
overshoot shoudl be 1 slot or so, which woudl be trivial in the case of 90 slots per rev at slow speed. If it all works I may be able to set a stop point
where the Z motion stops, and picks up again after passing an index point at a certain minimum speed, but thats in the future if all works well.

  This is all very experimental, hasnt been done before as I can tell, so we're in a very grey area. If it works in reality as well as on paper, we'll
be real happy, if not... well, we'll have a steady RPM display and the code will allow for other toys that dont require the exactitude of threading.
Plans are in the works to use this timing method to do other things, such as sense stalled steppers and auto corect positions while slowing the system
to allow motors to catch up. A type of closed loop control. Who knows, its only though such experiments that I can guage how usefull such
timing technology is.  :)

Thx
Art


   
 

 
« Last Edit: April 21, 2009, 07:50:07 AM by ART »

Offline simpson36

*
  •  1,374 1,374
    • View Profile
Re: Problems threading on the lathe
« Reply #246 on: April 21, 2009, 12:16:12 PM »
Sounds like you are on a good track. Closed loop would definately move Mach to a whole new level.

I cut aluminum mostly and run the spindle over 6,500 RPM with small cutters (up to about 3/8"). I would want to thread as fast as the axis movement and rigidity and power of my little mini machine will allow. I don't know yet where that would be, but certainly well over 1,000RPM

The leap from one slot to 90 slots seems immense. If the objective is single point threading, that seels like ovekill to me. What would be the practical benefit of 4 degree azimuth accuracy in terms of the possible effect on a thread profile? The error would be so minute as to be beyond the capability of the machine tool, I would think.

From the photos of threads that I saw on the forum, there appears to be an max error of something like .030 on a 10TPI thread (that's a guess). While it corrects over time, it is still unacceptable to be sure, but if you cut that by a factor of say 30 times, you are now looking at .001 deviation constrained to an individual thread. If my guess is close, then 30 slots would seem a potential compromise between accuracy and spindle speed. And that is just the theoretical improvement. The improvment in practice would be much greater because the correction could take place within one revolution (or even much less) and thereby eliminate both cumulative and averaged error.

It appears you are leaning toward giving the user choices in the number of slots. That would be ideal.

I am planning to build another 4th axis, this time with servo power (which arrives today). The servo is 4,000 RPM with a 300 line encoder, but I will likely again gear it down as before by 3.6:1 to the spindle since it is a small motor. My intension was to trick Mach into continuously driving the A axis as if it were a spindle as I did with the stepper powered indexer, but what you are wokring on sounds like the proper permanent solution.

I make my own timing gear so it would be a simple natter to make it a bit wider and cut a groove in one end deeper than the timing teeth and read directly off the teeth. The same slot could be a bit deeper yet and have a single deep 'tooth' cut that only the index sensor would see. 

This is primarily a hobby for me and I like to tinker. My rig is availble if you want anything unusual designed or tested. 


« Last Edit: April 21, 2009, 12:24:53 PM by simpson36 »

Offline ART

*
  • *
  •  1,698 1,698
  • Tough as soggy paper.
    • View Profile
Re: Problems threading on the lathe
« Reply #247 on: April 21, 2009, 01:21:22 PM »
Hi :

 Yup, I do want the slots to be variable, and Id use 30 without any hesitation, or even 10  ( or 4.. ), but I suspect any accumulative error
will be better corrected by more slots, while more slots will limit RPM more and more, so its all a tradeoff, a fast speed user may decide that
8 slots is fine, whlie a slower lathe may be better off with 90 or 100.

  In the end, if it all works I may just add a DRO so the user can tell MAch3 how many slots there are, in which case th eindex pulse woudl no longer
be required as long as the user is SURE that no slot ever goes missing.. I can then simply start counting from an arbitrary position and count the slots
to know where I am. The advantage of the index slot is simlpy that I can count the slots and double check that noe went missing.. Not really required
if we fnd the slots alone are extrememly stable and never get lost.

  Ill add code to determine that soon, and youll be able to see if , over time, any single slot was missed, if none are after several hours, and everyone finds
that to be true, the requirement for the second sensor for index will go away.

Thx
Art
 
Re: Problems threading on the lathe
« Reply #248 on: April 22, 2009, 04:17:49 AM »
Hi Art,

Thanks for all this work. My ORAC had an index and 60 (I think) slot wheel which I replaced for a single slot wheel for use with Mach3.

(BTW, I've not experienced any noticable pitch error with my setup so far but only tried up to 30mm long threads - the fit felt perfect along their length in a nut. I must be lucky with my old Pentium 3, 1.0 GHz, win2k, NEC PC... My RPM is rock steady (when not cutting).)

The benefit of a single slot was I could re-start a thread easily and shave a little more off to fit, so long as I did not shut the machine down. If you do away with the index, I think that would be impossible? Or at least difficult?

I like the idea of multiple slots to ensure a perfect thread pitch but also an index for re-starting. Trouble is, I only have one input available for the spindle unless I disconnect something else...

If you can make these things optional, I think that would be a good way forward so that the user can decide the compromises.

Just thoughts!

Regards,

Woody.

Offline simpson36

*
  •  1,374 1,374
    • View Profile
Re: Problems threading on the lathe
« Reply #249 on: April 22, 2009, 04:57:52 AM »
I would vote for leaving the index available for the purpose of 'homing' the spindle, whether the spindle is powered by a regular motor or a servo.

For example if I had a part in a hex shaped collet holder and that in turn was held in the chuck. If I had to remove the holder from the chuck to do a secondary operation on another machine and then return it to the chuck a couple days later, I may need to index it back to the same starting point. If the machine was off in the interim, I would have lost home.

Also sometimes it is neccessary to return a threaded part to cut the threads a little deeper or longer as mentioned by WoodyCam.

My mill locks the spindle with a pin for losening the drawbar. It would be very convienent if the mill spindle stopped right at the lock position every time, rather than randomly.

There are other ways to accomplish all of the above, but it would be faster and probably more accurate if the spindle could home itself.

Another wish list item would be a 'continuous run' mode for a servo motor. I *think* that could be accomplished with a script or pehaps a brain . . .  heven't gotten that far yet, but if it was a planned feature addition, there would be no need to pursue a workaround.

BTW, received my little servo and Gecko drive yesterday. It took about an hour of tinkering to get it humming along.