Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: panaceabeachbum on September 11, 2008, 10:41:28 PM
-
I hooked up the encoder on my big lathe to the breakout board today and am having some problems . The encoder is a tamagawa qaud with index pulse , I have the index hooked to pin 12 input on my breakout board and I am getting a very accurate RPM reading on screen. The lathe is new with ball screws and no measurable backlash . Threading tool is Carmex IP carbide threading tool , held very rigidly in VDI 30 tool holder.
I am using threading files that run perfectly on my other two lathes , both with ball screws and mach . Everything seems to be working as it should but 4 out of 5 parts I thread at come out looking like I have rammed the tool holder into them . Everything will be running well and on the 5 -6 pass it I will get a shhh sound from the tool and the threads are pretty much wiped out . I have cut some where around 70 sets of thread today and might have 5 that are acceptable. I have cut thousands of threads on my other two lathes and just unsure whats going wrong here .
I have tried adjusting the j value from .001 to .010 , changed the number of spring passes, tried two diff types of coolant , synthetic and oil based , trans fluid , trichlor , and gtx cutting fluid , still no luck , on at least two of 6-12 passes when cutting .05 pitch (20 tpi) threads the tool will just kind of wipe all the threads out .
Are there some params I need to look at or adjust in the software that relate to the index pulse?
I think I have checked all the mechanical and wiring issues and have tried to eliminate the cutting tools, cutting fluids , feeds and speeds as possible problems .
Any help or thoughts greatly appreciated RT
-
I was told early on that the index pulse from an encoder was most likely WAY to short of a duration to work reliably with Mach.
200 microsecond minimum pulse needed.
Might reduce spindle speed by half to verify.
Didn't see any mention of a SS in your post.
RC
Well......you did say "Any help OR thoughts...."
These are "Thoughts"........not necessarily any HELP. :)
RC
-
Do you have your SS on this machine? If not then the Index is most likely the problem as RC said.
Hood
-
no SS on this machine until the encoder can be attached . The readout in mach is showing what appear to be accurate RPM readings across the entire range . I will make a slotted disk and attach the encoder I got from cnc4pc today and see if the threading is better
-
What version of Mach are you using?
There have been problems with some lathes and threading. I have never had a problem but some people have and still do, the latest version of Mach has cleared up these problems for most but some still have issues. When threading the spindle speed DRO is locked so it looks like the speed is constant even though it might not be, the latest version however should work best but as its still in development and there have been a lot of changes you should use with caution.
Hood
-
I am running the latest lock down version , 2.64 I think, the other two lathes are running 2.57 .
I upgraded to the latest developmental version and the problem still exist . I am getting nice accurate readings on the tach on screen , never waivers more than 1or 2 rpm . Problem still exist , it doesnt look like its getting out of time , appears to be starting and ending at the correct time , just looks like the threads are torn some what , kind of like a dull tool that is dragging instead of cutting . I am using a commercial boring bar type internal threading tool and carmex inserts , same tool I have used on the other machines to cut thousands of threads.
I am going to try a different threading tool in the morning , although I dont think its the problem , and if that doesnt make a diff I will make a disk and try the CNC4pc pulse generator
-
Do you have a SmoothStepper ready for that Lathe?
Hood
-
Hood,
Will the SS do threading with R3.042.008 and an index pulse for testing purposes?
RICH
-
I can probably talk shepard out of his SS in the morning , The one I ordered has found a home in my mill.
-
I have just been using the slotted disc and opto so far for threading on the lathe as I have also been jumping back and forth between SS and PP doing testing so have not fitted the encoder yet. I think however a few of the testers have encoders on their lathes and seem to be fine but as I said no experience of it myself.
You need a plugin that only the beta testers have at the moment for threading with the SS but I think Tuesday there is supposed to be a new plugin which will contain the threading as well as SoftLimits, thats if there are no final problems with it.
Hood
-
I was just hoping to use the original encoder as its already mounted , the disk I need to make would have to be 11" in diam to , may still do it in the morning as I need to thread a part that just wont eaisly fit in my other lathes
-
Then again, as suggested earlier, you may get by temporarily by reducing the spindle RPM to 50% or less just for the threading.....or even more. It may get you over the hump.
RC
-
I have tried threading in 50 rpm increments from 50 rpm to 1000, same problem
-
Maybe going the "Reflective Sticker and Sensor" route would be easier than the slotted disc if the SS is soon coming into play.
RC
-
you still doing the motorcross thing? i called you abouy some property for sale down there about 2 years ago did you ever sell it?
alex
-
Hi Alex , we sold everything inland , my wife decided we would keep the house on the river. Havent been there in over a year . Hopefully the real estate market will come around and we will put it back on the market. Havent had much time for trail riding in the past year , busy in the shop .
-
Hey RT,
Looks like from the other topic you got the index to work.
What was the culprit ?
Jut curious........and curious why I'm so curious. Jeeshhh
RC
-
I havent gotten it to work 100% but I read your post on your threading tolerances increasing drasticly with the upgrade to .008 , loaded the latest development version and its doing much better. I decided to thread the 400+ tubes I need on the other lathe and get back to this one when I can get another smooth stepper. I really need to get this one threading as it has a 3" hole thru the spindle, 30hp spindle motor , 12 station tool changer etc etc.
I sent the fellow at warp 9 an email this past weekend but havent heard anything back. I was hoping to get one in hand before the week ends , plenty of other stuff to do in the meantime.
-
I hope it's all patched up in the next release. Looking for a new lockdown soon, if I'm following the other forum correctly.
Keep up the good work,
thanks,
RC
-
Still waiting to here back from Warp9 on getting a smooth stepper for this project
-
smooth stepper landed today , the first one had male db25 and plugged right into my c11 BOB , This one came with female db25 on the cables, will have to figure something out in the morning to plug it into the c11 BOB on the lathe.
Brett and Hood stay tuned, many stupid questions to follow
-
Hey RT,
Would you mind to check this for me ?
http://www.machsupport.com/forum/index.php?topic=8461.new#new
If this is the screen that you are using.
Thanks,
RC
-
Hello all,
While treading on the lathe, the x-axis is walking slow in or out on some cuts :o ???.
Can some one tel me what the solution is?
Rieks
-
What is the code you are using?
Hood
-
What version of MACH are you using?
How are you generating the threading code? Wizard, M76, G32?
What is the condition of your lathe?
- Ball screws / steppers / backlash ?
What are you using for an index?
RICH
-
Hello,
The version I use is R3.042.020 and I use the wizard "Threading" in Lathe, thus G76
-
and what is the code that gives you the problem?
Hood
-
When treading, after 2 or 3 cuts, wit a depth of 0.2 mm, befor the next Z-axis movement in negativ
direction, the X-axis feeds in 0.2 mm, and then, when Z-axis moves in, the X-axis moves slowly out, as if
a taper is cut.
Rieks
-
please give an example of the problem code.
Hood
-
Hello Hood,
sorry for the delay, Here is the problem code.
It is the first time I tested the threading wizard.
Rieks
-
This is the code:
G0 G40 G18 G80 G50 G90
G00 G53 X0 Z0
T101M5
G00 X10.5
G00 Z3
G00 X10
M03 S200
M08
G76 X8.12 Z-20 Q1 P1.5 J0.2 L45 H0.4 I29.5 C0.5 B0.1 T0
M9
M5
M30
rIEKS
-
certainly looks ok, shouldnt have any problems with that. What version of Mach are you using and if you look in C:\Mach3 for m1076.m1s, if you open in notepad does it say 12/25/08 Rem G95 at the start?
Hood
-
Indeed there is 12/25/09 Rem 95
-
Small misser 12/25/08 Rem 95
-
Can you attach your xml and I will see if I can replicate the problem.
Hood
-
Can You gif me Your E-mail, then I can mail it to You tomorrow, its almost midnight.
-
sent my email in a personal message.
Hood
-
I am having the same or a similar problem. I have posted In a another thread, but it seems to be a bit slower than this one. Here is what I wrote:
Has a solution to this problem ever been found? I am using .020, and it is giving me very similar problems. If during a cut the spindle slows down very much at all the z speed compensates just fine, but the next pass is cut very unusually. The next pass will be cut at what appears to be a constant taper with the z axis very slowly moving from a depth that is outside of the thread to the final depth that the pass should have been cut at. This movement can be seen both physically, and on the DRO. I have also had a problem where the next pass after a slowed down pass will be completely outside of the thread in the air. I am not losing steps, and the pitch is always spot on, but the depth is very messed up. I have run a test piece of code posted elsewhere in this forum that is a g-32 code that has a very shallow thread cut in 80 some passes. I have run it three times, and the results are perfect, and repeatable.
I am very confused as to what is going on here. I don't have a very good understanding of what the g76 is commanding while it cuts at all the different depths to achieve a thread, but something seems to be amiss. I am pleased to hear that you can change the output from the threading wizard to a g32, or what I would understand to be a longhand version of the code, I will try that as soon as possible to see what happens. Thanks
I did do some more playing around yesterday, and I found that I was finally able to cut a 1/4-20 thread in brass and have it come out perfectly, but I had to do it in 40 passes.
I found that if when using the turn diag. screen I can watch the spindle speed deviation and watch the problem when it happens. It seems that when the speed differs by about 10-12% the following pass will be messed up. The pitch, or Z movement always stays correct, however the depth of the thread is cut at a taper, starting outside of the thread, and then tapering in so that by the end of the thread it is at the correct depth. This then has a snowball effect, because as it tries to cut the next pass it is effectively cutting too deep since the material that should have been removed on the previous pass is still there, thus the spindle slows down, and the cycle starts over again.
I only have a 1hp motor, and I realize of course that it is a limiting factor, but the cutting on a taper is very strange to watch. Let me know if there are any other suggestions, and I will put them to the test.
Thanks.
-
TrevorH,
Only expect software to compensate so much for the mechanics of the lathe. What the program does to compensate for the mechanical ill's is very complex. It may take you additional passes but if in the end you get a good thread
that's what's important. My understanding of what happens is that the threading program does adjust to rectify a bad pass in the next pass. It can only do so much. Since threading is very machine dependent, i would suggest to anyone, that they do some experimentation.
1. As you have done, try air cutting and see if timing is working as it should and that the axis's have the
accelleration / velocity to do the required moves. If you are using the wizard to generate the code , it will calculate
and see if you are within your motor tuning,
and if not, you should change passes and spindle speed accordingly. I also must remark that if your max velocity
and acceleration settings don't leave any headroom for cutting, then your not being very conservative and will
surely run into a problem sooner or later.
2. Next confirm the quality of cutting by doing doing manny very small passes onto a marked shaft. You should get a
single nice clean spiral. You will see if all is not well. I have posted pictures of this in other threads on threading.
3. Next comes the actual cutting. All the things associated with threading come into play. How well the "system"
actuall does may require you to adjust accordinly for your "system". Small lathes need to have as much going
for them as possible. Sharp cutting tool nicely ground for the thread, properly placed for cutting, and adjusted
accurately ( taking into account tip radius , etc.). So find out where things will go sour by doing some
experimentation at different speeds, feeds , and .....material. That experience will go a long way to being
successfull.
I wish someone could say that at "x%" variation of speed threading will fault but just don't find that to be practical.
You shouldn't be there to begin with!
We just tried my Punny Lathe out the other day cutting a 1/4-20 @ 900 RPM / .001" first pass, .006" other passes with 2 spring passes in Al. Thread was perfect. BTW, I only have a fourth of your HP.
RICH
-
Rich, Thanks for the reply, Here is a little more about my setup.
1HP dc variable motor-0-1700 spindle rpm, most threading done at 3-500 rpm
Linear rails, and rolled pre-loaded ballscrews, with a couple thou backlash, but no compensation currently enabled in Mach
my velocity is limited to about 70 ipm, so I have set the motor tuning to allow for 50ipm max where there is plenty of power aviliable
The threading tool is a commercial carbide indexable insert with a very sharp point, no radius. It is set as close to exactly on centerline as I can get.
I agree that a smaller lathe will take many passes to achieve a good thread, and that not too much can be expected from a 1hp 200lb machine, but what really confuses me is what exactlly is going on when mach does the strange tapered cut that several of us have experienced. Unfortunately it doesn't allow much room for error since once you "overload" the spindle and the software has to correct beyond a certian ammount(some say 5-6%, I say 10-12%) Then the operation is pretty much doomed since the next cut is going to be cut at a taper, leaving the next pass cutting at basically twice the programmed depth. As I have stated before the interesting thing is that the pitch of the thread always seems to be perfect for me, with a incorrect depth caused by the taper being my concern.
I will continue to play around as time allows, and for now I will err on the side of lots of shallow cuts.
Thanks again for the input.
-
I forgot to mention that I did try the experiment with the 80 some very shallow cuts on a inked shaft with perfect results all three times that I tried it. Thanks.
Also my apologies for taking over this thread with my questions, though I think that my problem is pretty much the same as the original one that started this thread.
Thanks
-
Hello TrevorH,
I have no problem that You are jumping in ;).
At first my unwanted X movemend was also in the inside (minus) direction,
later trials wend the other way.
My PC broke down today, so I can not try out new suggestions for a wile.
Rieks
-
Hello Rich,
If a cut is missed, caused by the walking out of the X-Axis, it dus not cut.
In the next cut, when it is good, it tries to cut twice the cut depth, which causes
a overload of the Spindle with a lot of sadness as the consequence.
-
I have done some more experimenting.I now think the critical issue
is a stable spindle.After installing the s/s and mucking with encoder pulse
I thought that I was ok.However this was with sharp tool,soft mat'l.
With tool dulling in some 4140 studs the erattic x feed came back.
I then worked on the drive ,MORE POWER.I'm now threading at 800
rpm and all is well.I tried to slow the spindle with a 2X4 jammed against it
and the treading is fine.
-
Rieks,
My question is this.......how are you missing a cut? Are you really missing a pass?
Backlash in the system and the resulting pass cuts can take on a strange appearence / illusion.
It is very difficult to definitively say / see what happened. Even with a measuring microscope attached to
the lathe carriage. And you need to be very disciplined in the observence.
Are you taking out the X & Z backlash on setup?
This will help.....to some degree....i won't debate the point as logic says one thing but in my experience it just dosen't cut it over numerous pressured passes. It just takes one or two thou and then a move in the other direction and now your cutting what seems like almost a double depth of cut. I can mimic that somewhat just with or without cutting fluid.
Try this, put ten 0.0001" spring cuts in. Try it in the begining, mid-way, and at the end of the threading.
What happened during the spring cutting?
I would like you to do something. Do two threading operatons. One using G32 and one using G76.
Both of them should be done with "exactly" the same paramters, metal etc. ie; spindle speed, depth of cut, etc.
In fact use a threading operation that caused fault.
One is a canned cycle and the other numerous X/Z moves.
What are your results?
Try the same using G32 with and with out backlash compensation.
What are your results?
Try another run, the only variable change is exact stop and constant velocity.
What are your results?
Try another run, the only variable change is not to provide cutting fluid on some cuts.
What are your results?
Please take the above in this light. Only trying to help not judge. I quess i believe there is nothing wrong
wth the threading cycle, that the built in compensations work to within some resonable degree, and that if things get
out of whack too much the thread is history. Every part of the system has an effect on the outcome.
RICH
-
hello Ritch,
Yes, I miss cut's, while the X-Axis walks out of the material during the Z move, as if a taper is requested.
Not only physical, bud also the X-DRO, as TrevorH wrote.
During this pass there is no cutting material.
Obviously the program keeps count of the passes and the infeed's
The next one, when it is not walking away, takes the new value, and makes the next cut, witch will be the double infeed.
If only the axis would move by it self, and not the DRO then I would think about noise pulses.
As a retired Electronic engineer, I can think about noise, while I don't use screened cables.
Close to the X Steppermotor are two cables from a measuring device.
For me as a Hobby metalworker the problem is not very serious, so, don't stay awake about it, but it would be nice if
everything would work in the end.
Rieks
-
Rieks
looked over your xml and so far dont see anything wrong.
I am trying to think of a way I could simulate your problem but as I have no way of slowing the spindle down on my lathe manually I dont know how I can, even a 10mm DOC wouldnt slow it down.
Hood
-
Hello Hood,
I really don't think that the problem is in the software.
"Keithmech" thinks that he has solved the problem, and I tend to think that he is right.
The only thing I can't explane is why the X-DRO is moving as well.
I am making my Hobby-Lathe CNC Controlled, so it is not very serious in my case.
There are more people with the same problem, so I'm curious about the solution of this problem.
Rieks
-
I just finished running 100 pieces.5/16 nf in 4140.
Not one missed thread.six passes per.at about 1000 rpm.
Threading takes more power than we think.I struggled with the same
issue and tried several work arounds but Hood, who has more horse power
than Zeus, has never seen our issue.Try a bigger motor.
-
Here's a thought for Hood.Try cutting a 4 tpi acme in some 4340.
set your gear change to the top speed and adjust the vfd down
so it is at about 15%.Motor should lug under these conditions.
I know it is alot of work or you could wedge a large timber up against the chuck
to simulate a spindle variation.I use a 2x4 but my Hardinge is just up from puny.
-
I am pretty sure that Reiks and I are having very similar problems from reading his description. I would be happy to try the suggestion for using a g32 as well as a g76 threading operation and report the results. The only problem is even after reading a description of how to change the macro to output longhand code I still don't quite get it. I know that there was something about changing something to false, but I need a little more direction. If I can figure out how to change that setting then I will do a comparison test.
I think that I would try a 1/2-13 in 6061, maybe about 1 long at 350 or 400 rpm with everything the same except for the code. I will use a brand new threading tool, and the same piece of bar, and report the results. If someone can steer me in the right direction as to how to edit the macro, or even better just post a modified one that I can replace the existing macro with ;D
I would probably have time to do this tomorrow, and I might even be able to manage a photo of the results.
Again thanks to everyone for all of the great input!
-
If you guys are using VFDs for speed control if at all possible try using a spindle speed which relates to the motors normal frequency (50Hz/60Hz depending on which side of the pond you are) Obviously it will depend on your axis speed as to whether you can physically do that.
Like Rieks I am still intrigued why it does the x axis moves though, I will see if Art has any thoughts on this.
Hood
-
Here's a thought for Hood.Try cutting a 4 tpi acme in some 4340.
set your gear change to the top speed and adjust the vfd down
so it is at about 15%.Motor should lug under these conditions.
I know it is alot of work or you could wedge a large timber up against the chuck
to simulate a spindle variation.I use a 2x4 but my Hardinge is just up from puny.
Afraid that wouldnt make any difference, I have a big AC Servo on the spindle (see specs below), doing a 10mm DOC in 75mm Dia EN24 wouldnt slow the spindle for long enough for me to notice. The servo drive would compensate and if I pushed it even more then the drive would fault in milliseconds.
Hood
-
I am pretty sure that Reiks and I are having very similar problems from reading his description. I would be happy to try the suggestion for using a g32 as well as a g76 threading operation and report the results. The only problem is even after reading a description of how to change the macro to output longhand code I still don't quite get it. I know that there was something about changing something to false, but I need a little more direction. If I can figure out how to change that setting then I will do a comparison test.
I think that I would try a 1/2-13 in 6061, maybe about 1 long at 350 or 400 rpm with everything the same except for the code. I will use a brand new threading tool, and the same piece of bar, and report the results. If someone can steer me in the right direction as to how to edit the macro, or even better just post a modified one that I can replace the existing macro with ;D
I would probably have time to do this tomorrow, and I might even be able to manage a photo of the results.
Again thanks to everyone for all of the great input!
Go to Operator menu then VB Script Editor. Browse to C:\Mach3 and open M1076.m1s. You will see a load of green text for a start then down a bit you will see in black Test =false , change that to Test =True and then close and save.
Next time you use the wizard your code will be written in G32, watch however that any preliminary moves are correct and make sure you change it back if you have any code that has a G76 in amongst other code as the M1076 will rewrite your file on loading.
Hood
-
Here is what you change to get G32 code.
MODIFIED: SORRY ABOUT THE PIC AND ALSO NOTE THAT THE FILE NAME IN THE PIC IS INCORRECT.
IT SHOULD SAY "M1076".
-
Didn't come through RICH.
Try again ?
Thanks,
RC
-
Thanks for the instructions on ow to change the threading macro. I just tried it on the home computer and it was really easy, and it would generate nice long code for threading. I will put it to use tomorrow, in the shop and report the results. I think that i will try a 1/2-13 in delrin since I have some of it handy, and I have been able to get the result I have been describing while threading delrin before. Thanks guys.
-
Talked to Art and he thinks it must be a VB error, some earlier versions had problems with VB but the latest ones should be fine. If it is a VB error then you will not see it with the G32.
Look forward to your results.
Hood
-
Well you get the written version and a picture also!
-----------------------
I am scracthing my head on this one also. Back a week or so i fooled around and couldn't get the
x axis to do what is being described. I harp on the mechanical stuff, just want to be sure that
that is eliminated.
I have Art's postings on how threading works, but, hate to post something since if they changed threadng
or something in Mach versions it would only add to confusion.
If you loose a step with a stepper, and you usually know it, the x would take on a mind of it's owne calliing for a
hit of the estop. I have had them run away and also have had them skip but continue with the code,but if they skiip
a step usually it's for a time more than what these folks are experiencing.
If it's intermitant, finding the kremlin is tough. Rf / noise can be a culprit here and that can be tough to converse
on.
RICH
-
Hood
May be all wet here, maybe someone can chime in, but here's goes.
You have the following:
1-supplied voltage- say 60 hz
2-spindle sensor frequency to mach - 1 pulse per rev
3-VFD generated dominant freg- i can measure but most would not be able to do
4-the stepper pulses per unit- ???
Now you want to be away as far as you can go from any fundamenetal or harmonic....thus in terms
of suppled voltage 60,120,180, ...etc you want the spindle sensor being at 30, 90, etc.
So your input / output MACH pulses have less chance of having an intereference. Now if it's brute noise,
that's a diifferent story,. If that's the case then it would not be so intermitant and the grounding, shieldnig etc will have more effect.
A little far fetched but if the field builds up i can see where you can get some "goofy" pulse or interference
that could make the X axis not behave yet contnue. But like i said, a little farfetched.
Just some out of the box thinking,
RICH
-
Just a thought..(rare for me). ::)
The fellows with the X walking problem stated that the DRO reflected the move as well....
I can understand noise creating a pulse to the driver but would it show up in the DRO ?
Thanks,
RC
-
spindle slows maybe >1 rpm.software says "holy crap I'm lost".
The control then goes looking for wear it should be.I think a software solution might be.
If reference pulse signal varies by (small value) then retract x from thread imidiatly
return tool to start position and carry on at last cut value.
-
Ok, I went out to the shop tonight, I had too many thoughts going thru my head with all of the helpfull suggestions recieved here tonight. I have lots to report, I will Divide it up into a couple of posts. First for the code that I used.
G-76, I guess that it didn't copy onto my thumb drive in the garage, I will have to get it tomorrow...
Long code:
(Taper = 0)
(Infeed Angle = 15)
(Total_Depth = 0.125)
(StartZ = 0.1)
(EndZ = -0.75)
(Seq = 0 )
(Min_Decrement = 0.0001 )
(Dia Mode )
G0 X0.525 Z0.1
G0 X0.5
(Decrement = 0.014 pass 1)
G01 Z0.1
G32 X0.486 Z0.0981 F0.077
G32 X0.486 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0058 pass 2)
G01 Z0.1
G32 X0.4802 Z0.0973 F0.077
G32 X0.4802 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0044 pass 3)
G01 Z0.1
G32 X0.4758 Z0.0967 F0.077
G32 X0.4758 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0038 pass 4)
G01 Z0.1
G32 X0.472 Z0.0962 F0.077
G32 X0.472 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0033 pass 5)
G01 Z0.1
G32 X0.4687 Z0.0958 F0.077
G32 X0.4687 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.003 pass 6)
G01 Z0.1
G32 X0.4657 Z0.0954 F0.077
G32 X0.4657 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0027 pass 7)
G01 Z0.1
G32 X0.463 Z0.095 F0.077
G32 X0.463 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0026 pass 8)
G01 Z0.1
G32 X0.4604 Z0.0947 F0.077
G32 X0.4604 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0024 pass 9)
G01 Z0.1
G32 X0.458 Z0.0944 F0.077
G32 X0.458 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0023 pass 10)
G01 Z0.1
G32 X0.4557 Z0.0941 F0.077
G32 X0.4557 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0022 pass 11)
G01 Z0.1
G32 X0.4536 Z0.0938 F0.077
G32 X0.4536 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0021 pass 12)
G01 Z0.1
G32 X0.4515 Z0.0935 F0.077
G32 X0.4515 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.002 pass 13)
G01 Z0.1
G32 X0.4495 Z0.0932 F0.077
G32 X0.4495 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0019 pass 14)
G01 Z0.1
G32 X0.4476 Z0.0929 F0.077
G32 X0.4476 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0018 pass 15)
G01 Z0.1
G32 X0.4458 Z0.0927 F0.077
G32 X0.4458 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0018 pass 16)
G01 Z0.1
G32 X0.444 Z0.0925 F0.077
G32 X0.444 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0017 pass 17)
G01 Z0.1
G32 X0.4423 Z0.0923 F0.077
G32 X0.4423 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0017 pass 18)
G01 Z0.1
G32 X0.4406 Z0.0921 F0.077
G32 X0.4406 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0016 pass 19)
G01 Z0.1
G32 X0.439 Z0.0919 F0.077
G32 X0.439 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0016 pass 20)
G01 Z0.1
G32 X0.4374 Z0.0917 F0.077
G32 X0.4374 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0015 pass 21)
G01 Z0.1
G32 X0.4358 Z0.0915 F0.077
G32 X0.4358 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0015 pass 22)
G01 Z0.1
G32 X0.4343 Z0.0913 F0.077
G32 X0.4343 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0015 pass 23)
G01 Z0.1
G32 X0.4329 Z0.0911 F0.077
G32 X0.4329 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0014 pass 24)
G01 Z0.1
G32 X0.4314 Z0.0909 F0.077
G32 X0.4314 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0014 pass 25)
G01 Z0.1
G32 X0.43 Z0.0907 F0.077
G32 X0.43 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0014 pass 26)
G01 Z0.1
G32 X0.4286 Z0.0905 F0.077
G32 X0.4286 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0014 pass 27)
G01 Z0.1
G32 X0.4273 Z0.0903 F0.077
G32 X0.4273 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0013 pass 28)
G01 Z0.1
G32 X0.4259 Z0.0901 F0.077
G32 X0.4259 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0013 pass 29)
G01 Z0.1
G32 X0.4246 Z0.0899 F0.077
G32 X0.4246 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0013 pass 30)
G01 Z0.1
G32 X0.4233 Z0.0897 F0.077
G32 X0.4233 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0013 pass 31)
G01 Z0.1
G32 X0.4221 Z0.0895 F0.077
G32 X0.4221 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0012 pass 32)
G01 Z0.1
G32 X0.4208 Z0.0893 F0.077
G32 X0.4208 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0012 pass 33)
G01 Z0.1
G32 X0.4196 Z0.0891 F0.077
G32 X0.4196 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0012 pass 34)
G01 Z0.1
G32 X0.4184 Z0.0889 F0.077
G32 X0.4184 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0012 pass 35)
G01 Z0.1
G32 X0.4172 Z0.0887 F0.077
G32 X0.4172 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0012 pass 36)
G01 Z0.1
G32 X0.416 Z0.0885 F0.077
G32 X0.416 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0012 pass 37)
G01 Z0.1
G32 X0.4148 Z0.0883 F0.077
G32 X0.4148 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0011 pass 38)
G01 Z0.1
G32 X0.4137 Z0.0881 F0.077
G32 X0.4137 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0011 pass 39)
G01 Z0.1
G32 X0.4126 Z0.0879 F0.077
G32 X0.4126 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0011 pass 40)
G01 Z0.1
G32 X0.4115 Z0.0878 F0.077
G32 X0.4115 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0011 pass 41)
G01 Z0.1
G32 X0.4104 Z0.0877 F0.077
G32 X0.4104 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0011 pass 42)
G01 Z0.1
G32 X0.4093 Z0.0876 F0.077
G32 X0.4093 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0011 pass 43)
G01 Z0.1
G32 X0.4082 Z0.0875 F0.077
G32 X0.4082 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0011 pass 44)
G01 Z0.1
G32 X0.4071 Z0.0874 F0.077
G32 X0.4071 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.001 pass 45)
G01 Z0.1
G32 X0.4061 Z0.0873 F0.077
G32 X0.4061 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.001 pass 46)
G01 Z0.1
G32 X0.405 Z0.0872 F0.077
G32 X0.405 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.001 pass 47)
G01 Z0.1
G32 X0.404 Z0.0871 F0.077
G32 X0.404 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.001 pass 48)
G01 Z0.1
G32 X0.403 Z0.087 F0.077
G32 X0.403 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.001 pass 49)
G01 Z0.1
G32 X0.402 Z0.0869 F0.077
G32 X0.402 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.001 pass 50)
G01 Z0.1
G32 X0.401 Z0.0868 F0.077
G32 X0.401 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.001 pass 51)
G01 Z0.1
G32 X0.4 Z0.0867 F0.077
G32 X0.4 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.001 pass 52)
G01 Z0.1
G32 X0.399 Z0.0866 F0.077
G32 X0.399 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.001 pass 53)
G01 Z0.1
G32 X0.3981 Z0.0865 F0.077
G32 X0.3981 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.001 pass 54)
G01 Z0.1
G32 X0.3971 Z0.0864 F0.077
G32 X0.3971 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 55)
G01 Z0.1
G32 X0.3962 Z0.0863 F0.077
G32 X0.3962 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 56)
G01 Z0.1
G32 X0.3952 Z0.0862 F0.077
G32 X0.3952 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 57)
G01 Z0.1
G32 X0.3943 Z0.0861 F0.077
G32 X0.3943 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 58)
G01 Z0.1
G32 X0.3934 Z0.086 F0.077
G32 X0.3934 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 59)
G01 Z0.1
G32 X0.3925 Z0.0859 F0.077
G32 X0.3925 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 60)
G01 Z0.1
G32 X0.3916 Z0.0858 F0.077
G32 X0.3916 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 61)
G01 Z0.1
G32 X0.3907 Z0.0857 F0.077
G32 X0.3907 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 62)
G01 Z0.1
G32 X0.3898 Z0.0856 F0.077
G32 X0.3898 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 63)
G01 Z0.1
G32 X0.3889 Z0.0855 F0.077
G32 X0.3889 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 64)
G01 Z0.1
G32 X0.388 Z0.0854 F0.077
G32 X0.388 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 65)
G01 Z0.1
G32 X0.3871 Z0.0853 F0.077
G32 X0.3871 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 66)
G01 Z0.1
G32 X0.3863 Z0.0852 F0.077
G32 X0.3863 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 67)
G01 Z0.1
G32 X0.3854 Z0.0851 F0.077
G32 X0.3854 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0009 pass 68)
G01 Z0.1
G32 X0.3846 Z0.085 F0.077
G32 X0.3846 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 69)
G01 Z0.1
G32 X0.3837 Z0.0849 F0.077
G32 X0.3837 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 70)
G01 Z0.1
G32 X0.3829 Z0.0848 F0.077
G32 X0.3829 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 71)
G01 Z0.1
G32 X0.382 Z0.0847 F0.077
G32 X0.382 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 72)
G01 Z0.1
G32 X0.3812 Z0.0846 F0.077
G32 X0.3812 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 73)
G01 Z0.1
G32 X0.3804 Z0.0845 F0.077
G32 X0.3804 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 74)
G01 Z0.1
G32 X0.3796 Z0.0844 F0.077
G32 X0.3796 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 75)
G01 Z0.1
G32 X0.3788 Z0.0843 F0.077
G32 X0.3788 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 76)
G01 Z0.1
G32 X0.378 Z0.0842 F0.077
G32 X0.378 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 77)
G01 Z0.1
G32 X0.3772 Z0.0841 F0.077
G32 X0.3772 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 78)
G01 Z0.1
G32 X0.3764 Z0.084 F0.077
G32 X0.3764 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Decrement = 0.0008 pass 79)
G01 Z0.1
G32 X0.3756 Z0.0839 F0.077
G32 X0.3756 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
(Last Pass ID_OD = 1)
(Decrement = 0.0005 pass 80)
G01 Z0.1
G32 X0.3751 Z0.0838 F0.077
G32 X0.3751 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
( Last pass at depth of 0.0001)
G01 Z0.1
G32 X0.375 Z0.0838 F0.077
G32 X0.375 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
( Spring pass number 1)
G01 Z0.1
G32 X0.375 Z0.0838 F0.077
G32 X0.375 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
( Spring pass number 2)
G01 Z0.1
G32 X0.375 Z0.0838 F0.077
G32 X0.375 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
( Spring pass number 3)
G01 Z0.1
G32 X0.375 Z0.0838 F0.077
G32 X0.375 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
( Spring pass number 4)
G01 Z0.1
G32 X0.375 Z0.0838 F0.077
G32 X0.375 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
( Spring pass number 5)
G01 Z0.1
G32 X0.375 Z0.0838 F0.077
G32 X0.375 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
( Spring pass number 6)
G01 Z0.1
G32 X0.375 Z0.0838 F0.077
G32 X0.375 Z-0.75 F0.077
G01 X0.525 Z-0.75 F0.077
G00 X0.525 Z0.1
G00 X0.5
G00 X0.525 Z0.1
-
Ok both turned out like ka ka, but here are some of the specs that I used.
.500 od
.375 Minor dia
.077 pitch for 13tpi
.014 first pass
No taper, No chamfer
400RPM which made for travel of 30.8UPM
81 passes and 6 spring passes
Here is the first thread cut using the G76 code(http://)
-
Here is another fo the first thread cut using the G76 code which shows some very interesting wavy shape to the threadform along with the tool that I am using to cut the threads. The thread cut fine for about the first three or four passes, but then it began to slow down the spindle and the fun began. I paid very close attention to what happened and realized that it was cutting every other pass in the air, then cutting tha alternating passes at what seemed to be twice the normal depth. Here is the really interesting part--Sometimes when actually cutting every other pass it would cut straight with no X movement, and sometimes it would cut them at a taper with an x movement thrown in along with the Z movement. As you can see the thread is not correct, but it does fit my cheapo thread gauge perfectly!
More to follow, time to put the kids to bed....
-
OK now for the second thread that I cut with the long code posted a few posts back. All of the specs are the same, I saved them in the wizard, then changed the macro using the instructions kindly provided earlier and re posted. This thread also didn't turn out, but in a different way. The first couple of passes turned out allright, then the spindle slowed about 25 rpm and things went south. This time it was also interesting to watch as a allmost magical pattern appeared. It would cut a pass, slow down, then the next pass it would cut in the air completely outside of the thread. Then the next pass would be cut at the commanded depth(I had a chance to compare the DRO to the code several times) but since the pass before didn't remove any material it's "effective" depth was too great which resulted in another reduction of spindle speed followed by another air cut and on and on. Then about the last 30 cuts it began to again throw in a little taper as can be seen in the finished thread pictured below. I think that you can see that the thread is cut deeper towards the end of the thread than it is at the beginning.
Here are some things that I observed
I was amazed that no matter how wrong things seemed to go the cutter always followed the correct pitch, and never crashed into the workpiece, this is pretty impressive to me and shows that the software is in fact doing a very nice job of correcting the Z feedrate on the fly.
I also noticed something interesting while watching the turn diag. screen. I had the spindle turning at 400-405 rpm, and the greatest deviation that I ever had was 39 RPM, but the box that shows by what percentage the speed was off by showed a max of 39 percent. I think that 39 RPM is approx 10 percent of 400 RPM, and it leaves me wondering if Mach really thinks that the speed deviates by 39 percent, or if the box is simply mislabeled with a % sign?
It may turn out that I need to be able to controll the RPM to a greater degree than is presently possible, with my current spindle motor?
I think that tomorrow maybee I should try to cut the same thread in lots(maybee several hundred) passes and see what happens then.
Let me know if all of my ramblings have made any sense, and possibly inspired an idea or two as to what I should try next.
Thanks
-
So even using G32 you are getting the taper cuts and the X dro is showing that taper?
Hood
-
Hood, Yes the taper happens no matter how te code is generated. Later today I am going to try to cut a thread in about 200 passes and see what happens. I will report back tonight.
-
I did some more testing today with similar results. I also took a video of the process which I think will help to illustrate the unusual movements that I and others have been describing. Is is possible in inbed video here, or do I just need to post a link to the video on youtube. let me know. Thanks.
-
Yes you can embed :)
Hood
-
TrevorH,
I used your Gcode that you posted to cut a 1/2-13 thread in 6061 on my Punny little lathe. ( 400 rpm spindle speed)The posted pic is of the G32. Also cut one useing M76. The results were the same. In the pic you can see a difference of 2 thou at the thread beginning and that is due to the actual diameter dfference as i didn't start off with a finished stock diameter.
The spindle did slow down. Never experienced an X runaway. During the spring cuts there were a few times when more than a hair shaving was taken off. I have about .002" backlash in the X and a little under the same in the Z. So during the spring cut is it's possible for me to get more than just .0001" cut. i can adjust / take out more of the backlash but I leave it as is for now.
The flank cutting ( your code had 15 deg infeed ) worked as it should, just a nice forward curl. Note there are no
steps in the backside of the threads. Your's has them ( that's backlash and i can duplicate it by increasing mine).
I believe your problem is mechanical. Note no waviness in my threads. Software dosen't do that. Mach reacts rather
quickly, but not instantaneously to a slow down, when that accurs the next pass will try and fix it. Yours almost looks like a gouge. On the next cut if it happens again, because of some other / prior pass, then again it tries to fiix, but
then who knows what it's fxing ( just my thought). You may be better off not taking as deep a first pass cut ( .014").
This way you get a v started which can help guide the tool. Just some thoughts for you.
Now i will admit that there MAY be some quirky thing from the software point of view, but not convinced yet.
Or maybe i just haven't stepped in poop lately ( i do have the knack of finding it).
RICH
-
I just tried to embed the yahoo vidoe here, and it just showed up aith what looked like a very long address, but no picture. Here is a link to the video.
http://www.youtube.com/watch?v=vb6ozg1Qi1k
I tried to show the cutting, as well as shome shots of the screen. As you can see and hear The bit is engaging too much and slowing down, then it is cutting air for one or sometimes two passes before it again re-engages the work at what becomes too deep of a depth. As you can see my toolpost and overall setup leaves alot to be desired, but nothing seems to be moving around too much. I do have another video showing the machine making some .100 moves in the z direction, and as you can see I do have 2-5 thou of backlash/inaccuracy, and that may very well be causing or contributing to my problem. I still just don't understand what is causing the machine to cut in the air like it is. Thanks
Backlash Vid
http://www.youtube.com/watch?v=IhnrRqWhBZs
-
Took the liberty of posting it for you.
Hood
http://www.youtube.com/v/vb6ozg1Qi1k&hl=en&fs=1
-
Certainly can see the X moving on a cut, dont have an answer for you I am afraid.
Hood
-
At least you can see it so that you don't think that I (we) are crazy. Thanks for putting the video in for me, how did you do that?
-
["flash=640,480]http://http://www.youtube.com/v/vb6ozg1Qi1k&hl=en&fs=1[/flash"]
Without the "
-
Thanks for the video post. Now will listen to it very carefully.
Trevoh, your not crazy in anyway.
But me.......well that's another story! ;)
RICH
-
Trevoh,
Are you using backlash compensation?
What is your stepper rated torque?
RICH
-
Rich, No backlash compensation enabled, maybee I should play around with that? The steppers are 191oz/in increased by the belts pulleys 1.6 to 1, they are driving 5/8 rolled ball screws with a pitch of .200, or 5 Turns per inch. I am using Linisteppers to drive the steppers in half step mode currently at 12v and 1.5A per phase.
The thread that you cut and posted a pic of looks really nice, I can only hope for those kind of results at this point.
-
Hi, Trevoh
My first impression after hearing/viewing your video, Is it's a rigidity/flex issue, Try cutting much closer to the spindle or use a tail stock support.
Also the vertical/center line placement (sweet-spot) of the cutter is very/very critical, Cutter sharpness & type vary with different types of material being cut.
Just some thought's, Chip
-
Hello TrevorH and the others,
Very happy with your video, this is exactly my problem.
My cutting is as close as possible to the chuck, so this not the problem.
I did not take any compensating action for backless, bud make the clearance to be certain thad
the "working moves"are allways in the same direction.
My stepper torck is about double the value.
Rieks
-
TrevorH,
Just a whole bunch of basic comments which make a difference in thread cutting and final dimensions:
1.As stated by Chip, try to get the cutter on the centerline of the stock.
2.Use a cutting fluid when cutting threads and idealy it should be constantly applied.
3.When setting the axis for the cut remove the backlash.
4.The more rigid the setup the better.If poor, fix it. Use the tail for additional support.
5.Take a finish cut on the stock, so you know where to set the cutter, it provides for
a more even cut load especialy if the first cut is deep.
6.When you set the cutter account for the tip radius. ( look at how a sharp v depth is defined )
7. Flank cutting can provide for more equal cutting / loading ( attempts to maintain equal area of
chip / shearing of metal ). I usaully use radial ( 29 deg ) for small threading.
8.Use sharp properly ground cutters. Carbide thread inserts are great but use ones with a small
nose radius on the smaller lathes. I have some that just don't have sharp edges and thus require more
power to do cutting.They sit in the box. Don't have any chasing cutters but they certainly add to the quality
of the thread form.
So be maticulous as any of the above can mean the difference between a good or bad thread.
For a 1/2-13 thread you have a "mean" tolerance range for OD of .012" and for pitch diameter .005"
if you want to fall "somewhere" within a 1,2,3A Class fit. Lets forget about uniformity of pitch over the
thread for the point i want to make.So no great shakes on the diameter if the pitch is ok. Lets say you
do a finish cut on the stock and then adjust the cutter placement to get the pitch right ( or adjust accordingly in the
gcode). Lets say you lost a thou based on the above 8 comments, that leaves you .004" range for the pitch.
You have backlash in the X and Z and .005" one or both. The chance of throwing a pitch over the plate for a
strike is...... well...........hope i made my point.
So yes, you should use backlash compensation as a software fix for just one part of the mechanical system ills.
Even though it does work great ( SS dosn't have it yet), you will see an improvement in threading but it's a patch.
Ideally you need to get rid of it or minimize it.
Sorry for being longwinded and didn't even get to your video, but, all of the above are in my thoughts as i watched
it.
RICH
PS: Yes i will be posting additional comments but i want a friend to watch the video first.
-
Hi Rich,
You do a great job explaining threading methods in general....much appreciated.
Would you mind to share your thoughts on what I mentioned in reply #60 ?
That is: Can mechanical issues, EMI or any other "Outside" influences actually cause the X DRO to change even though the program/software does not command the move ?
Thanks for your time,
RC
-
Thanks for all of the great comments about my video. As for my setup I know that it leaves a lot to be desired, and I plan to work on the issues over time. I know that I need to be cutting closer to the head stock, but the new metal way cover that were an afterthought simply doesn't allow it, so I need to move the headstock forward, and this is in the works. My bed which can't be seen under the covers is made of a pair of 3" wide 2 inch thick Linear guides, so I unfortunately don't have a way to mount a tailstock. As for the cutter I showed some pictures of it earlier in the thread, but it is a brand new indexable carbide insert/holder with a perfectly sharp point, no radius at all, and it is set dead center using a gauge. My current headstock mounting arrangement isn't perfect, and does allow some chatter espeically at certian speeds. I also know that my machine needs to be bolted to something more substantial than a wooden workbench that it is merely sitting on and a 3" thick concrete top is in the form curing right now, this will become the new home for the lathe. I will also play around with enabling backlash compensation and see if I can improve on my accuracy as much as possible. I agree that all of these things need addressed, BUT although they may contribute to poor, ill fitting threads I still don't see how any of these purely mechanical items can result in the machine cutting outside of the thread in the air, and at a taper followed by a cut that is effectively too deep in a very repeatable and per dictable fashion over and over every other cut over the course 80 or even 200 cuts as is is doing? ???
I will begin to sort out the mechanical "issues" that I have as I can, but I am unable to concentrate for long periods due to a problem with my eyes, so it might take a couple of weeks to get things as sorted as possible. In the meantime I look forward to continued suggestions and I will continue to post results so that if/when the problem gets better we will all know why!
-
I just had another thought, see if you agree with this logic, or not.
The X axis stepper motor is moving the bit into and out of the cut when it should not. I don't believe this to be a mechanical issue, though I am more than willing to explore it. So the question becomes why is the x motor moving when it shouldn't? The simple answer that I come up with is because the computer/software/controller is telling it to, I think that this statement is supported by the fact that the DRO is reflecting this move showing that the software is not only commanding the moves, but also keeping track of them. If I was loosing steps, or in some other way loosing position mechanically then I wouldn't be seeing the DRO's move right???? I am pretty green to all of this but don't those little steppers just do what they are told -within reason? I think that i have mentioned it before, but after completing the operation I can jog the bit till it touches the OD of the part, and it shows the same diameter... (.500 in this case) as it before the operation this leads me to believe that the motors are not moving on their own since the controller wouldn't be able to keep track of position--Is this correct?
If the above ASS umptions are correct and I hope that you will let me know one way or the other, then the new question would become Why is Mach telling the motors to move like they are?
Thanks, and I think that I need to quit thinking about this so much!!
-
Hi Trevor,
Good point.
IMHO,
RC
-
Talked to Art and he asked if you could single block through it and see if it does the same.
Hood
-
Hood, I would be happy trotry that it seems like a good idea. Can I do it just by hitting the single button over and over? or will I need to change the code somehow?
Trevor
-
I cant remember the last time I used single block but think you have to press Start after each line has completed but not sure.
Hood
-
Hi All, just wanted to add, this is exactly the same issue I have, as in previous post.
I know this is brash to say but I am fairly sure this is an interference issue or a G32 bug with the parallel port. Its not G76 as this topic seems to have shown and I don't think it can be.
So, a quick poll - does everyone who has this problem have a VFD? I wonder if this can create interference at low speed and high motor slip when the cut slows down.
Next, does everyone with this problem use the parallel port?
I do wonder if there is a very small, very good at hiding bug in G32. I know that is a rash and arrogant statement and I apologise for that, but I just can't see how so many can have the same exact problem?
I've now cut 11 threads perfectly, M16.3 x 0.97 pitch (don't ask!) and with very light cuts (0.03mm - thats light!) they were all absolutely perfect, so I know the lathe and Mach3 is working well. But as soon as I move to deeper cuts and coarse threads like M1.5 or M2 and the spindle slows then the X axis starts to move after about the 3rd or 4th cut, so I have to stop and start again - eventually I can complete the thread after about 6 re-starts.
No matter what the spindle or Z axis does, the X axis should not move during a thread with no taper and it should not suddenly start moving when in the previous initial cuts on the same thread it didn't!
I'm sure we will get to the bottom of it!
Woody.
-
No VFD here, I wish! I just have a 1hp dc motor controlled manually with the knob on the Dayton motor control box. Mac has no control over my motor I have to turn it on with the switch, then dial up the desired speed. I will try to run the code line by line later as suggested and report the results, hopefully later today.
Trevor
PS, I am using the parallel port.
-
Think your x stepper is loosing a step and then Mach is able to still control the steppers but every thing is out of whack. So mechanical problem leads to a software problem. I may be very, very, wrong! I would suggest that you try bringing your velocity down some. I think your step miss is x axis during the rapid before the next index, thus the the pitch is still ok. Then along with backlash , a screwy / upset program ,
it just repeats. Odd i must say. But I still want my friend to listen to the video and see if he hears what i hear.
I have had steppers miss steps, not in a long time, as i am conservative on velocity & accel settings.
Once i was milling a circle and the stepper missed steps but the " second circle came out all right
just a 1/4" of center from the first Z pass cut circle. Mach values were wrong but it maintained control. Sort of like "the driver lost control of the car but was able to bring it back onto the road with what was in his head only the car ended up in the wrong lane". In another case the axis just went totaly out of control at rapid setting. Post estop MACH's DRO values were nowwhere near the dro' on the mill.
12v @1.5a delived to the 195 Oz/in stepper,.....you have speed but i don't think you have much torque.
You would think that if you dry run / skim cut and all is well that you shouldn't have any problems.
RICH
-
Trevor
You have manual spindle speed control so could you run the code and just cut air and see if slowing the speed via the pot while its moving in the Z brings on the X movement.
Hood
-
I had the same problem.I had it with p/p and s/s.
I had it with a g76 and g32.The only way to make it go away was to add a dwell
at the begining of each cut or increase the power to the spindle.I think as I said before
that the reference pulse is the critical thing here.Depth of cut is not the only thing that can
slow down the spindle, friction of the tool rubbing on the sides of the tread. This does not explain the random
x movement but with enough torque it seems to not start.Any one can simulate this problem by
-running the treading wizard and generate some code.
-don't load a tool or work just turn on machine and cut some air
-apply a load to the spindle ,I just lever a 2x4 up against it until a rpm change is detected
-do this while threading in air.
Watch the x axis go into stupid mode.
-
Rich, I may be confused but I don't think that there is any possible way that I can be missing steps, because when the program is done running I can jog the tip of the tool to the end of the workpiece and it is at 0,0 just like before the program started. If it is reading 0,0 then doesn't it mean that the motors haven't lost any steps.
Hood, Keith, very good idea about cutting air and varying the spindle speed to see what happens. I could do it by loading up the spindle with a board, or rac, or whatever, but i think I will just turn the dial on the speed indicator to see if I can create the problem. I will go do that right now and report back, seems like a simple, but very telling idea. Thanks
-
Something to try also....just out of curiosity.
Run the faulty code with an "I" setting of 0 and see what happens.
I'm wondering if the "Constant Volume" per pass math done internally might be somehow adjusting both Z and X when the spindle slows to simulate a manual compound slide set a 29 deg. or whatever you have it set at.
Just a shot, there is a lot going on "Inside".
Thanks Guys,
RC
BTW....RT, hope you're OK.
I hope you don't shoot hijackers. :P
RC >:D
-
OK FOLKS,
Here it is and if you can manualy vary spindle speed the you can duplicate it.
The threading cycle has been changed from before in how it compensates for spindle
slow down. It's also a matter of degree of slowdown. :P
Generate the Gcode with M76 and have all the cuts .001" deep, 1 to 2" of thread, and run at 100 rpm so you can see what is happening. My dry test had 80 passes.This makes for easier monitoring.
As it should each time a new pass is made the X will move .001" for the next cut. All is good. :) At pass
#10 I varied the speed 70%. I am using the SS so you can't see speed change but you can see feed rate change. The DRO's "seem" to go bonkers......but i don't think so...... ???
The program see's that thread pass as out of the norm in which it can correct, so it takes you back to starting X DRO and does an air cut down to the X value at the bad pass, so it is doing a "tapered" move. ;D
Maybe what it has done or is doing is recalibrating / reseting the buffer for the next pass. But it needs some good data to work with.
The next axis move will now go to the next X pass value and that value is correct, just .001 deepr than the past bad one. Let it continue for 10 passes and each one will be correct. :)
I duplicated this 8 times in the 80 passes.
Now if you stop the spindle, and stop time seems a little time dependant on how it will behave, the Z will just finish the pass ....
the thread would be history in real life .......and the threading cycles will stop. Mach has lost the index...
it has no basis on how to continue.
So either the threading cycle is ******************x'd up or the way it deals with spindle slow down has been changed. ??? ??? ??? ???
RICH
Now I have been convinced, but the mechanical stuff still induces it. ;)
....... ART, Brian please clarify what the proper interpretation of the threading cycle is........!
-
Hello Rich,
As i understand, the trouble is caused by the compensating for unduly changing of the spindle speed?
If so, when I can forcomm slowing down of spindlespeed then it will be OK?
Rieks
-
Rieks,
The compensation was deliberately built in. It was done to take care of Punny lathes, does work, but there is a limit on anything. The better your
spindle speed is to start with and maintain that speed when cutting, and if you can minimise the mechanical influences ( backlash, uneven cutting, poor set-up etc. ) that may cause it to slow down, and if you use good machining practice, the axis components can do their job as it realtes to speed ,then you should do fine.
Threading is a "SYSTEM" of all the components. Not one thing. It's like a sterio, one part of the system not up to par and the music you will hear has been downgraded.
RICH
-
OK so i did some more testing today, and I took video.
First here is a video of my lathe cutting a ball radius on the end of a .500 Ally rod. I intentionally set it to cut the .500 sphere with a z center of -.500 so that it would not only round over the end of the rod, but also have to cut an extra .250 off of the end of the rod. This isn't realted to threading at all, but it does serve to demonstrate that if nothing elsel I think that I do have pretty good repeatability of the X axis, check out the .010 nub that remains until the final pass.
http://www.youtube.com/watch?v=uuz8B3oVLNs
Next is The video of the lathe threading while cutting air as Hood had suggested. As you will see the movements are normal at first, but then when I alter the spindle speed the funny x axis moves begin. I also noticed that these errors can be induced with an decrease, or increase in spindle speed which makes sense though not many of us have a problem with our spindles speeding up during a cut ;)
http://www.youtube.com/watch?v=x-rHNH8VVnI
I do also want to clarify one other thing based on my observations so far. If a thread is to be cut in whatever number of passes, lets say 80, then it will be cut in that number of passes no matter what happens. In other words if the problems begin and the x starts to cut a taper in the air it is in place of a programmed move. It does not appear to me that mach is inserting some kind of extra move in order to compensate, rather it is inserting a funny move in place of a programmed move, and replacing it. This causes the next normal move to remove more material than intended since the prior pass didn't do any cutting. So If I have programmed 80 moves I will get 80 moves, some of them OK, and some of them goofy, but I do not end up with 160 passes of which half would be normal, and half goofy. Let me know what you think of the videos. Thanks
Trevor
Now if i can just come up with a way to convince the wife that I need a 2hp VFD/motor combo that can maintain +- 5 RPM I will be all set ;D
-
Trevor,
Did you read my reply #96. Your probably correct but i didn't spend a whole lot of time trying to find every single thing. I will waite for a reply from
the writers of the software. What more can i say.
I didn't watch the video yet. I suggest for now just do lighter cuts, reduce your velocity a tad, use backlash compensation. It is the way it is.
RICH
-
Hi Guys
there may be two effects here, first, the SS uses its own threading code, totally different from the PP, BUT there was a problem in earlier versions where the PP can do this in G76.. now the SS may have an issue if things slow too much.. dunno havent heard of it.
So, if using PP, can you confirm its latest version, if using SS ,lt me know. I think Greg may have to look at the SS issue if there is one. But Id like to know if the PP is doing it with G32's..
Thx
Art
-
Art, Thanks for the reply I am using the latest stable release.020, and the parallel port, Thanks.
Rich, yes I did read your reply, and your suggestion of lots of lighter cuts is probably the best solution for now. Thanks
Trevor
-
Art, yep, same with me, version .020 and parallel port. No missed steps and no backlash. Single index and usually threading at 400rpm. Exactly the same issues as Trevor and others. Fine with light cuts, crazy X with cuts over about 0.05mm deep in steel when the spindle slows noticably.
Nice movie Trevor!
-
Art,
Thanks for the reply. I am usng the SS wiith the latest plugin. I'll get some info off to Greg and see what he needs,
says, and work with him. Threading on my end has never been better, but, no joy for some others, quite obviously. There are two issues in my mind, namely:
1. Clarity on how the basic threading is "designed" to work ( program reaction to spindle slowdown ).
( Not conjecture ie; based on what i found / posted in reply #96 ) and maybe some flavor of anticipated program
limtations.
2. With one above known, the user or the advice given can better deal with the mechanical system influences
causing a threading problem in the first place. There will be varing degree's of users lathe systems and this is only
the beginning as more users start threading.
I will be bold enough to say it again, SOFTWARE solution to a mechanicaly created one is a patch only and can only do so much. In that light the punny guys got a lot to thank Art for.
RICH
-
Hi Rich:
Fair enough, it may explain why Im confused anyway. :)
The only difference bwteen G1's and G32's is pretty simple. A g32 triggers a threading mode, in this mode the feed speed is modified for the spindle sync, the move is held until the
buffer has enough data in it, then started at index time.
Now, while the moption is happening on that move, ( x,z or a mixture depending on the commanded motion ), the spindle speed is monitored. Lets say it slows by 10%, the output stream timing is then slowed by 10% to match, if the speed then goes up, the output speed of the stream goes up. It never goes faster than kernal speed.
So the command streams are virtually identical, buffered 2 seconds of motion, the only thing that varies is the 25Khz may be slowed to 12Khz ( 50% spindle slowdown sensed.. ) or mayeb 20Khz, ( 20% slowdown of the spindle.), but in the end the only effect coded is a slowdown of the kernal speed.
This is all done in the driver, not the application, it monitors the spindel speed, and slows the kernal is required to lower kernal speeds. Its why Im boggled to try to find an
interaction, ( that apparently must exist) between the X and Z motion. Its as if the Z motion is not slowing, but being canceled. I suspect its only possibel if instead of slowing the kernal it actually moves the trajectoy buffer forward skipping steps output, but if that IS true, then the Z MUST go out of position.. Does it?
We'll track this down to a "Ahh damn.." moment Im sure, but Im justa bit confused abotu where that may be. Can you speak to the Z position, does it go out of
position.. I just cant figure where the heck the extra X motion is coming from if not.. Sounds like Z is goign off, but how the heck can it come back to Z0 if thats true..
Let me know what you see though.. it all helps,
Art
-
Art,
Fooling with it as i write. I am trying both G32 and M76 and they are behaving the same to me.
This is what i am seeing when dry running:
(Decrement = 0.001 pass 1)
G01 Z-0.1 Z IN POSITION WAITING FOR INDEX TO START THREAD
G32 X0.999 Z-0.0997 F0.076923 INDEX / Z ACCEL TO THREAD START POINT
G32 X0.999 Z1 F0.076923 THE THREADING CUT
G01 X1.1 Z1 F0.076923 RETRACT OUT OF THREAD
G00 X1.1 Z-0.1 RETURN TO THE X OFFSET & Z START
G00 X1 X MOVE TO STOCK DIAMETER
NOW THE SPINDLE SPEED WIILL BE SLOWED DOWN, LETS
JUST SAY 50% ( 100 RPM DOWN TO 50 ).
(Min decremant being used)
(Decrement = 0.001 pass 2)
G01 Z-0.1
G32 X0.998 Z-0.0994 F0.076923
G32 X0.998 Z1 F0.076923 SLOWLY- BRING SPINDLE RPM FROM 100 TO 50 AND BACK TO 100
G01 X1.1 Z1 F0.076923 DURING / OVER THE 1" OF THREADING CUTTING
G00 X1.1 Z-0.1
G00 X1
SOMETHING WRONG HERE. IF SPINDLE WAS SLOWED TO A STOP FOR
1 SEC ( 1001 ) THEN PROGRAM CONTINUES. IF SPINDLE IS STOPPED FOR
3 SEC ( 1001,1002,1003 ) THEN THE THREADING CYCLE STOPS.
IF JUST SLOWED DOWN AS NOTED ABOVE YOU GET COMMENT BELOW .
(Min decremant being used)
(Decrement = 0.001 pass 3)
G01 Z-0.1
G32 X0.997 Z-0.0991 F0.076923 NOW YOU'LL GET A COMBINATION G32 "TAPERED" MOVE FROM THE
G32 X0.997 Z1 F0.076923 PRIOR G00 X1 POSTION AT SOME FEED RATE TO .997 ( THERE IS NO CUTTING)
G01 X1.1 Z1 F0.076923
G00 X1.1 Z-0.1
G00 X1
THIS MOVE CYCLE SEEMS BACK TO NORM IF RPM IS STABLE. THREADING WILL
CONTINUE.
(Min decremant being used)
(Decrement = 0.001 pass 4)
G01 Z-0.1
G32 X0.996 Z-0.0988 F0.076923
G32 X0.996 Z1 F0.076923
G01 X1.1 Z1 F0.076923
G00 X1.1 Z-0.1
G00 X1
ANYTHING ELSE YOU NEED GIVE A YELL AND I'LL TRY TO DO.
RICH
-
ART,
but if that IS true, then the Z MUST go out of position.. Does it?
Not according to the DRO's.
And just measured the Z. It dosen't loose position at all ( start and end points). Even when you do a 3 sec complete
stop of the spindle. For a complete stop it just reeturns to the starting Z postion and threadiing cycle doesn't continue.
You will get the error message if spindle is shut off completely that " no spindle feedback seen in G95....etc."
It dosen't seem to lock up MachTurn as i can rewiind the program and just start all over.
RICH
-
Just for info:
Mach Version: R3.042.020
SS PLUG IN: BETA_V015ogb
Lathe threading Wizard: REV 1.17
RICH
-
Art, I am glad that you are working on this with us. I have mentioned before, but I think it may be improtant to answer the question that you posed earlier. At least in my case no matter ow "wrong" things seem to go the controller never seems to loose track of the actual position of the cutting bit. That is to say that I can jog the tip of the bit back to the outer corner of the workpiece after a cycle is completed and it will still indicate that it is at 0,0 just like before the cycle began, as a novice this would seem like a pretty simple indication that the software/controller is keeping track of position correctly. I hape that my way of thinking is correct.
Trevor
-
Hello Art,
In my case, the Z-axis was out of position during the "walk away" of the X-axis.
At this moment , I can't tryout anything, my PC is out of order, but I remember that Z-axis was out for 1 cut,
and than looked to be back in the right position.
I didn't gave it any attention than, because I taught that it was the result of the Z-axis problem.
Rieks
-
Hi Rich,
what is the spec of the thread you are trying to produce and have you a sketch of the part.
I do not understand why you have two G32 lines for each pass
Graham
-
Hi Guys:
Hmm, those are interesting test results. Im not sure I understand all the comments on the first one.. Im also real confused as to how this can happen but I think Im getting closer to
maybe coming up with possible reasons, if so I can test them and see.
First, so the axis never go out of position.. thats good, it measn no loss of information at any rate, so there must be a scrambling going on somewhere.
The 3 seconds does match an internal number I use I think.. its the threading wait for stability and index.. weird that its being waited for though..
OK, so I need to understand a bit better, you say if its slowed down to 50, then slowly worked back to 100, its OK? But not if you stop it for
more than 3 seconds? Or is it ok only if stopped for 3 seconds, but screws up otherwise? Im not sure if Im getting that right.
So if it slows less than 50% and then speeds up is all OK? The error you get woudl be the spindle speed being sensed as zero on start of next pass calculations..
Can anyone tell me what happens if a G32 is single stepped? And you slow it down and back up during the pass, then do the next line.. Does it taper then?
We'll track it back.. :)
Art
-
Graham,
That code is as generated out of the wizard. It's a 1-13 just for the convenience of monitoring the axis moves
as i changed spindle speeds for testing. Two G32 lines??, well that goes back a long time, 8 months ago when i first tried threading. Normaly just use the G76.
RICH
-
Art, can the problem be seen while running the code one line at a time, The simple answer is yes, but only if you do it just right. I tried to run the exact same g32 routine that I have been working wit one Line at a time, and at first I thought the problem was not present. I could it the single button, then the cycle start button over and over watching one move at a time. I would manually change the spindle speed during the cutting pass, and at first I would wait a couple of seconds in between moves, and the problem did not appear. Then I tried again this time clicking the mouse button over and over as quickly as I could again while varying the spindle speed, and to my suprise the problem appeared again. I did this a few times since I found it quite interesting. All of this was done while just cutting air, maybee I should try it while actually cutting? Let us know if you want some other specific tests done, and I am sure that one of us can do it for you. Thanks for the help.
-
Art,
The first group of comments ( 1st threading pass) was info about each line of code and and just confirms that all
is working.
The 3 sec is the total elapsed time of "no spindle rotation" / no spindle index would be recieved by MACH.
It would be the equivilant of a cutter jammed into the stock. When i turn the spindle back on, Z will continue to move down the threading pass and then return to the start point, but the program just stops and you get the
error message. And the axis locations are right where they should be.
The rpm change ( I can't tell exactly, it's probably from a 100 dn to 30 and back to something near 100),
Did numerous different speed changes, and note that i wasn't interested in some "transition %" ,but rather
trying to see if i could consistantly create the goofy x/z move.
It would be the equivilant of the cutter gradualy slowing down the spindle and then the spindle speeding back up
while cuttiing a thread. It dosen't matter if after the slow down you don't bring up the spindle speed as you will get that goofy x/z move in the next pass. The Z velocity will track / increase or decrease along with the spindle increase or decrease and there is no x change of movement during this period.
If you stop the spindle for 1 sec it just seems like the equivilant of a spindle slow down and speed up.
Note that the spindle speed changes were only done during the actual threading move, after it started and beforee it ended. So those changes have nothing to do with a G00 or G01.
I'll go a line by line and see what happens. ( ii see Trevor has already done so)
RICH
-
Here is another related, but dangerously general question. Just how much hp do I need to cut a 1/2-13 thread in 6061 at 400 rpm in lets say 20 passes or less. Assuming that everthing else such as tool geometry/ rigidy and such are assumed to be ideal? I am considering the purchase of a VFD and motor, so I would like some opinions. Do I need 1hp, 2hp, 3-5hp? Let me know as if I am going to buy one I would only like to do it once. I realize that I have asked a question whose answer could be dependent on alot of variables, but some educated guesses, or better yet pieces of practical experience would make my descision easier. Thanks.
-
TrevoH,
May i suggest you just hold off and don't buy anything.
Calc's can be done, heck there are books books written, there are studies by companies for years.
Add a different cuttinig fluid, or cutter and the calc ain't worth poop ( ok, maybe ball park).
RICH
-
Here is a G32 code which you can use for testing and it's much easiier to duplicate the
X&Z goofy pass over and over again and variations on the theme without stepping one by one
thru a large program.
RICH
(TEST OF SPINDLE SLOW DOWN)
G0 X1.1 Z-0.1
G0 X1
M98 P1000 L10
M30
O1000
G01 Z-0.1
G32 X0.999 Z-0.0997 F0.076923
G32 X0.999 Z1 F0.076923
G4 P5
G01 X1.1 Z1 F0.076923
G00 X1.1 Z-0.1
G00 X1
(Min decremant being used)
(Decrement = 0.001 pass 2)
G01 Z-0.1
G32 X0.998 Z-0.0994 F0.076923
G32 X0.998 Z1 F0.076923
G01 X1.1 Z1 F0.076923
G00 X1.1 Z-0.1
G00 X1
M99
-
Ill give this program a shot tomorrow and jam my spindle a bit to see if I can repeat this one... sounds more liek an application fault somewhere, but Im not sure yet..
Art
-
It has been a couple of days, is everyone out of Ideas, or just busy with life outside of CNC?
-
Hi Trevor:
Im still checking the code, but Brian is out of town till end of week and I need to discuss some thigns with him to help track it down.
Expect another week ro so till I can answer as to what it may be and perhaps a fix.
Art
-
Ok Thanks Art, I am glad that you are working on it!
-
TrevorH,
You had asked the following question:
"Here is another related, but dangerously general question. Just how much hp do I need to cut a 1/2-13 thread in 6061 at 400 rpm in lets say 20 passes or less?"
I looked at it out of curiosity a few different ways.
In one way i looked at the HP to shear the cut and had to make some engineering judgements.
Another way was based on SME research out of a 20 year old book i have. Yet another used more current
testing information. The last way was some computer programs which use info from form SME ( Society of Mechanical Engineers ) which is nothinig more than the material removal rate. I assumed a sharp v cut with 10 passes and a high shear stress value. Four or more ways .......all in the same ballpark.
HP required: 0.1 to 0.14
Now you need to find out your motor characteristics for the 1 hp motor you are using.
RICH
-
Rich, Thanks for the research. It is interesting just how little HP may be required to cut threads. I guess that leads me to believe that what in fact may be more important is the torque required to deliver the mentioned HP at a relatively low, and very steady RPM. My motor is rated at 1hp, but at 2500 RPM,much higher than the 5-600 that it is turning when threading. Thanks again for the input
-
Hi Guys:
Sorry for the delay, we're discussing the trouble and we need to know if CV being off fixes this weirdness.
Thx
Art
-
Art, are you doing some testing, or would you like one of us to do some testing for you? Is constant V something that I can switch off during threading, as I do recall I do have my config set to constant v, not exact stop, am I thinking of the same thing, or way off. If you would like something tried out let us know and I am sure that one of us can do it within less than a day, and I am sure willing to try whatever you might suggest. Thanks
Trevor
-
Hi Trevor:
Well, we know that a series of G32's will erronously activate the X and create a taper IF the spindle is slowed down.
I suspect the next move may be CV'ing in somehow. So Id like to know if the G32 series will still screw up if CV is turned off
during the series. Id appreciate it if anyone can tell me if thats so..
Art
-
Hi Art,
I am at someones house and will try to test later today. Problem still exists if CV is not used.
But just let me make sure.
RICH
-
Art, sorry to say all the work I do in the lathe is in Exact Stop mode and I have this problem of a wayward X axis during threading. I've just gone in the workshop and checked again and yep, exact stop.
Attached is my .xml file and one of my G-Code files that I had problems with. I've just run that again and whilst in the (air) cut, slowed the spindle down during the "cut" with the VFD and sped it up again on the way back. And yep, the next cut has X motion. I also noticed, if the spindle is still changing speed at the end of the Z coming back to the start point, the Z axis is then stuck (VERY slow moving) and I have to stop the code - I hadn't noticed that before, but this never happens in real operation.
Hope that helps and I'm very grateful you guys are looking into this.
Woody.
-
Hi Art,
The gcode i used for testing was per reply #118 to this thread.
SMOOTHSTEPPER: MACH VER: 3.042.020
-----------------------------------------------------------------
The G32 code will give you the weird XZ move in both CV and exact stop when the spindle is slowed down.
PP TESTING: MACH VER: 3.042.018 & .020
------------------------------------------------------------------
The G32 code will give you the weird XZ move in both CV and exact stop when the spindle is slowed down.
A 50 to 60% reduction in RPM seems to trigger it.
NOTE: 1.The testing was done without BACKLASH COMPENSATION for the PP.
Values for Shuttle acceleration other than "0" may create a problem in the axis travel from
a weird slow down in travel over distance to an actual stop of the other axis. Shuttle causing values
may vary depending on used computer and were posted in a different related posted.
Those values are posted in another thread on the backlash problem.
2. The weird pass also seems to accur in the G76 therading cycle about every four passes.
in light of all of this heree are some happy pics of a 0-80 threrad using the g32 CODE.
Rich
-
Smooth stepper test.I have had this issue with pp and ss.
With alot of effort I managed to slow my spindle and I get the error
with cv and no cv.I tried a g78 and a G32.same issue.I am free tonight to run
tests if any one needes a hand
-
Woody:
Thx, very nice description. You seem to have narrowed it to a single sentance, ( I like that.. ). So ..
"If the spindle speed is varied signifigantly during a pass, subsequent passes will show a X move during their pass. "
Does everyone agree this seems to describe this error.
Thx
Art
-
yes
-
Art, Yes that is exactly what I believe several of us are describing, I can say that for me the variation in spindle speed has to be over 10rpm. The lathe diag screen says variation percentage, but I think that it is showing a variation in rpm, not a percentage, for example 400 rpm set point dipping to 380 rpm shows a 20% spindle speed error which is actually more like 5% I think. Thanks
Trevor
-
YES, and the amount is aroound 50 to 60% .
RICH
-
interesting..
OK, Me and Brian will put on our thinking caps and see what kind of diagnostic we can put in for this,or see if we can deduce
from your tests whats happening. I must say, this one defies logic. But that CAN happen.
The way the driver works , Mach3 has no real knowledge that the spindle has slowed, so its an interesting trigger point
to find.. Sorry for all the delays here, but its taken me awhile to fully understand .. and its confusing as hell. :)
Im sure we'll soon have an Ah-ha moment and Ill spend days or weeks kicking myself.
Art
-
HMM........Just a thought, but what did you guys change from when it worked?
Version 3.041?? or so ago??
RICH
-
Yep, Art, that summarises it for me. Also, I'd say about 10 to 20% speed dip triggers it on my machine.
If you want to suggest I test with an older / newer version of Mach, let me know.
Woody.
-
Hi Guys:
Found it. In actual fact a RPM change of exactly 50% or more was required to trigger the error. It was not an application error, but a driver error, and a very weird one at that.
This one has been hanging in there awhile. For the person with 20% reduction causing it, I suspect one rotation was measured at 50% and thats all it took. From then on the
error woudl present itself.
Thanks to all of you, good reports, good help in troubleshooting and you made it much easier to find this rather bad driver fault. It might also have affected PP probing in very rare cases.
A fix will be out soon.
Art
-
Art, I am being pretty bold in kinda disagreeing with you since you are now doubt "the man", and I mean no offence, so let me appologize in advance, but there is absolutely no way that I am loosing 50% of my rpm. The problem occurs for me with a much smaller loss of rpm as I have said before. I feel very confident about this, but i will try to see if I can get time later today to test it one last time to make myself feel better about my standpoint. If I am wrong I will be more than willing to admit it, but I am sure that I am not going from 400rpm down to 200 rpm while threading..........
Trevor
-
Hi Trevor,
The "50%" caught my attention as well.
Perhaps you could hold off changing anything until ART provides his fix just to see if that corrects the problem on your end.
If not, we can go from there.
Regards,
Curious wimpy lathe runner,
RC
-
Sure, I will wait for the fix from art, this is all for fun for me anyway, I did just have a thought though, Art, would a reduction of 50 rpm do it? I am still curious about the box under turning Diag showing a percentage label on it. As I have said before if I have a reduction of 20 RPM it says 20% on the box. Is this just a label that the program doesn't even care about, or is it actually seeing it a a 20% reduction, if so I could see a 50rpm loss being seen as a 50% loss. I am probably grasping at straws, but I just don't think that all of us could be experiencing an "actual" real world loss of 50% of our set RPM. One of us would have noticed that by now as there is a big diffirence between 200 and 400 rpm even with a puny lathe like some of us have. I am excited though as I bet that you are close to a solution!!
-
HI Guys:
This is a matter of reference, Im speaking in terms of driver reading of the RPM. However, many systems are not pure in this sensing, sometimes a noise spike can occur and the system will run that section of code, this wont normally affect threading or your RPM display, as it is updated too fast for you to see , but that simple noise spike can make the program "think" that the RPM has slowed by 50% or more for just 1/25000th of a second, a fraction later the system will see the rpm is not really reduced.
Im pretty sure this is what caused the error, and weve fixed it so it will be out within a day or two I suspect, next version you see anyway will have the fix. Dont focus too highly on the 50% thing, internally its more than possibel for it to occur with no spindle slowdown that YOU see, but the driver may have seen several, it takes steps to reduce noise and youd enever see the slowdown.
thx
Art
-
Great news, looking forward to trying the fix ;D
-
Hi Guys:
I think that fix is on the web. Im pretty sure thios one shoudl fix you up, but Im still looking into
other possabilities. Ill have a test driver ready soon if this doesnt fix it so we can test deeper now
that Im on the right track at the very least. So if you still see this X motion, yell and Ill send you a special driver
to help track down the exact position of the problem.
Art
-
Art,
Thanks for the prompt attention on the threading. :)
A little off thread here, but since manny users use backlash compensation,
can you guys take a look at the backlash problem in Mach. Hopefully that will
be even easier. ;)
RICH
-
Rich:
Im not aware there is any issue with BL, works fine last I tested it. Not my baliwick anyway though..
Art
-
ART,
Is it Brians?
Here is the link to the thread i started.
Real pain in the neck, and if coupled with threading can be confusing.
Simply put, it is a shuttle accel value issue.
http://www.machsupport.com/forum/index.php/topic,10855.0.html
RICH
-
Hi All,
Has anyone tried the latest version 3.042.023?
I still get the same XZ move and now there are actualy "two" of them instead of
only one. That was with G32 and using the SS.
Art, send me the special driver when you get it done.
RICH
-
Ok ART,
Give me about 20 minutes or so and will let you know.
RICH
-
Rich:
Is this the repeating code your using?
G01 Z-0.1 Z IN POSITION WAITING FOR INDEX TO START THREAD
G32 X0.999 Z-0.0997 F0.076923 INDEX / Z ACCEL TO THREAD START POINT
G32 X0.999 Z1 F0.076923 THE THREADING CUT
G01 X1.1 Z1 F0.076923 RETRACT OUT OF THREAD
G00 X1.1 Z-0.1 RETURN TO THE X OFFSET & Z START
G00 X1 X MOVE TO STOCK DIAMETER
if so, can you change the first move to a g0 from a g32. So it reads..
G01 Z-0.1 Z IN POSITION WAITING FOR INDEX TO START THREAD
G00 X0.999 Z-0.0997 INDEX / Z ACCEL TO THREAD START POINT
G32 X0.999 Z1 F0.076923 THE THREADING CUT
G01 X1.1 Z1 F0.076923 RETRACT OUT OF THREAD
G00 X1.1 Z-0.1 RETURN TO THE X OFFSET & Z START
G00 X1 X MOVE TO STOCK DIAMETER
Does it still do it? Im thinking the first G32 is being ignored, ( and it shouldnt be necessary anyway.. )
Art
-
Hi Guys:
OK, I think we're narrowing way in..
You can keep the original code as youve been doing, try this exe for me..
Thx
Art
-
ART,
It's not the double line of the gcode. I generated a different Gcode with just a single line of g32
coding. Same problem.
I will change it.
Just a quick question, is the *********x17-2 file strictly for use with a PP? ( the other one would not work with
the SS). That other one would also generate an error if you tried to use the gcode posted in my reply #117?.
RICH
-
Answered my owne questiion in the last post #153.
Here is the code i am using for testing with *********xx17-2 mach file.
First line of g32 code changed to a G00.
Looks promising, but let me fool around some.
RICH
-
Art,
With the changed code and the 17-2 version I CAN NOT get the XZ move to occur.
The threading cycle will stop at around 75% turndown ( 100 down to 25 or 30 rpm to trip it).
I could "very rapidly" stop the spindle ie; 100 rpm down to 0 only for less than a 1/2 sec or less
and the thread cycle would continue on.
I tried to spike the index pulse by varying the rpm numerous times during the threading and stiill the threadiing continued.
The displayed rpm is off in the readout and also in the turn diagnostics by about 5 rpm ( 95-96 vers 100 actual).
------------------------------------------------------
Now i need to replace the first line G00 back to G32 and see what happens.
------------------------------------------------------
One thing i did notice is that if you vary the speed it may keep that speed for a few thread passes.
As compared to a 5 months ago, the Z dosen't seem to be as reponsive to a slow down or speed up
of the spindle. But lets not dwell on that for now.
Think your on the right track!
I'll fool with it more tomorrow as it's getting a little late.
Will stiick arorund for about 20 minutes of so.
RICH
-
Rich:
Sounds good .. Can you see if the original code and the 17-2 works good too?
The RPM being off is due to other changes in this exe, you can ignore those for now,
the fixed version from Brian wont have that strangness..
Thx
Art
-
Will do later today and post what i find.
RICH
-
Art,
The original threading code and the 17-2 version work fine.
Tried it out on two different lathes and three different PC's and coudn't get
the XZ moves to happen.
That extra line of G32 code is not skipped. It happens very fast and in a short distance.
For those following this thread, let me remark that the spindle slowdown can cause
the threading cycle to stop. The trigger point which causes the stop will vary depending on the pc,
but it is not no 10%.
Art,
Can you let us know when an update may get posted. Also will the update impact the SmoothStepper?
RICH
-
Hi Guys:
Thx for the confirmation, Brians code is fixed, update wont be long. PP and SS should both be fine as this fix affects both.
You all did real well here, and I bow to your effort. It was a very bad one to find and your descriptions really led me to the well,
I still needed to be forced to drink, but at least I was at the well.
Id like to hear of any threads you get after the fix and their quality. I have more to fix in threading and any assistance helps.
Thx
Art
-
Hi, Brian
I know your busy, Could you post the updated .exe "Art" was talking about above, So we can continue testing.
Thanks, Chip
-
CHIP,
Reply #152.
RICH
-
Hi, Rich
Thanks for the Info, But I was looking for the update exe for 3.042.023 that Art implied Brian would post with the latest Fix's he made.
After testing there are a few differences in Art's exe as he stated earlier and I was just wanting to continue testing with a version that had only mod's that addressed the threading Fix's.
Thanks, Chip
-
Chip,
ver 3.042.023 is available for downwload. Get to work trying it out. ;D
Thanks for the update Brian.
RICH
-
Dear Brian and ART,
I just tried out threading with the updated ver 3.042.023 with the SS using G32 or G76.
No joy! Etremely sensitive to a change in rpm on my few tests.
I didn't try the PP.
With only a 10 rpm change ( 400 dn to 390 ) the threading cycle faulted.
When it faults the XZ go "wild". Also you get the error
"NO SPINDLE FEEDBACK SEEN IN G95"
Ah.....i need to remember what our good looking Scout mom said:
"IF at first you do not succeed, try, try again" :)
RICH
-
Rich:
If you can, try PP for me, SS uses different code for the most part. If PP fails, then we'll know its a difference form Brians code to mine.. since mine works in your tests..
Thx
Art
-
ART,
MACH VER 3.042.023
When i use the SS the rpm is displayed correctly ( 0-1300 RPM within one or two as measured ).
When i use the PP the rpm is off and over 130 rpm it's useless.
The same happens if i replace the ver .023 mach.exe, with the one from .020, and the 17-2 ( only pp use).
This is true for 2 different pc's.
Since I can't get the PP to correctly display the RPM properly, someone other than myself needs to test using the PP.
RICH
-
Rich:
Ahh, OK, so I take it the encoder index is just too short for the PP to read, so yours is only usable on the SS..
Did any PP version work on that machine?
Art
-
Rich:
>>Dear Brian and ART,
>>I just tried out threading with the updated ver 3.042.023 with the SS using G32 or G76.
Sorry, my bad, Brian tells me the fix isnt yet released on the web, so this test doesnt mean much. :)
Thx
Art
-
Hi Rich:
This version shoudl work..
http://www.artsoftcontrols.com/downloads/Mach3Version3.042.024.exe
Thx
Art
-
Hi, Art
Thank you for letting us know, Just another wasted day in a string of many lately, Your dedication hear is Appreciated by ALL.
Thanks, Chip
-
Art,
Thanks, for the heads up.
Ya know, before playing around all day, i took a look at the revisions in the change log, and it said:
March 17/2009
Release 3.042.023
-- Threading bug found and fixed in Driver... ???
I am still laughing. Must admit that the my index slot is a whole lot bigger now! ;)
Heck, you can use it to cover the half moon hole on the outhouse. ::)
Should make a nice holiday gift for Brian! :) :) :) :) :) :) :) :) :)
RICH
-
Hi Rich:
YEah, sorry about that, that was from when I was pretty sure the driver was bugged. On the bright side it did fix a nasty driver bug, just not in threading is all. :)
That version I just linked to should have the required fixes in it. But it may still bug out, who knows, its an iterative process, but at least we know my code base works, so we shoudl be able to fix it up pretty quick IF it is bugged.
Thx
Art
-
Hi, Art & ALL
Version 3.042.024 seems to work much better, I'm using a 555 timer circuit to simulate the index pulses at the moment so no actual thread report.
Edit: Hope it can be used in the new release Brian's working on. :D
Thanks, Chip
-
Hi All,
Dry ran 3.042.024 a number of times and from what i can see and hear looks like a winner
for both SS and PP.
You can't do the looped G32 file that i posted you'll get an error. Will post something different
tomorrow.
The amount of rpm allowance and readout seems back to normal and movements seem well behaved.
By well behaved i mean, the Z tracks the spindle slow down and speed up and reacts rather quickly to
the rpm changes and dosen't trip the threading cycle so easily.
Will cut some threads tomorrow and see how things go.
Thanks for sticking in there Art, it's appreciated.
RICh
-
Hi Art & everyone else,
These are just a few of the threads done using Mach ver 3.042.24, the SS, and G32 code generated by the wizard. They represent a good range of threading for Punny lathes.
# THREAD RPM IN-FEED ANGLE MATERIAL
-- ------------ ------- ------------------------- ---------------
1 0-80 600 30 WELDING ROD
2 1/4-20 400 29 6061 AL
3 1/4-20 100 20 AL ( THE SOFT STUFF )
4 3/8-16 400 29 1018 CR
5 1/4-40-2 LEAD 200 29 1018 CR
( G32 code not generated from the wizard )
6 1/2-13 400 15 ( TOP PART ) TOOL STEEL
" 1/2-13 300 15 ( BOTT PART ) TOOL STEEL
I coudn't find any pitch problems with 1,2,3,4,6 and the threads look good. The top part of 6 is was not finished as the thread tool holder
moved and the tool jammed the thread, so yes there was a slowdown and the thread cycle recovered from it! The bottom of 6 created numerous slow downs but the thread still came out.
The two lead thread has some pitch problems in the last 1/8" of it but not sure why.
I didn't get around yet to using another computer to try the PP as it is limited by axis speed. The SS will do at least 4x in axis speed as compared to the PP.
So looking good so far.
RICH
-
Thanks RICH, you have hung in this one like an old rusty nail. I really need to thank everybody for all of the work you guys have put into this.
Thanks,
Brett
-
Rich:
Excellent. Thanks for the photo's ..nuthin says "thread" like a nice photo. :)
Art
-
ART,
Maybe you can shed some on this question.
How or what inpact does the debounce input values affect the thread cutting RPM?
I notice if set to "0" that i can get the displayed rpm value to increase but it fluctuates
by say 5 rpm. What kind of stability on the rpm do you need?
Modified to add some clarity:
No problem here with the SS, so the question only relates to the PP.
The manual states: "The index pulse and the other inputs have independant settings".
Now my understanding on the index debounce / debounce interval has always been relative to
homing switches. But if the slot index for threading happens to provided limited rpm, like say 300 rpm ,
and then you go and change the index debounce to a low value you can the get full rprm , like say 1400 rpm,
but it is not stable ( may constantly vary by 10 rpm ). Will threading lock into an average or something?
Rich
-
I am following this thread with much interest as I am encountering the exact same kind of threading problems as narrated by others here.
I am using the index pulse of a differential encoder as a feedback to the spindle and it was pointed out to me that the index pulse width may not be enough for Mach3.
Can someone tell me what is the minimum pulse width or better pulse time (milliseconds?) needed by Mach3? I may use a 555 to stretch the pulse width or time. I know that this may depends on the kernel speed and I am running at 60 KHz kernel speed.
I have tried the Mach3 3.042.24 with PP and it is much better already. However, this is the first time that I encounter my spindle (1 Kw - for a Sieg C6 mini lathe) slowing down to also zero RPM even under no load when threading at a set speed of 300 RPM. Did anyone else encounter this same situation?
Weedy
-
This is from the TURN manual.......assuming it is still valid.
RC
-
Rich:
Index debounce will affect the sensitivity of the index signal. IT basically is how many interrupt periods the signal must be present, or not present before a change is actually sensed in that line. SO if set to 2 for example, when the index appears it will be ignored for 2 periods to make sure it isnt noise. Same with when it disappears. Setting debounce too high will make the index go away altogether.
Since the length of the index is dependent on spindle speed, minimum length is variable, but the time must be at least 1 period at a debounce of zero. SO in 25000, thats 40us. The variation of 5RPM or so is really due to the CPU clock base changing, Im still looking into ways to stop that, but a 5RPM over 300RPM would be .6% of actual rpm being in error at maximum, so you may get a pitch variation of .6% , probably not noticable on the thread. For now, I wouldnt worry about rpm fluctuations if they are less than 2% of total. They should be mathmatically insignifigant.
If a person notices a dropoff in RPM at a certain speed, they need usually a lower index debounce OR a wider tag. Index inputs from an encoder are usually pretty short and will limit speed readings at some point as you go higher.
Im seeing quite a few computers that vary CPU clock rate these days, but most seem less than 2% , most less than 1%, so except in long threads this effect should be mimimal. My plan is to continue to work on that as we see what the effect is, so Id like some PP thread results before I jump into further strategies to make things tighter. The changes to MAch3 and the driver over the last few months introduced many errors that we're finally geting rid of, so Id like to see more empiracal results before moving deeper. It loosk like the SS can be considered working fine now, so as results come in on PP threading , we'll discuss the ramifications to the code and the varying CPU clocks happeing in the more modern CPU's.
Thx
Art
-
tested the fix today.I had increased my hp on the lathe before and this made it possible to thread.
I backed off on the torque and no problem.The random x move is gone.I tried a 3/4 x 8 tpi
at 600 rpm and worked fine.I jammed a 2x4 under the spindle and slowed it down 50% and still ok.
good work on the fix!
Now I have another trying problem,getting my spindle to stop with the same orientation every time?
-
KEITHMECH,
"getting my spindle to stop with the same orientation every time?"
Not sure what you mean.
RICH
-
Rich, he is wanting his spindle to stop and orient, like a mill has to do when using auto tool changer. This is critical on some jobs (like being loaded and unloaded for a second op by robot). Think you will need to use an encoder or possibly just a custom macro, prox switch, and a brake. Really need to start a new topic for this.
Brett
-
Yes I don't want to hijack this thread only a passing comment.This
has been one of the more interesting problems and I'm sure more to come.
-
No problem. So to get this back on threading.
Like, how to pick up a cnc thread once the spindle has been stopped and the piece removed.
Or you stopped the spindle and just want to check the thread anad adjust or take another small
cut. We got it down to a small error just need to think about it some more.
We'll play around a little more than maybe i can ask just right question to Art.
RICH
-
Rich,
possibly using the start angle feature would be the way to pick up on a thread, think Art would have to give you some way to determine what that start angle would be and it doesnt sound like it would be a five minute job to do that but Art has got things working well so far so you never know ;)
If there was a way to stop a thread halfway along a pass in a controlled manner then it would probably be easy enough to pick up, you would just start the threading move, have it stop, move out a bit on X and then put the thread in the chuck and jog in on the X and rotate the thread until the tool lined up and tighten the chuck, sounds simple but dont think it will be ;D
Hood
-
Success, I had a chance to try out the new version today, and although I only had time to cut two threads they both came out great. I am using the P. Port, and I am not sure if anyone else had had success using the PP, but it worked great for me. I cut a 1/2-13 in delrin, and a 1/4-20 in cheap alum, and both are beautifull. Thanks to Art, Brian, and everyone else who had a part in finding, and fixing the problem. If nothing else it will make us all appreciate threading a little more than we would have otherwise. I know I just stood in amazement watching while a thread was cut in a dozen passes just as I had hoped, and with no extra funny moves in between! Thanks!!!
-
So your done threading a piece and your not satisfied or maybe you just want
to tweek it some, maybe the piece has been removed out of the chuck or you just tried the nut and it's tight.
You can pick the thread up in cnc if you wish and tweak it.
Now just make note that threading depends highly on the mechanical aspects of your
lathe. You can tweek either side of the thread flank or follow the minor diameter lead depending on how you want to pick up the thread.
I am only using a single slotted disc. I align / center the slot to the pickup. Placing an fine scribed line on the disc as a reference would be even better.
HOW TO PICK UP A THREAD
-----------------------------------------------
The thread has been cut. Before you remove the piece align / center your index slot
and then place a very fine witness line on the piece with the cutter.
The following applies if the piece "has not been removed" from the machine.
---------------------------------------------------------------------------------------------------------------
The spindle is off, the cutter tip is not in the thread.
1.Align the disc slot to the pickup.
- If your in MachTurn you may want to use the MDI line for a G80 & G94.
2.Move the thread cutter tip into alignment with the point you wish to pick up.
- You can use the root at minor diameter of the thread V, front or back flank of the V,
or even center the cutter tip with crest of the thread.
- Zero the Z axis DRO
Note: Move to your point such that backlash is taken out. Here is were that MPG
with a nice feel and movement comes in handy. I have a 30x microscope attached
to my lathe so that is a great assist also.
3. With the cutter out of the thread, now make - Z move in increments of the thread
lead. ie; for 20 TPI you will move 1/20= .050 increments. You should move beyond
the end of the shaft by approx 3 to 5X the lead ( ie; 3x.05=.150"). Single start
thread so pitch =lead.
- Zero the Z axis DRO
4.Make an additional negative Z move and return to Z=0 to remove any backlash.
5. With spindel on, now do a G32 -Z *********x F.050 from Z=0 where *********x is some length of
the thread and F value is the thread lead.
- Turn off the spindle, G80 & G90, MDI to Z=0
6.Align your disc slot, do MDI moves in lead increments and see if the the cutter tip aligns with the pick up point.If all alligned then no need for a Z adjustment. If not adjust the Z start value by the amount you may have needed to move to get into alignment with your chosen point.
Now you can do G32 moves to accomplish what you want to do.
What you have done is the equivilant of picking up the thread on a manual lathe with an indexer dial. This dosn't take 5 minutes, and if you know what your doing it is rather quick to do. Simply put, you have closed the half nuts, picked up the thread using the coupund slide, tested it by dry running.
This applies if the piece has been removed from the machine.
------------------------------------------------------------------------------------------
1.Align disc slot.
2.Put the piece into the chuck and align the cutter to the reference line you put on the piece. 1 & two must match.
3. Now do the same as if the piece wasn't removed.
Sorry for the detail and hope it's right. My testing showed this to be accurate.
HAVE FUN,
RICH
-
Hi Guys:
For any of you using the PP for theading, can you try one cut only shallow and show us a pic, Id like to see the
size of the crests on it across the thread to just the consistancy of them.
Thx
Art
-
ART,
I can do one later today and make some measurements. I just want to caution you on what you may see in a picture.
Just being very picky here but reading into what you ask for.
First, a few comments about and from my testing and will admit that most are of short lengths of threading.
If you want to adjust lead error based on program number rounding it would be important that the test piece
be done on a very accurate alligned lathe, properly prepared piece, and the result will be only as good as the lathes screw. So if the screw has lead error, say .003 over a foot you may see that error in the pic.
But what are you seeing, error out of the program or error mechnicaly created (this would include the piece setup). Same goes for measuring it ( yes i can measure very accurately but wouldn't want to lead ya into
doing some thing based on bum info ).
If it's an adjustment to the flank cutting that is another scenario.
Here is some pics of A 0-80 and A 1/4-20 threading tests i did along with info as follows:
THREAD# REMARK
1 This shows a taper because of setup and a poor / worn tool
2 Same as above but a better set-up
3 Good 0-80 thread, fresh ground tool, note the consistancy in the crest, root, pitch
3 30X mag of the good 0-80 thred
4 This is a 1/4-20, you can see good thread consistancy. Note that there are "two" scribed lines".
The wider of the two was from wizard generated code and the other was picking up the thread
and to deliberately do an offset of the Z start to test how picking up a thread would work usng G32.
Tracked quite well.
4 30X mag of the tracking
Just wanted to clarify my caution noted above.
RICH
-
ART,
sent you a PM
RICH
-
Rich:
Actually, what Stev is getting on a 4 inch or so thread, when cut shallow, and can easily be seen, is the crests at the middle all look pretty much the same, but the first 4 or 5 crests shows a narrowing of the crest, then it stabilizes to a set width to just about the end of the thread. I was wondering if others are seeing the first 4 or 5 crests showing a narrowing.. As the enclosed shows..
Art
-
Hm...
Was a clean up cut done before doing the threading?
You want a nice round stock, centered / parrallel surface to the Z axis movment,
no spinging of stock or lathe compund, let the rpm settle out, make sure any backlash is taken out, etc.
If your going to compare a surface after a cut you would like any mechanical item
to be elimated as much as possible.
Now see the machine can track a fine line. Do 60 .0001" with a razor sharp v tool ( no radius on the end ) and see how it tracks the first scribed line. That eliminates any motor slowdown issues.
------------------------------------------------------------
My quess would be that with no end bevel the tool shears more material in the beginning
and over some distance settles out on the amount. Some of the above could also come into play.
-
I suspect proper prep was done, Stev and John are pretty good machinists. Im not sure why their threads dont look like some
of the ones here, but John does report his Aluminum threads are good, its the steel ones that seem to vary in pitch as it goes.
Ill run soem diags witha special driver with them to see if turnign off spindle speed correction shows anythign interesting..
Thx for your input..
art
-
First off a little background for the machine.
It's brand spank new and has been designed as a CNC from day one.
Spindle is driven by a 500 watt 3 phase brushless servo with encoder feedback to the driver board, this then drives thru a 3:1 timing belt reduction so it's at max torque at 800 rpm.
True speed at a requested 800 rpm is 800 to 804 and steady.
(http://www.stevenson-engineers.co.uk/files/KC4_27.jpg)
Ballscrews fitted with no discernable backlash, no compound, everything tight.
I'm running the same tests over and over which is a 2mm pitch thread 80 mm long, short threads don't show an error like the long ones and I'm positive that you need to cut long threads and use a tap or known screw as a pitch gauge because a thread gauge fits along the thread due to the fact it only covers about 4 or 5 pitches.
This is what I'm getting for the first three cuts
(http://www.stevenson-engineers.co.uk/files/scratch%20cut.jpg)
Unlike Steve who was getting a narrow land at the start and end and OK in the middle I always get a good thread at the start and an increased pitch at the end causing the land to become very narrow.
At the end of 80mm I'm about 1/2 a pitch or 1mm out.
Art has picked up on aluminium threads being OK but they were shorter ones for a job.
tomorrow, well later today as it's 1:30 am here I'll cut a long alloy thread with the same driver I have on the machine now.
Then I'll swap to the driver Art has sent and redo the threads in alloy and steel, scratch cuts at first.
John s.
-
John:
Thanks, that will be interesting. If the long alloys look the same, and the new driver also looks the same it will point in one direction, if the
new driver seems fine it willpoint in another..
(Nice pictures by the way.. Im impressed..)
The RPM reading is good, Im pleased there.. Whats it do with averaging off? Does it vary allot more?
Thx
Art
-
By the way, nice looking lathe..
-
JOHN S,
Will try a some longer threading 3 to 4 inches and see what happens here.
Nice lathe and trust me when i say i undestand your frustration.
RICH
-
Got a chance to run some more tests on the lathe.
First Art asked if the averaging made any difference, with averaging off it moves between 615 and 595.
http://www.stevenson-engineers.co.uk/files/P1000649.MOV
With averaging on it's steady at 600 to 604
http://www.stevenson-engineers.co.uk/files/P1000650.MOV
Now scratch testing on alloy, fresh tool, machine cleaned and slides lubricated.
First test is 50mm long @ 2mm pitch
(http://www.stevenson-engineers.co.uk/files/day8test1.jpg)
This is typical what I have been getting.
Next test was the other end again cut 50mm @ 1.5mm pitch which is what Steve usually tests with.
(http://www.stevenson-engineers.co.uk/files/day8test2.jpg)
Now I have never had that before but Steve has, however mine looks cyclic in that it looks to be going on a wander at the 50mm end.
So dump the driver, reboot, install new driver, run driver test and reboot again.
(http://www.stevenson-engineers.co.uk/files/day8drivertest.jpg)
Back to test 1, 50mm x 2mm and we get this.
(http://www.stevenson-engineers.co.uk/files/day8test3.jpg)
Now that looks good so carry on and do a full thread. One thing I noticed as it was cutting was the chip load wasn't constant from pass to pass, one pass would take a sliver and the next pass would be a lot deeper. More disconcerting though was it would cut heavier in different parts of the thread.
One pss say at the start, another pass at the end and so on.
Finished thread.
(http://www.stevenson-engineers.co.uk/files/day8test4.jpg)
Using a blued tap as a gauge, start looks good, nice crests but the end is ragged, thin crests and out of pitch. This is consistant with what I'm getting on 2mm pitch threads.
Back to test 2 with the 1.5mm pitch threads. Start again looks good.
(http://www.stevenson-engineers.co.uk/files/day8test5.jpg)
Finished thread.
(http://www.stevenson-engineers.co.uk/files/day8test6.jpg)
Good crests at the start but gets rough towards the end, pitch isn't bad but the tap doesn't want to sit in the threads anywhere, it rocks about as if the middle is right but the ends stop it sitting correctly.
This non compensated driver seems to be the best of the bunch so far.
Shout up if there is anything more I can do or try.
John S.
-
John:
Perfect testing, Thank you. A picture is truly worth more than 1K words.
Very strange results.. not what I expected at all. The cyclic nature is evident in the second photo. .
SO the special driver, ( which simply has speed correction turned off ) seems to do much better, but since its not
correcting the volume is off due to variance..
I have to think about this one before I come up with another test, we're definitely onto something though..
Thx
Art
-
Hi John:
Here is a driver with a subtle change in the corrects.. Id be interested in the result of a thread
on this as you tried yesterday... Id like to see if the cyclic changes are still there..
Thx
Art
-
Hi John:
BTW: the end of the thread will always be ragged with thin crests, the distance of that will be equal to the deceleration of the Z axis, upping your accel for the Z axis will minimize the effect,
Id expect the last few turns to go thin if the accel isnt high enough, if your lathe can handle it, Id raise the accel up as high as possibel as long as you dont lose steps.
Thx
Art
-
Pretty picture time.
Loaded the driver up Art posted and upped the acceleration as high as it would go and did the usual 50mm long 2mm pitch thread, 2 scratch cuts.
(http://www.stevenson-engineers.co.uk/files/day9test1.jpg)
Slight tracking out from midway to the end, then cut this to full thread.
(http://www.stevenson-engineers.co.uk/files/day9test2.jpg)
Not bad looking, crests are out even though the acceleration was right up but still off on pitch. Next run the 1.5mm pitch thread. This was also out
(http://www.stevenson-engineers.co.uk/files/day9test3.jpg)
Didn't bother doing a full thread for this one, so out of interest slowed the acceleration down.
(http://www.stevenson-engineers.co.uk/files/day9test4.jpg)
Tracking better but the end is closed up due to the slowing down, went back to mid point on acceleration and started playing about with speed, so far these have all been done at 600rpm. Going up caused the pitch the get courser and it's already out, dropped down as low as 150 and started working back up.
the pitch of the thread was altering according to the speed.
This is the 2mm pitch at 300 rpm and that's the best one I have cut yet.
(http://www.stevenson-engineers.co.uk/files/day9test5.jpg)
This is 2mm at 600 rpm, double tracking and to course on pitch.
(http://www.stevenson-engineers.co.uk/files/day9test6.jpg)
One funny thing I have noticed is that the first cut makes one track, the second id off but subsequent passes want to follow the second pass as though the first pass is a settling path ?
John S.
-
ART & JOHN S,
Yep, the threading is progressively changing on each cut and it's not in the
code generated by the wizard and not apparent until you do a larger diameter and longer
length threading as John mentioned.
I am using MACH3 ver 3.042.024 and a SmoothStepper and wanted to what would happen.
This thread was done with the Smoothstepper using G32 code generated by the wizard.
Stock is S.S., 0.735" (18.65MM ) OD x 2.6" ( 66 MM) long thread x 0.0788" ( 2MM )
pitch at 300 rpm, 29 deg lead in, 25 passes @ 0.0002" deep. Z clear was set at 3"
( approx 4 times the pitch ). Although not using metric this kind of mimic's a 2mm thread.
Looking at the Gcode the incremental change in the Z is 0.0001" for each pass for a
total of .0024". So if the lines were individualy scribed onto the stock, and you could see
them, then you should have 25 lines at the start of the piece and 25 lines at the end of
thread contained in a width of 0.0024" wide.
This is not what is happening with my single test. I have tried to provide meaningfull data.
Now the first scribed line has 25 "scribe lines in it and contained in a width of 0.006".
which is located from Z=0 at approx -0.3". Now as the thread progresses and the pitch
is increasing ( it shouldn't ) and now have 25 lines contained in a space of .028" at Z=-2.3".
I have attached some pictures:
THRD_JOHNS_HCIR123- composite picture of the next three.
THRD_JOHNS_HCIR1 - shows the thread progressing on the piece
SCALE_THRD_JOHNS_HCIR2 - shows the pass at Z=-2.3" at approx 30X.
60X_WIDTH_HCIR - this picture at 60X shows only the 25 cuts at Z=-2.3.
The small black tick marks represent an even progression of 0.00113".
Hope all the info provides some measurable basis to refine threading. ???
RICH
-
John,
Fruitless trying to come out with a good thread when the threading is in error.
If the scratch lines won't track you will never get a good thread.
Happy I tried something bigger and longer since you had me stumped.
I didn't try Art's recent file. Looks like not much of an improvement.
Don't you feel good knowing that it's not only you! ;D
RICH
-
Rich,
Can you clarify that this test was with the smooth stepper and on one index pulse or from an encoder, if so how many count encoder ?
I was of the understanding that the SS was threading OK and it was just the parallel port that was having problems.
John S.
-
John S,
I used the SmoothStepper and also just one index pulse from a slotted disc.
I also thought all was fine using the SS, but the largest threading i have done was 1/2"
and 1" or so in length. I also demenstrated how to pick up a CNC'd thread using the slotted disc.
I deliberately did the threading this way because never had any problem. Also believe it is not a
mechanical or a diameter of stock issue.
A lot of settings / inputs even mechanical as they relate to threading can have an effect on the thread outcome, but each of those should not create a constant increase of the lead. I could probably
write a few pages on each of that thought. It's basicaly a Z distance related problem and only ART can find what it is.
The data given from my test says there is a 4 to 5x error in lead ( .028"/.006" ) over 2 inches. The scribed lines on the diameter just magnifies it. Lets see what ART has to say.
Please question as ya all wish, as i have been wrong before!
RICH
-
Rich, that looks very similar to what you would get if you didnt have the "Use Spindle Feedback in Sync Mode" checked, wonder if that could be a clue for Art?
I have not done any long threads for a while but may try and do some at the weekend if I make it to the workshop. However I have never had problems threading before, (long or short, large or small dia, course or fine pitch have all been perfect) so my machine is probably not a good test other than to say threading does work for some.
Hood
-
Well my spindle speed sync is definitely ticked.
Hood, Your machine is probably the worse one to do any testing on. With 25 Hp at the spindle driving thru a mechanical gearbox it shouldn't alter speed by a tenth of a rev when threading. What are you using for an encoder ?
Has anyone other than Steve Blackmore tried using a normal encoder with Channel A and B on the Smooth Stepper ?
John S.
-
John, dont have that now, have an AC Servo on the spindle now and its a miserly 12.5Kw and it doesnt go through a gearbox. I am using the Index pulse from the encoder, well actually the buffered encoder output from the drive but the same thing. Dont think you can use the A and B channels yet for anything other than monitoring.
My revs are rock steady in Mach,they dont even jump one digit and I am not using averaging, they do read slightly wrong for example at 500rpm it may say 501 at 1000 say 1002 and at 2000 maybe 2004 but I think that may well be a smoothStepper calibration thing..
As for the sync being checked, I was meaning Rich's test showed similar to what I have seen in the past when I forgot to check it after fitting the pico mobo in and was just wondering if it was possible that for some reason even if it was checked Mach was ignoring it.
-
Hi Guys:
>>My revs are rock steady in Mach,they dont even jump one digit and I am not using averaging
Im of the opinion that THIS is the key to all of it. If the speed doesnt jump in non-averaged spindle, then it means
that computer is ROCK steady in cpu clock speed. In the old days they all were, but latest generations over past couple
years of CPU's vary the clock speed almost randomly even if your not power saving..
I suspect this shows the real problem, random variance of the clock is slowly adding to an error that ccumulates over time.
Its why when I turn off correction, Johns machien actually looks liek a good thread..albeit it off flank cuts during the thread
on various passes, this coule be due to several different spindle speeds locking in as each pass changes the no-load RPM slightly
beofre taking off on its pass. The code assumes non-loaded is accurate prior to the pass and shoudl be the same pass to pass,
tru e on hoods, varying 1-2 on others, 5-6 on others.. Im coming to the conclusiogn this is the real culprit and explains why hoods is so
good.
Im researching to see if I can take advantage of the system clock chip to better define "time" instead of using cpu clocks.. trouble is there
are technical challenges in such a thing.. but Im investigating. Keep up the good work, the testing is proving alow really, the linearity cal seems
unimportant and can be deleted, a new one can be made as a plugin to allow for better fine tuning for those that need it in future.
So it seems...
The thread wandering over time is an accumulation of pass to pass errors caused by the divergence of "time" , and that length shows it best.
Spindle RPM has an effect as the time variation affects the thread in a formula based on steps/pitch x lenth of pitch in some way, again, I suspect
this is accumulating error. Higher the RPM, the higher the variable speed sensed, and this affects them as you go up in speed..
If I can hook into the timing chip in any meaningfull way this may solidify the rpm reading and we'll see what that gives. It'll take me a few days
to see how I may be able to do this..
In truth though, the SS should be imune to this, Greg can read the actual RPM as exactly as it can be done. Rich: , how much fluctuation in speed reading do
YOU get?
Thanks
Art
-
One thing I would add which may confuse the situation is a while back I sheared a key in the headstock and never noticed until a thread had started cutting. The spindle slowed from 1000rpm at the start down to 300rpm at the end (or similar, it was a while ago) I heard this and was about to kill with the E-Stop but I noticed the Z axis seemed to be tracking so decided to let it go, it finished the 10 or so passes and I inspected the thread, it was perfect. It was a short thread if I remember, probably only 30mm long 20mm dia and 2mm pitch, this was with the SmoothStepper so thats why I was surprised to see Rich having problems with the SS, granted his is a longer thread.
Just wish I could figure out a way to vary the servo speed to see what happens on a longer thread, maybe I can use an analogue signal on the drives override inputs, will have to investigate.
Hood
-
Hi Guys:
This test is for experienced testers with PP test only. What Ive done is hook into the main 1,193,181Hz timing clock, and am measuring spindle RPM
with it. This clock should never vary no matter what, so Im interested in RPM readings only. Does this stabalise rpmp readings on your system , OR make
them more accurate. Test with averaging off to see if its stable and correct to your known speed. This method should read to a very high max frequency..
YOu need to install this driver... and copy this new MAch3.exe into your folder.. save your old .exe and driver to get back to normal..
Thx
Art
-
Hi All,
Was off on a trip and just got back.
The "Use Spindle Feedback In Sync Mode and also Spindle Speed Averaging is checked.
The RPM displayed in the DRO will only flicker once in a while and then only within 1 rpm and
I check the actual RPM with a good speed indicator and it says 300 RPM.
The cuts were 25 passes, but total depth was only .005" to eliminate any rpm influence and never once did I notice the rpm change.
I didn't use diagnostics to see what was happening in it's RPM reading ,and unfortunately, when using the SS you don't have a take on the rpm as when using the PP and can monitor with the Turn Diagnostics.
In the latest version of threading you can no longer put a dwell before or after the pass as you were able to do in prior versions. That allowed me to take actual indicated readings on each beginning and end of the Z moves for comparison.
Just for info, no need for comment, I got a buddy who just CNC'd a lathe, has a two horse motor and when geared for like 600rpm it's probably like 5 or 6 hp, for a screw he used a 1-8 tpi of threaded rod and has 0.046" of backlash ( hardware store threaded rod and nut ) . He uses backlash compensation and does small and large threads that look like they came off a high end machine. No i haven't checked the lead on his threads , but the point is, here is a machine that should turn out crap for threads and it dosen't! Mind boggling!
Have a few thinsg to do and then will fool around some more. Want to try ART's rpm test on a few different PC's.
RICH
-
Will run first thing in the morning, midnight here and the bloody workshop is haunted anyway.
Last report of the 2HP motor geared for 600 rpm plus Hoods large spindle motor lead me to thing it's down to feed back from spindle speed.
Problem is most small modern machines use electronic variable speed of some description, unfortunately a reduction of speed will not give an increase of torque like the older pulley / gear driven machines.
John S.
-
Hi, Art
Not getting an RPM output hear until I put pulley ratio to .001, See picture bellow for details, Expanded RPM Dro display.
Using your exe and driver with simulated 555 timer setup hear.
Chip
-
ART,
- PP & AVERAGING "OFF"
--------------- RPM'S ---------------------------------- TURN DIAGNOSTICS RPM'S
PC VERSION MEASURED DRO DIAGNOSTICS REAL TIME APPLICATION
------ ------------ --------------- ----------- ------------------ -------------- -------------------
DELL 3.042.024 299 299-302 299-302 299-302 299-302
ART# 214 299 0 0 299-303 .119 - .120
NEC 3.042.024 300 300-330 300-330 300-340 300-340
ART#214 300 0 0 298-301 .89-.9
- PP & AVERAGING "ON"
--------------- RPM'S ---------------------------------- TURN DIAGNOSTICS RPM'S
PC VERSION MEASURED DRO DIAGNOSTICS REAL TIME APPLICATION
------ ------------ --------------- ----------- ------------------ -------------- -------------------
DELL 3.042.024 299 299 299-300 298-301 299
ART# 214 299 0 0 300-302 0
NEC 3.042.024 300 300 300 299-302 300
ART#214 300 0 0 298-300 0
Here is info on two of my pc's. I included rpms for all of the screens readouts and for both
on and off averaging.
Make sense?
RICH
-
Hi Chip:
Is it varying? Rich: Can you try a ratio of .001 as well as a test.. Im researchign why that may be so..
thx
Art
-
Guys:
Still trying to figure out why I have RPM, but you dont.. Can sopmeone put a DRO#72 on the screen and see
what it says while its turing..
Thx
ARt
-
Hi, Art
Yes, A little, Hears some pic's, Pulley ratio set to "1" now.
Dro39 was in the screen set I used, ;D
Hears both DRO 39 & 72, Note, First 3 pic's shown with Pulse Freq 26479 solid, Last pic shows Pulse Freq 26024 slightly different value.
DRO 39 is Turn Spindle DRO
DRO 72 is Current Spindle Counts DRO
Chip
-
Hi, Art & All
Hears another pic, Pulley Ratio set to ".001", Just to compare.
Chip
-
Hi, ALL
Hears the Test Lathe. lset file, If you want to give it a try, Install it in C:Mach3 folder, It's a work in progress screen Lset.
You need also install the Zip file content (JPG's) in C:\Mach3\Bitmaps\MillBitmaps folder for the Pop-Out Pendent.
Chip
-
CHIP,
Thanks for the file posting. Don't know if I'll get a chance to try them today.
RICH
-
Chip:
SO does that mean your getting a reading of spindle speed of 321.87xx over time, Is it really varying only .00xx as RPM?
I see its 1000 times greater than it shoudl be.. but other than that is it really that low a variation? Is that with averaging off?
And why does the pulse frequency read 8 thousand or so on the diags screen yu posted??
Thx
Art
-
Hi Guys:
Here is a driver and drivertest.exe, Id really liek to see a coupel screenshots form anyone willing to test it. A shot of the drivertest.exe runnign as per normal install, and then this one with the enclosed driver. I need to see the "Longest int" value, shoudl be -1 or -2 on most systems, and how the stability looks after lettig it run fro a few seconds to settle. The new drivertest uses the PIT timer on your motherboard. I need to know why Chip is 1000 times too high, and some of you get 0RPM .. This test may tell me that.
Keep a copy of your old exe and sys file to copy them back and reinstall your normal driver after testing..
Thx
Art
-
ART,
Here are some screen shots using the driver test's.
The file name indicates which is which, namely, Normal Install and Reply 226 driver test.
RICH
REMARK:DELL GX520
-
Hi Rich:
Thx, seems some PIT interval timers arent at the sam eport as mine..
More tests soon of an enhancment to pulse timing that I found while working..
Shoudl make it up to 5us more stable for most people I think..
Art
-
I've been folowing this thread off and on and I just want to throw an idea into the pot.
It seems to me that there may be a conflict between reading the RPM only once per rev and the built in power compensation in some variable speed controllers. I have an ammeter on the output of my Minarik brand drive and I can observe the power changing yet the RPM is (relatively) consistent.
For example, when the tool first starts cutting, the spindle will slow down. Then the variable speed conrtoller will compensate and throw more power at it.
If this all happens within one rotation, MACH has no ability to measure the actual speed that the spindle is turning at the END of the rotation since it only has available the time taken to complete one rotation. i.e. Mach would measure a lower speed since the initial slow down would be included in the total revolution period.
What I'm thinking is that Mach would adjust for the speed it thinks the spindle is turning based on the avilable info, namely the time interval of one revolution, when the spindle is actually turing at a higher speed becuase the controller has compensated and increased the power.
This scenario would self correct over a few revolutions as the rpm stabilized (assuming a relatively consistent stock density) during the cut. This seems to be consistent with the behavior people are experiencing.
If this is the case, more readings per rev would be a potential solution. In this way, Mach would become aware of deviation within one revolution which have been corrected within that revolution.
-
Hi:
Yes, I have been thinking the same thing. And I will be adding a selection to turn off compensation as well as a diagnostic for those vfd's that self coorect. In fact with self correction internal correction may not be
necessary at all. But I have some corrections to implement first to try to stabalise the readings a bit more. Might as well make it as tight as it can be before modifying the methodology used..
I may try to get an enocder to work yet.. I suspect it can be done but I'm still looking into it..
Thx
Art
-
Hi Guys:
This test driver file is for the normal version of MAch3 , whichever version yor using. This driver has been optimised for timing
as I discovered a few things I could do. Hopefully it works fine on your machines. IT should be more accurate as to the end frequency
it settles on, and it shoudl be better at timing resolutions. Run a driver test before and after installing it, Id liek to see any screenshots of
before and after. Your free to use this driver with your original Mach3 , the Spindle RPM's may be a bit better.
CHIP: This version shoudl also stop your frequency locking problems .. Let me know if it handles it for you, no mouse motion or
anything should be required to make it lock in properly. I get 25007 PPS with this driver on 25Khz..
Thx
Art
-
BTW:
Couple question for you all...
If you use SS, hwo is it in threading.. Any troubles or are the threads good?
Same for PP except for the problems we know of in long threads..
Thx
Art
-
Hi Guys:
One last small note. Im about ready to release what shoudl be a fairly good driver test using multiple slot wheels, this is a new mode specially
designed to take into account the problems we seem to be having on single slot, Ive come up with a new theory on controlling the speed more
dynamically and it should be possible to turn off the spindle, the Z will stop, turn it on again and the Z will accelerate up with the spindle.. if it all works.
Is there anyone with multislot capability that could test such a thing on the printer port.. All it will require is a special driver, standard Mach3 should
work fine with this new driver mode (Locked_Spindle_Sync_Mode).
The new algorithm should, if my theory holds :-), allow for a total stop of the spindle because it remembers the slowdowns and speedups. While it doesnt
correct for speedups, there is no way to do that, as long as the spindle doesnt go faster than it is going at time of initial G32 motion, the real position should be
remembered across the entire distance of the thread. within certain limitations of error.
Post if your capable of testing, all youll need is a multislot wheel, 90 slots will have a limit of perhaps 5000-6000RPM on the spindle, 180 slot woudl have a limitation
of 2500 - 3000RPM for synced speed by my numbers at 25Khz mode. A REAL encoder can be used, BUT youd be real limited unless its a low line count. A normal 2000 line count encoder woudl limit you to 60RPM for example .. and woudl require a special test build just for you. :)
Thx
Art
-
Hi, Art
The last driver you posted requires far less mouse movement to lock in the Pulse Frequency now, But it will still drop off with no movement of mouse,
All though with my large Cut Screen and running a G Code file it will lock in while the code is Running, 25K set shows 38,456 Pulse Frequency.
Good CPU, 25K shows 24,997 Pulse Frequency.
Thanks, Chip
-
Hi Chip:
Thx, I suspect htat machien is pretty far gine, the internal timers are acting up badly if thats the case. Not sure I can make it tighter than that, but we'll see how others come out in this test, it may shed some light. :)
Thx
Art
-
ART,
If i made a multi-slot disc would one of the slots need to be bigger and the width basis for the others still the same as a sindgle slot????
RICH
-
Rich:
Hard to say, still playing. If you use a separate index for triggering then youll need 2 sensors, otherwise one slot
will have to be wider than the others..
Art
-
Hi Guys:
Just in case anyone has a spindle with an encoder on it, this test driver and plugin will sllow you to test RPM display and sensing with
either an encoder or slotted wheel with a separate index pulse..
It will not yet allow threading, but will shortly as Brian releases a new updatedd release version to allow the pluin to take over the RPM
display. The Plugin will however, display the numbert of slots, the current RPM , and in G32 mode how much the spindle is slowing.
This is really just a test of RPM display using encoders or slotted wheels.
Thx , any experiences aprreciated, this driver/plugin can be used with any recent version of Mach3.
Art
-
Oh.. just a note..
You input the index pulse to INDEX and use TIMING for the input of slotted wheel, OR turn off TIMING and use INDEX and Encoder#4 inputs as the encoder count input.
Thx
Art
-
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
-
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
-
Hood,
i was under the impression that the ab channels weren't working on the SS for threading ?
John s.
-
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
-
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.
-
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
-
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.
-
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
-
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.
-
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.
-
ART,
Tried out the the MACH3GENERATION4 driver you posted back in reply #231. I used the SS & G76 for trying to cut multiple start threads. Single and double start were fine but no go here on the three start thread as the timimg was off i believe. Lead start point on end of piece varied for the third thread start.
The threading was short (3/4" inch), but overall all, by the time it's cutting the third start it would have been the equivilant of doing a single thread of 2 1/4" long.
Would this be an applicable test for trying out the index timing?
Making an adapter so i can easily mount and try different slotted disc's for testing.
RICH
-
Hi Guys:
Actually, even if we only had a slotted wheel I could give you an indexable home. The question is if we can say withotu doubt that no slots are missed during the time the machine is on. If we KNOW that to be true, Itd be easy enough to give you a button that sets any particular slot to be the index slot. Youd simply revolve the spindle by hand to a certain spot, and hit a button that sets it as the index. There are multiple ways to deal with such things but only if we know that the reading of the slots is absolute and we never lose any.
Anyway, there are several things that can be done with an advanced Spindle control plugin that we can look at over time once we know if threading will work
under the proposed sheme. Id like to simply have multiple setup selection onthe plugin that allow for various configurations, each perhaps with known %error
tolerances on threads.
More as data comes in I guess. :)
Thx
Art
-
So whats the best combination of hardware and software for lathe threading at this point ? I have both a single slot encoder disk and pickup as well as a qaud encoder with index pulse . I am running a cnc4pc breakout board and a smooth stepper , and not agaisnt rewiring etc to get the best posible setup for single point threading very basic single start threads
-
Hi Guys:
Heres a test driver.. Even if you use 1 pulse per rev Id like to know what happens when you try it. You have to load the driver, and the plugin enclosed.
You can set the INDEX timeing as normal, and if you dont have a slotted wheel, set the TIMING input ot the same as the INDEX input. This will simulate
a slotted wheel with 1 slot. Id be interested in your results as a diagnostic. PP mode only though.
You can see the results with the plugin/Advanced Spindle menu item, you shoudl see a stable RPM on the second DRO, but Id like to knwo what they all say.
Take note it takes 64 revs with single slot to get a proper RPM because its assuming a 90 slot wheel at the moment, and averaging over 64 slots.
Thx
Art
-
Hi, Art
Hear are some pic's to look at with simulated pulses single and simulated 4 slot doing G76 threading, Very Nice.
Seems to lock in the Pulse Frequency on my problem computer fine also.
Thanks, Chip
-
Hi, Art
Hears 4 more, 2 with 25 and 2 with 251 slots simulated.
Now if you'd make the "Corr" Barber Pole bidirectional, I'd have a Sync-Row-Scope to Adjust the ratio.
Chip
-
Chip:
Excellent! , thanks. Your numbers are good. Is the Slot based RPM steady? Mine stays within 0.xx of 1 RPM typically.
Correction is not yet turned on, so slowing the spindle will only show you a Q value which indicated exactly how much correction
will be applied in realtime as the thread progresses. Gree means its slowing down from start, red means its speeding up.
Yours seems perfect as long as the slot based RPM is steady.
Thx
Art
-
Hi, Art
I'll try it on my good computer in awhile, Using 2 non locked time sources, Need to find a divide/multiply chip and source off one timebase hear to test further.
Slot based RPM steady? Mine stays about the same as you's, 0.xx of 1 RPM. Flashes red/green when threading, Then red or green with rapids.
Chip
-
Hi ART,
Screen shots using MACH version 3.042.027 along with Chips Lset.
Single index slot.
RICH
-
ART ,
Here are some more as i changed the rpm twice as shown in
1&2A and 3&4A screen shots.
BTW, you can thanks Chip helping me get the driver test set up on my PC.
RICH
-
Hi, Art
Hears 4 pic's of my good computer with simulated, 1, 10, 99 and 999 num slots.
Chip
-
Hi Chip.
Thx, you and rich have pretty good numbers,
your 99 slots seems to miss one slot per rev, and 999 seems to lose about 10.. thats interesting, we'll see how real world
conditions do. I still have one computer reading weirdly so whatever I find may reflect soem weakness somewhere, but you
two are fine fer now.
Thx for the tests, preciate the results.
Art
-
I have noticed what appear to be rounding errors in Mach on the cutter comp routines. If that is related, it may be a place to look. I've had problems like this as programs age and I am continuously modifying them. Usually it (if I ever find it) the problem is old variables without enough precision that never got updated.
Specifically, in Mach I get a distinct perpendicular axis shift at the tangent of two arcs when I used an cutter comp offset of .008 but changing to .009 eliminated the shift.
FWIW
BTW, is there any tought of adding a continuous rotation capability for servo motors?
-
Hii:
Brian has redone cutter comp for futre versions. It shouldnt round though, but arc intersections can get complex in calculation, and some variance can be expected depending
on the acuteness of the angles involved. If all works out , Im willing to add capability to the new Spindle control routines, but at the moment, Im focused only on threading.
Thx
Art
-
Hi Guys:
This is a threading slotted wheel Scoping test. Im looking for Ground effects or floating times. Id love ot see any captures you do on
this one. Just get your spindle going, and launch the scope, select # of samples and hit sample.
If TIMING is disabled, it assumes input from Encoder#4 , otherwise a single slot input on TIMING input.
My kernal is 25us per int on the photo's test, and I see a max 25us or so swing in time, this indicates a very flat and good responce to a very
good and stable input. Id like to see yours.
You need to install the enclosed driver and plugin to use this..
Thx
Art
-
ART,
Do you need version .027 for this test or will it work with 024?
RICH
-
I think this test will work with any version, but the RPM detected will not be passed to MAch3 unless .027 version is installed. The Scope and such will work though in any version as long as this driver is loaded.
Art
-
ART,
The scope is not working for version 024 that i am using ?
With or without the sys file and fooling with the settings.
RICH
-
Rich:
Weird.. Does th eplugin show any slot times being seen? This scope only works on Encoder #4, or TIMING input.. If theres a TIMING input there it shoudl show up in the scope as well as in the plugins dialog as SLotTime
changing as the slots come in. If "LastSlotTime" is changing, then the Scope should work fine.. any version..
Art
-
Rich:
Here's another plugin, it reports each CPU and if it is set to throttle or not, you have to select a CPU number before it will report. If you have only 1 cpu they will all report the same. Does anyone report a throttling? All you need is the plugin for this test..
Thx
Art
-
Hi, Art
Getting very little to no output on scope hear with last 2 Data scope plug-ins.
Chip
-
Chip:
Wow, thats pretty flat a graph..
Well, what Ive dteermined so far is the "maybe" the CPU clock is varying on some systems. Here is a driver and plugin that uses a whole new method, it uses the PCI bus timer, and all results are displayed in uS, not clocks or ms.
Id be interested in your results, you have the most stable system Iv eseen yet, even better than mine.. ( a bit. :) )
This test requires this new driver and plugin..
Art
-
Hi, Art
Hears a pic of the new plug in still no data displayed, I'll try it on my other computer later today.
Pin 10 is assigned to index, Trimming is on pin 11 simulated.
Chip
-
Hi All,
Well no joy here on the graphic display for version 024 or 027.
Tried using the files from reply 264 & 271.
Using a 4 slotted disc and timing.
Here is a screen shot using version 027 and using sys file from reply 264.
RICH
-
ART,
I got the graph to work.
Will post some pics and also a file on what did to do to get it to work.
RICH
-
ART,
Here are some pics at various sample rates.
Kernal speed was 25khz and actual spindle speed was 197 RPM.
I also noticed that if you run the driver test first the rpm in the DRO actualy
will change up or down when you load TURN. The plugin didn't behave very well on my end since one time
I could load a threading program and watch the correction change as it was threading, then it didn't work,
then sometimes it would show 5 slots, then no index based rpm.
BTW, I could only get the graph to display for 32, 64 and 128 samples. If spindle speed was increased
then maybe 16 samples would show. No graph past 128 samples though.
I also attached a file which shows what i did to get the graph to display.
RICH
-
Hi Rich:
>>In the directory where MACH3 is installed replace the "sys" file with the one posted
in reply #271 and also install the threading plug in the reply.
You may also want to create an xml just for testing.
>>>1.Need to go into Windows device manager and uninstall the Mach3 driver
True..
>> 2.Run Mach's Driver Test and that will install the driver from reply #271
Prior to this, check the windows folders for a backup of mach3.sys, delte it if it exists, some peopl ehave backups in Windows folders and the old driver gets reinstalled. I think your driver is still old.. Ill make up another with 1.03 as the version..
>>3. In MACH3 TURN: I am using a disc with four slots of which one is at least 50% larger than
than the others.
- in config - enable the advanced threading plug in
YUP, CORRECT.
- in config>ports and pins>input signals - enable the index and timing using the same ports and pin numbers
ONLY IF YOU ARE USING INDEX AS A TEST INSTEAD OF SLOTS.
but the index is checked for emulated ( if you don't enable the index you may not get a graph, may be a fluke?? )
NOPE< MAKE SURE INDEX IS NOT EMULATED>
- in config>ports and pins>spindle setup - check spindle feedback and spindle speed averaging
DOESNT MATTER FOR THE PLUGIN>
4.Open the plug in control pulldown and click on the advanced threading, click the Launch Scope, select # of samples in the
data scope screen and click capture.
YUP< BUT I THINK YOUR DRIVER IS OLD> NUMBERS ARE WAY WRONG.
Ill post anew one shortly..
Art
-
Hi Guys:
Here is a newer version, if the driver version box doesnt say 1.03 , then you havent properly loaded the new driver. On some systems you need to do a search of the C:\Windows\.. and deeper folders to make sure no Mach3.sys exists, delete it if it does, then follow the install of the driver as per normal using drivertest.
This may be the last till I return from vacation, I leave tomorrow for a week. Be back sunburned and ready to finalize all this rpm testing.. The numbers Chip and Rich are getting seem wrong, and I suspect the driver isnt updating or something, or that the PCI bus timer is too large to fir in 32 bits. Mine does, but I may need to make it take 64 bit values into account.
Thx,
Art
-
Hi Guys:
Heres a photo of my system running test program just uploaded. Ill explain the numbers a bit as well.
Notice the Driver version is 1.03, if yours isnt, your driver didnt load, an older one did.
Notice RPM is about 394.6RPM, 101 slots, slot time is about 1505uS , thats the time from slot to slot. With 100 slots , that woudl be
394.74 approx, so thats pretty good. ( for the math oriented.. the calc is ...)
1 slot time is .001505 , times 101 slots is .152005 seconds per 101 slots, and if we look to the reciprical, 1/.152005 is 6.5787 revs per second, times 60 is 394.74 RPM.. :)
Note the index time ( time from one index to another is 152347.3us or .152347 seconds.. much liek the above calc from there..
Interrupt time is the time from int to int. Its about 21.8uS , ( .0000218 seconds) whic when you divide into 1 second is 45800hz ( my kernal speed at the moment..).
101 slots is how many slots it sees in the TIMING input from one INDEX input to the next..
Main PCI timer base is the speed of your PCI timer, on mine its about 3579545 counts per second. This timer value on a system is documented not to change and be very accurate, its why Im switching to this method. Your number may be similar or not, the program will take this into account.
Your cpu(s) shoudl show your cpu Throttling is disabled.
If TIMING input is disabled, then encoder #3 is used as the counter. If you try a G32 motion, the Q is a quality value, it will show 1.00 if the speed doesnt change after the thread starts. It lowers (?) or raises if it slows or speeds up. In the end this value will determine how much slower the motors move.
Slot based RPM is based on a 64 slot average time, whcih should be pretty stable, but if your fooling it with just a TIMING input set to the same pin as
your INDEX< then you will have to make sure the spindle rotates 64 times before this stabiizes. Threading lock RPM is the speed locked in at start of G32 mode to set the master reference speed.
Index based RPM is the RPM based on INDEX to INDEX input only so you can see if the slots are more accurate.
Last Index Time is simply the time in uS from one INDEX pulse to another..
Last SLOT is the non-averaged last slot time.
The Corr BAR is a visual display of how much the spindle has slowed or sped up since G32 started.
You can test all this by zeroing your Z axis, and simply entering G32Z0 , youll then be in G32 mode, and the Q and Corr bar
will activate. Entering a G0 in MDI will cancel G32 mode.
In the Scope:
I havent yet relabeled the Y axis to uS from ms, so ignore that, its all in uS..
Youll notice on mine that the high is 1517uS or .001517 seconds between pulses.. and low is .001494, so the range is only .000013 seconds or so, thats
very stable indeed.About 1 interrupt time. ( 23us or so..).
The variance from low to high on the scope should really never exceed 1 interrupt time in normal operation. If it does, somethign is varying, ( and thats what Im searchign for. )
Im using my normal INDEX from my lathe, and feeding in a set frequency to my TIMING input from my new PMDX-112 testing baord. ( I love this thing.. :) )
So the slots are simulated, but with a very stable frequency. This way I eliiminate outside causes of loss of timing.
Thats it. Have fun, post pictures, if they are screwed up, not to worry, I may need to change to a lager number handler. Your PCI time may exceed
32 bits. I didnt think it would, it woudl mean a PCI timer running at higher than 4,294,967,295 hz.. 4Ghz would be one high speed timer. :)
As you can see there a fairt amount of design here to show as much as I can get, I really want to find any loss of timing and where it is at. This is the first time Ive used the PCI timer, but as I say, its known to be very stable, so if we can get all this working, your feedrates and such will become more accurate as
I use this timer for other things, pulse counts, feedrate measurments, timign statistics in DriverTest..ect..
Just thought Id explain whats going on in allthis in case it helps in your playing.
Thx for the testing.
Art
-
LOL, forgot the phot.. too much typing.. LOL
Here it is..
Art
-
One last note.. Driver encoder #3 is really Mach3 encoder #4, in the driver the numbering starts at zero.
Ill add one to that in future..
Art
-
Hi, Art
The data scope isn't scaling the ms vertical to match the min/max stats value, I'll try the 1.03 plug in in a few minutes.
Chip
-
One further note for Vista users, when you use the control panel to uninstall the driver, you are asked "Do you wish to delte the driver software?" Select YES
otherwise DriverTest will not install the new driver.
Thx
Art
(I just fought Vista for an hour to get mine to load.. friggin Vista.. Sucks hard..)
Art
-
Hi, Art
Thanks for the Info.
Now have Both Computers showing Scope Info.!!! :D
The one with High "Last Index Rotation us" problem was being caused by having Mach3's Kernel Speed was set to "100K". >:D
Scope trace seems to only work up to 512 samples hear.
Have Fun on your Vacation, Chip ;D
-
ART,
Installed the version from reply #277, did all - checked all - still is not working properly on my end.
Have a nice vacation.
RICH
-
Nice readings Chip.. just like mine. Ill check into why the 512 limit when I get back, and Ill help Rich get loaded .. must be something wrong there..
I see your divider is now correct. .excellent..
Thx
Art
(See ya's in a week.. )
-
Hi, Rich
I think I've found the problem your having, You need to have both index & timing enabled with an active pulse stream or you'll get the high rpm indication.
The data scope doesn't have much pulse height if the Number of Slots is 1 ether.
Chip
-
Chip,
HMM.....so you actualy need another " active pulse stream " and not emulating one of them as i did before or you'll get bum data as noted by ART's reply below.
------------------------------------
ONLY IF YOU ARE USING INDEX AS A TEST INSTEAD OF SLOTS.
but the index is checked for emulated ( if you don't enable the index you may not get a graph, may be a fluke?? )
NOPE< MAKE SURE INDEX IS NOT EMULATED>
- in config>ports and pins>input signals - enable the index and timing using the same ports and pin numbers
---------------------------------------------------
Thinking now, and that is dangerous! ;)
Just leave the timing disc as connected since it's on the back side of the spindle (i made an adaptor to easily make
additional slotted disc's from CD's - use the boy's rap music CD's >:D ) and put the index in the chuck / mount a pickup on the crosslide / 5 volts and two temporary wires for inputs using the 2nd PP .....easy......
I figured i would start off with four timing slots and then do one with say 20 to 30. Disc diameter is limited to
about 3.25".
RICH
-
Hi, Rich
If both are from the same, Examp. 10 you get this.
Give me a call.
Chip
-
The index will only have 1 slot and the timing will have 4 and they wil be inputs from different pins?
Do the inputs need to come form the same PP??
RICH
-
I don't have 2 pp I can test with, don't know.
-
That's ok, since i can disconnect the cable from the MPG's which use the same PP as the timing disc.
Using the other PP may influence it, but then, i can also test that way and see if there is a difference.
-
Still no joy #$%^&* rotten $#@%^& computers @@##$%^ programs !@#$#$^%^
dummy user ! >:( ;D ??? :-\ ;)
RICH
-
Hi, Rich
During some testing this evening, I ran into some Issues with the latest test driver, Mach started to execute G code anytime I re-set Mach, stop feed-hold didn't work only RESET, It was also turning on Single BLK Mode but G code continued to Run.
Testing in Mill Mode, Turns out that it was caused by having OEM Trig #3 & #4 set to pin's 11 & 10 which just happened to be the Pin number's I'm using for Index & Trimming simulation test's.
Edit: Turns out I had them set to Single Step OEM1004 & Cycle Start OEM1000. ??? ???
Wild ride to say the least, Not for the Weak Hart-ed, So be careful for Sure.
On the Bright Side This test driver appears to cure my bad computer's Pulse Frequency fluctuation and get's the speed closer to the Kernel speed set by Mach.
Just a little beta Testing, Chip :D
-
Hi Chip,
The problems here have been a challenge. First i found a ground loop in the controller which had an effect on using pins 10,11,12,13 as inputs. All worked fine for the Two MPG's which used those pins, but no joy when using them
for timng or index. Once that was fixed, and i knew it was not a software, cable, connection, computer problem, then...................
Trying to get another index setup using those pins. Well come to find out that all those junk box photsensors
are different, need to be wired differently, some were bad, but...... i can get then to trigger but not with a high enough voltage to change the pin state from high to low. Thus no rpm readout. Since the voltage for the photosensors comes from the power supply inside the controller via a connected cord I end up screwing the MPG's up if it's greater than 5 volts ( actualy you can fry them!).
Sometimes you just can't win!
Can't buy any sensors locally, maybe i will just use an external pulse generator ( if i can find it / stored away !) for the other index.
On the positive side i did find that ground loop which i never knew existed. It's been a trip! ;D
BTW, two computers, one controller, and none of the CNC machines are usable at the moment!.
I call all this a refresher course in setup! ;)
RICH
-
Hi Guys:
Im back!. :)
Thx for all the testing , I do appreciate it, and how much a hassle it is.
This version willnot show you anything if the driver is not matching the plugin, so Ill be interested in the results. If you have the rigth plugin,
there is a line that say s " 64 bit timer detected..), it shoudl be unchecked if all is well for the present code.
All numbers are in microseconds, both in the scope and the main dialog, and a deviation is shown in the scope as well, mine is always less than 40us and usually about 15.
Be interested in any displays, real or simulated. Ill explain your results as their posted.. I think we're getting close, but I suspect driver versions and loading problems have plagued some in the testing.
Thx
Art
-
Hi, Art
Hope you had a good time relaxing.
Hears 4 pic's, First 2 are of my problem computer (But it's acting pretty good at the moment), Threading Sim works.
On my sec. computer, Threading triggers but wont actually proceed through the G76 code with the Test SYS driver.
Works just fine with ver. .027 SYS driver though.
Chip
-
Hi Chip:
Thx, I hadnt really gotten to the stage where I thought an actual thread sim would work, I was really just interested in the numbers as you show them.
All seems well EXCEPT that your scope on second computer shows an abnormal low reading on both. Does that happen on all captures? There should be only 40us or so max deviation shown, I may be grabbing numbers one slot too early or somethign though.. Try a few different scope grabs and just tell me if its always way above 40us or if its just random.
You show 1102.xx and 1103.xx on those two grabs, I suspect Im grabbing one wrong number somewhere.. Otherwise it all looks good. Ill proceed to other matters based on that when I see how some others are doing..
( Max Deviation is shown on the Scope dialog , its just the high minus the low reading iof the slot times.. That second computer has a very fast PCI timer, the full 2.3Ghz seems to be your clock for the PCI.. thats fast..)
Thx
Art
-
Hi, Art
Once I reduced the slot count down below 90 slot's threading works fine, one computer is fine, it's the second one with low min value .
I have a 100 slot disk to test with, Need to get the second OPTO working and adjusted for it though.
Thanks, Chip
-
Hi All,
Well my neighbor, who has a TV repair shop, may deliver a pulse generator tomorrow which will allow me to simulate a pulse to use along with my timing index.
Chip, you may not standing alone. ;)
RICH
-
Hi Guys:
New version, shoudl show steady RPM's on your displays in encoder or slot input.
Let me know if your RPM's are now accurate and stable if you can.. Ill then start working on the actual threading speed correction algorithm, which will complete ( hopefully) slot based or encoder threading. Then, finally, we get to see
if this all actually makes better and more pitch accurate threads. :)
Art
-
ART,
Hopefully, I'll get the pulse generator today, so i can simulate either the slot or encoder while actually
using what is mounted to the spindle. Can't be of much help until that happens.
RICH
-
Hi, Art
Hears a couple of pic's, I'll post more info later.
Chip
-
Hi Guys:
Found a problem with encoder input, nSlots was counting slots properly. Hopefully thi swill fix that if your using an encoder input..
Chip: Any idea why the number of slots is zero on your? Other than that the numbers look great.
Art
-
oopss..
Here the files..
Art
-
Hi, Art
Hears 2 pic's, First is from my problem computer and Second is from the stable one.
The signal is from simulated pulses, Both computers are tied to the test pulses at the same time, Index/RPM was used to set Index & Timing values, Index set to 200 & Timing set to 400.
Both computers show close to 200 rpm for Index Base RPM's but that's about all that's common to both, Number of Slot's are working now also.
Threading only start's if Advanced Threading Enabled is Checked.
Chip
-
Wow I am glad to see this thread has taken hold and there has been positive progress on lathe threading .
I am still having problems threaading with the lathe from page one.
I dont think spindle HP is an issue , motor is 30hp , Rpm never varies more than 1 rpm no matter how heavy the cut. machine is equiped with ballscrews and has almost zero backlash . Was new one year ago when this project started and has less than 200 hours on it t date. Motors are 2kw ac servos. In my original configuration I was alternating between a single slotted disk and the factory encoders index pulse. The results with both were the same , threads would overlap and starts were random.
After talking with Hood about his threading success I decided the smooth stepper might be the key . I have it up and running nicely , but I am still having problems with threading. The problem now each time a new pass starts, it starts just a few degrees later . On a 3-4 pass thread 40 tpi or so you can only see the problem under a microscope. With course threads like 10 tpi that require 12 or so passes it quite obvious. The valley ends up flat bottom as if the tool has started slightly later or at aprox z-.001 deeper on pass one, z-.002 deeper on pass two and so on.
My rpms appear very stable, all the motors are strong enough there is no mechanical loss. No backlash . I am not getting the variable pitch problems as some folks earlier in the thread, doesnt matter if i thread .5" or 8 inches in length.
What really has me confused is I have a crappy 13x40 enco lathe I purchased in the 80's , very well worn, with dc servos , 2 hp spindle motor and cheap ball screws that turns perfect threads. This one drops 10-15 rpms everytime it makes a new pass but still cuts perffect threads . I have threaded both ends of hundreds of suppressor tubes and thousands of end caps and barrels and it turns perfect threads everytime. The only things I can think of that might be an issue is i am using version 2.54 on this machine, I dont know that the computer has made a difference , I was using a 2.2ghz p4 for most of a year and a few months ago started using an older p3 , and its cut perfect threads with both.
All the above rambling aside , are we getting pretty close to having a workable plugin for threading?
Anyone have any thoughts on what I might try with my big lathe , I have more help in the shop now and plenty of time to get this lathe threading properly and i am willing to try /experiment with just about anything to get the threading ironed out. As far as HP , accuracy and rigidity this thing is a perfect test bed so feel free to throw out suggestions.
-
Richard
I would say by your description you have not checked "Use Spindle Feedback in Sync Mode" you will find that from Config menu, Ports and Pins, Spindle Setup, its over at the top right.
Hood
-
Hi:
>>The problem now each time a new pass starts, it starts just a few degrees later . On a 3-4 pass thread 40 tpi or so you can only see the problem under a microscope.
This is an odd problem to have. (Though Im pleased pitch and such isnt a problem on either lathe, but then it really shouldnt be.). This new thrust is really meant to help
in compensating for computers that vary their internal timing , it is thought ( primarily by me. :) ), that many of the issues with threading are a result of internal clocking
differences in some CPU types and motherbaords. The new plugin is goign to try to address those by getting more accurate data from the cpu and motherbaord and
allowing a better averageing of these random frequency changes. When you average a true random event, you average to zero displacement. So a multi slot
system ( say 90 slots in a rotation ) should be 64 times as stable ( I average over 64 slots in the driver ), and more responsive as its correction algorithm will use a rolling
avergae over the 64 slots so even one slot timing changing from a load will compensate. In theory all this will help.. a lot if Im right, not at all if Im wrong.
Your problem though.. cant see it. Either the license file is acting up ( make sure it doesnt read demo..) or the "Use Spindle Feedback for sync" isnt checked. The only
other possability is a floating time on the trigger (index) pulse or a computer that is internally floating more than most. Almost no reports have ever been made of start
trigger fluctuations though.. normally errors are in the pitch realm, but from variations during cut, not from the start, on 99% of systems the first several threads are
near perfect. There arent enough users to give you stats on how many have issues with threads, but I hear from fewer with problems that I do from people with
threads that are good. Within a short period though I will turn on the compensator algortithm with this current testing.. and we'll see if all is well , better, or worse
with this theory.
Thx
Art
-
That was it, I checked use spindle feedback and the threads look great.... so many settings , buttons and things to configure I just cant keep up. I am glad for this group and all the help.
I have run half a dozen test cuts at 20 tpi , all look great at 40x on the microscope, and more importantly they mesh properly with tubes threaded on the other lathe running mach and the tubes threaded on the Haas . I am going to work with course threads next . Thanks
-
Hi:
Thx for the information. Nice to hear of good threads at any time. :)
Art
-
No Thank You , I have hung in since Master5 and never expected the software would become so full featured
-
Rich
As soon as you described what it was doing I knew exactly how to cure it, had exactly the same when I switched over to the Pico mobo and took me a few hours to work out what was wrong so no way I will forget ;)
Hood
-
I keep loosing communication with SS now and MACH locks up , have to unplug the USB to close MACH . I also seem to have to choose the spindle sync check box everytime I open Mach
-
Have a look in device manager and see if the USB Hubs have power management , if they do uncheck and see if that helps.
If you enable the sync then shut Mach down then restart it should be saved, the xml only gets written to when Mach shuts down properly.
Hood
-
no power management for the usb in device manager.
mach will just freeze mid run , hour glass pops up, motion stops and spindle cuts to 78 rpm . Cannot exit unless I open the cabinet and unplug the usb plug from the smooth stepper. I can then close mach and an error message pops up. I then have to reboot and everything will work OK for a little while. It was happening about every 10 minutes. I reloaded the usb driver for SS and its now just doing it 90 minutes or so. Has done it twice since reloading the driver earlier in the day .
I can minimize Mach when it freezes and go to device manager and SS is not present
Hopefully its something simple. I am so close.
I dont have anything set to sleep or hibernate, no screen savers and all unneccesary stuff is off
-
Try powering the SS from 5v if you are using the USB to power it at the moment.
Hood
-
Hi, Panaceabeachbum
You may want to look at and un check "Allow device to save power" settings in Device Manager.
Chip
-
YEP , that was it , silly power management. Thanks guys
-
got about 4 hours before lost comm with SS after unchecking power management in device manager. I will pull a clean 5v from the power supply in the morning and give it a 10+ hour work out
-
I hooked up an external 5v supply to the ss and set the jumper but I still keep having a problem every 5 minutes to 1 hour where my spindle speed drops to 78 rpm and mach freezes completley. I can open device manager and SS is still present under USB but Mach will not respond.
I can force mach to close and i get the error reporting pop up , below is what it says
szAppName : Mach3.exe szAppVer : 1.0.0.1 szModName : hungapp
szModVer : 0.0.0.0 offset : 00000000
When I click the more details box I get the message below
C:\DOCUME~1\Owner\LOCALS~1\Temp\WER92ee.dir00\Mach3.exe.mdmp
C:\DOCUME~1\Owner\LOCALS~1\Temp\WER92ee.dir00\appcompat.txt
When I force mach to close and then reopen it I get the error message stating that SS is not connected , to close mach , unplug and replug usb to SS and restart Mach.
Any thoughts on whats going on?
-
Can you look at the SS monitoring page when you are aving problems or are you not able to do that?
Hood
-
cant do anything in mach when the problem occurs
-
Have you got more than one SS plugin in the plugins folder? If so delete the older ones.
Make sure its the latest plugin you are using.
Hood
-
Just one , its the latest one from the warp site
-
Not sure what to suggest as if Mach is crashing then its hard to find out if the SS is losing it or if its something else.
Would be interesting if you could go back to the PP and see if everything is stable.
Hood
-
Hi:
The error messages dont really tell much because your forcing it to close.
Is it totally unresponsive in all aspects, can you trigger an Estop for example?
It should be near impossible for MAch3 to lock up when not using the printer port.. unusual at least.
I would delete all files in the plugins folder except the smoothstepper.dll and see if that helps.. It may be some
other plugin causing the lockup due to some bad interaction. Worth a shot anyway.
Art
-
Totaly unresponsive, The hour glass pops up as the pointer and nothing can be clicked, estop does nothing. Its as if its lost comm with the smooth stepper and its waiting .
Forcing Mach to close leaves the spindle turning and coolant on , juast as it was when the program locks. I can then walk to the back of the machine and unplug the SS and the spindle and coolant will stop.
After it locks and I close mach I have to unplug and replug the SS board before Mach will connect with it again.
I have moved all the plugins other than SS to a temp folder , will run it the rest of the day and see what happens
-
Ran about 20 seconds this time, I was just manualy jogging with spindle on . Hourglass cursor is up , spindle is turning around 80 rpms . Estop button, cycle start , pause have no effect. Cant click anything in mach either .
-
Have a look at CPU useage and see whats there. Any Brains or macropumps?
Hood
-
Only brain is for the oiler , cpu usage shows 2%
-
That CPU when its crashed? Try disableing the Brain, unlikely to help but you never know.
Hood
-
yes thats it right now , with Mach frozen, spindle slowly turning
-
Weird, would have expected a high CPU if Mach had crashed.
Hood
-
I dont think its actualy crashed., i think its just lost communication with the SS for some reason or ss has stopped responding . When the system freezes I can walk to the back of the machine , unplug the USB from the SS board and then navigate thru mach, hit the estop , etc , all the onscreen buttons then work and I can access all menus.
Once it crashes it will stay frozen until I either force it to close or unplug the USB
-
It does sound as if the plugin is locked up waiting for the SS to respond, though I didnt think the main loop of th eupdate in the SS waits for USB traffic.. it should just trip an error.
Id mention this one to Greg to see if he can think of anything. The fact that Mach comes back to life seems when the usb is unplugged seems to be a situation where the communications is being
waited on by something.. but by design the plugins dont wait for traffic, they just analyse what has come in.. it does sound like a locked up thread though..
Art
-
Thanks Art, I contacted Greg with a link and description yesterday afternoon. Hopefully he will drop in over the next few days with some insight.
-
thx, Greg is a very good at dealing with such issues. In the end though, it may be Windows triggering some unknown
wait state when the USB locks up, Im really not sure.
I havent looked at the plugin source for awhile, but Im pretty sure we were carefull not to add any code that waits on USB transmission
in the update loop, so Im thinking thi smay be a hardware issue that coudl be hard to resolve.
Art
-
Richard, I think you have two SmoothSteppers, if thats the case what about swapping them and seeing if the problem stays with the lathe or follows the SS to the Mill.
Hood
-
one other thing , I am running the exact same computer , ordered the same day , same build spec etc on a bridgeport mill with smoopth stepper. That machine is having no problems . The only major diff is its running an older version of mach and a much earlier release of the ss plugin.
I wonder if I should start a fresh instal on this machine. I am a little reluctant with all the settings that would need to be reconfigured but also very excited to get this issue sqaured away before I dive into the tool setter, bar feed hyd chuck and hyd tailstock issues.
I will try pulling the SS from the lathe and putting in the mill later today and see if the problem follows the board
-
Take a look at the description of the different plug-ins on the Warp site. May just be plug-in version
problem.
RICH
-
I am running the latest plugin and they older one I have doesnt support threading .
I did pull the SS board form the mill and installed it in the lathe . When I booted the computer the found new hardware wizard popped up , even though the SS driver was already installed. Ran the hardware wizard .
Launched Mach and a message poped up stating a SS with a diff serial number was detected , clicked OK .
I do notice the LED array is lighted diff on this SS than the other one, unsure if this earlier board is different or not. They were ordered about 7 mionths apart. Will be running the lathe for 6-7 ,ore hours today USB gods permitting
-
Well never mind , system froze while I was typing the message above
-
Ok so that proves its not the SS itself then, is there any chance you can swap computers now?
Hood
-
It looks like the red light on the SS goes out when the system freezes.
No they are both heavily integrated into the machines, no way to pull them out and swap easily
-
Sounds like a format is on the cards then :( Could try saving your xml and macro folder and then deleting the Mach directory, reinstalling Mach then replacing the xml and macros folder.
Hood
-
Is that all I need to save, Macro folder, oiler brain and XML file?
I dont mind starting over if its fairly simple. In saving the above files will all my config data, ports and pins motor tuning etc be saved and allow me to set things up fairly rapidly?
-
xml has all ports and pins data etc, macro folder contains macros and also tool tables etc If you have custom screens then you need to save that also.
Hood
-
Uninstalled mach , deleted folder and all contents. Reloaded the latest version of mach, plugged in smooth stepper , installed its driver , loaded the plugin for ss and the screenset.
Launched mach and all appeared fine , cycled thru first part and aprox 2 minutes into second part and once again lost comm with SS . Now instead of mach freezing up I get the message that comm is lost . Spindle motor continues to turn , but at 80 rpm , instead of the 1600 it was running when freeze, coolant still on. Unplug USB and spindle and coolant shut down.
When I reboot computer and run mach I cant get spindle motor to turn anything above 80 rpms , Comm with SS is then lost within 3-5 minutes , same result with either board.
Hopefully Greg will respond to my emails soon
-
What time out do you have set in the SS Config, also have a look in the monitoring and see if there are any errors flagged.
What do you have the controller frequency set to?
Are your axis frequencies set to just above what you need for each active axis and the axis you dont use set to minimum?
Hood
-
control freq is set to1khz, 500mhz on the x and z axis , spindle and all others are set to 256
in monitering the only thig flagged is a check box labled "is still"
not sure where the time out setting is , maybe thats my problem
-
should be on the config page if you have the latest plugin, its called Watchdog.
I would set the axis that arent being used to 32KHz and presume you are meaning 512KHz rather than MHz but whatever it is just set to the setting just above what you actually need.
Hood
-
Also, the message you get does it say something about it will be handled more elegantly in the future or words to that effect? If so try unplugging your keyboard and seeing if that helps.
Hood
-
I am not finding anything labled watchdog , I downloaded and installed the latest plugin yesterday , its labled as vo15ogb.
here is the message I get
(http://www.thompsonmachine.net/img/misc/Image1.jpg)
-
Ah ok thats not the message I was meaning so diregard the keyboard thing.
Watchdog should be in the latest plugin, maybe its called something different, I have a Beta.
Hood
-
thanks Hood, I see the watchdog now , same problem . I have to load a job in the big Haas mill but as soon as its up and running I will be swapping out the computer in the troublesome lathe
-
may be speaking to soon but so far all looks well.
I was pulling the computer out of the cabinet at the front of the machine and noticed I had neglected to disconnect the two 12 foot long PP cables that run to the cabinet at the back of the machine. I detached them form the PC and have been running for a little over an hour with no problems yet , maybe they were acting as a big antenna. Will feel foolish (and happy) if it was something so simple
Will be running it for the next 8-10 hours threading hundreds of suppressor end caps
-
Sounds like that is quite possible, lets hope so :)
Hood
-
had a pretty good run, got about 85 parts turned and threaded before it lost touch with the SS this time. Now its back to dropping the connection about every 5 minutes . Going to try the other computer
-
I installed a different computer , complete format , latest version of mach, latest plugin and SS driver and its losing contact with the smooth stepper within 3-4 minutes , same issue . Not much left to swap .
Vfd is no where near computer , bob or drives , everything is properly grounded . I dont know if its an issue or not but the usb cable from the computer to the SS is about 10 feet long
Any thoughts appreciated
-
VFD always running when it craps out?
Tried a different USB Cable?
Tried grounding the SS? I have never needed to do it but think I remember seeing a few on the Warp forum that had to.
Hood
-
tried a diff USB cable , no change
doesnt matter if vfd is on or not
will ground SS in just a minute
-
back to the original screen set , VFD not even powered up and still losing SS after 5 minutes or so
Also notice a couple of tools in the library lose there z axis offset value every 3rd or 4th time I get a freeze ???
-
I put the borrowed computer and smooth stepper back in the milling machine and now that I have updated it to the latest version of Mach and the latest SS plugin it now loses communication with the ss about every 5 minutes just like the lathe. I have never had this problem with this machine which often stays plugged in and on for days at a time . Considering its doing the same thing now that the software has been updated as the lathe that the issue must be software related. I am pretty sure I have eliminated all the other variables by swapping SS, cables, mouse keyboards, machine, computers, full format and reload on two diff computers etc and now the problem exist on two diff machines.
-
Hi Richard,
Sorry to hear about all of the trouble you've been having. It is strange how USB works flawlessly for some and not for others. Thanks Hood for your determination in getting to the bottom of this one.
I would guess that you would have the best luck shortening the USB cable as short as you can (6 inches if possible), and then using parallel port cables to go from the SS to the breakout boards. I can't guarantee it, but I have had users fix USB communications problems that way. Another possibility is to run a heavy duty ground wire between the SmoothStepper and the computer, in parallel with the USB cable. I suspect you might have a ground loop present, and while it would be best to eliminate the ground loop, you can minimize it by minimizing the impedance between the computer and the SS. Another trick that can help is to insert a self-powered hub in between the computer and the SS. A hub can help regenerate the USB signals and interfere with the ground loop. It would be interesting to see if you can measure any voltage difference between the ground of the SS and the ground of the PC. You can also try plugging things into different outlets. Please let me know if any of this helps. If it doesn't we'll keep at it.
Thanks,
Greg
-
I have no problems whatsoever and the machine I build runs several hours every day. It's a Servo machine. We have another stepper based machine in production which caused the mentioned problems and they are mostly related to a long USB cable, and significantly related to the NOISE from the stepper's which telegraphs into the rest of the system. It is crucial to shield the heck out of a stepper based system to eliminate interference. SS might have issues but there are no catastrophic outages or failures. Several million lines if g-code have been processed here with speeds between 10ips and 1200ips on systems requiring high step frequencies to achieve that. Any problem related to communication loss or other significant events alike must be related to the setup in our experience. Two issues which bug us a lot are the fact that increasing the feed speed above 100% is not possible and that the CV mode has major issues. We are looking forward to the next version and some Mach3 CV enhancements.
Rainer
-
I will be back on the project all day today , the only thing that bothers me is since updating the software on the second computer the machine it lives at is now losing comm with the SS also making me wonedr if its plugin or software related.
I wouldnt doubt there is a problem with long USB cable on the lathe , its nearly 10 feet from the front of the machine where the computer is located to the control cabinet at the rear and the cable is 12 feet long . I will try running the USB cable in a piece of metal conduit the entire length along with ground .
Another thing that is odd is I loose communication even when the machine is sitting idle with spindle off and no motion . I am sure it will be a simple fix once figured out .
-
Hi:
Just a note on the "feedrate over 100%" issue. I recommend on SS systems that people post their code at twice to feedrate they desire, and program Mach3 to come up at 50% feedrate at all times.
This allows you to adjust feedrate up to 100% thus doubleing the speed anytime you wish. Setting it back down to 50% would give you the desired feedrate.
Id do this internally, but the printer port is limited in max speed, and it would waste bandwidth for the printer port where people may want 100% of the kernal speed available all the time. In the case of the SS though, it is so fast that it would be rare to max out its capability. Running at all times normally at 50% and posting at 200% would solve any issue with speed. ( At the cost of being carefull that your at 50% when running normally. )
Eventually though, this will likely all be done internally thus giving a capability of more than 100% of speed. There are technical issues with just allowing more than 100% as a norm, because the acceleration profiles and such woudl be overrun thus making it accelerate too hard and decelerate too hard.
Art
-
Art
What would happen with threading with regards FRO being 50%, I seem to recall that there were issues previously if FRO was other than 100% and threading was attempted, maybe I am just dreaming though.
As for SS, Greg has put the FRO back to Mach control in a Beta plugin I have tested (and still have) on the mill and it works great for me. There was a problem when going below about 10% FRO but that turned out to be a Mach issue and Brian fixed that up and if I remember right it was put into Rev 027. So if/when Greg releases that plugin the issue of FRO should be resolved.
Hood
-
Hood:
Good point, threading woudl be an issue, to thread youd have to set the feedrate properly as the program auto sets to 100% for the threading run..
Art
-
I thought the profiles are calculated on the fly. If they are not, then that explains everything. I understand that it will make the gantry fly of the table if someone would enter 1000% ;).
Also the use of different feed speeds for approach and things alike makes it even worse. The approach speeds are low already and setting things to 50% is making that a crawl and hot running tools. If the 50% rule should be used, then there would have to be several F1, F2,F3 etc.... which then would need weighted factors. of course that would now make a complete mess out of the problem lol.
Rainer
-
I have moved the computer to the rear of the machine and have a usb cable only a foot long between the computer and SS and I am still losing comm with SS every 5 minutes or so . I just cant think of any other variables to try
-
I dont know if this helps but when i reboot the computer I have to unplug and replug the USB going to SS before mach will communicate with it.
-
Try going into device manager and see if you can rollback the driver for the SS.
Hood
-
I have done a complete format on both computers as of yesterday so everything before yesterday is gone
-
Did you use the same download of Mach, SS Drivers and SS Plugin on them, might be one or all of these are corrupt, try downloading each again.
Hood
-
downloaded everything fresh and attempting to instal. Now I get a message when I plug the SS in that says unrecognized USB device . Uninstal driver and run new hardware wizard to re-instal driver and I get a message stating there is no better driver than the one already installed.
-
Try using FTClean to wipe out all traces of the drivers then reinstal.
http://www.ftdichip.com/Resources/Utilities/FTClean.zip
Hood
-
ran ftclean , replugged the ss , same problem just says its an unknown usb device and cant instal the driver , keep getting the no better driver for your hardware message.
-
Sounds like your USB Hubs are screwed in windows, try deleting them in device manager then restarting and letting windows reinstall the drivers.
Hood
Just another thought, make sure you have the jumper for power set the right way on the SS, may be you are trying to power from USB but its set for external or vice versa.
-
thanks , deleted usb hub and reinstalled , recognized smooth stepper. Still loosing com with SS after about 5 minutes. Wife has ordered me another computer try
-
Double check to make sure the Power saving is switched off on the root hub that the SS is connected to.
Hood
-
Hi Guys:
New version of threading plugin. This is for Chip , I need to know see a snap of the scope capturing
about 1024 samples.. There is a new DRO to show what sample number is causing that wrong minimum time
reading..
We ARE getting very close it seems, numbers are looking good all round, next stage will be actual threading
correction algorithm being turned on if this all works..
Thx
Art
-
reloaded xp serv pack 1 on the mill and loaded the latest drivers from the manufacturer and its now communicating with the SS again and running fine.
I did the same on the lathe and it now communicates fine for two or three parts and then looses communication if I get chatter from the parting tool on larger parts .
I am unsure why this is happening or how to resolve. the VFD for the spindle is on the wall aprox 5 foot behind the machine , the computer is at the front of the machine and the usb cable runs thru conduit to the ss which is in a very heavy steel cabinet at the back of the machine. I am guessing the vfd is now the problem. If the door is open it will loose contact with SS as soon as the spindle starts. With the door closed it only happens when the tool chatters. On small parts where no chatter is present it will run for quite a while. The control wire for the vfd runs into the same cabinet as the SS and comes within aprox 2 feet. The cable is sheilded and grounded but there are 6 wires that are exposed for aprox 4" that run over to a terminal block. Could this possibly be my problem and how would I resolve?
-
Hi, Art
Get you some Pic's in a bit.
Chip
-
Hi, Art
Hear are some Pic's of my stable computer, More to follow.
Edit: As before with number of Slot's above 80 Threading will not Start on this computer.
Chip
-
panacea....m,
Been following your thread some, and still confused by it.
I don't know if you have one problem or two problems, namely computer or noise / rf or even a combination of the two.
1. The ss should not be loosing communications with PC when VFD / motor and other influences
are removed from the picture. That has to be achieved, got to start somewhere.
I would recomend divide and conquer. If that's in place then you can in a very disciplined way go about identifying
another culprit if there is one.
2. Noise / rf can be a real bitch. VFD and motors are prime sources of it. Shielding is meant to keep a noise out or inside the protecting conduit. You can for example, inductively pick it up and makes sure it stays mixed by keeping it inside a shield. Or you can provide a path for the noise \ rf along the shield and get it ito the grounding. Bitch is you can't see it, you can measure it somewhat to get a mental picture of intensity, and then use some logic or "black magic" to cure it. So sometimes easy, or logical, or complex, or black magic .....just a bitch.
You change one parameter , like opening the VFD cabinet, and you have a whole set of new possible cause and effect conditions. The motor starts and creates an atomic bomb of noise, or the noise just gradualy builds from it and evently affects something. Sometimes the only way to get rid of a electric field is shut it down so it resets back to zero.
Divide and conquer,
RICH
-
Hi, Art
On my non stable computer, Threading will start at above 80 slots.
First 2 pic's with stable Pulse Frequency, 3'rd with mouse movement, 4'th without mouse movement.
Can you set the scope to stay on top.
4 more pis's one post UP, Of my stable computer.
Chip
-
Thanks Rich , my problems with the SS have been multi fold . I was having USB driver related problems which I eliminated today with a fresh instal of XP pro and new drivers from Dell .
Now that I have eliminated the USB problem I can succesfully turn parts for quite a while until there is a heavy load on the spindle and I get interference .
I can turn , thread and part off small alum parts (sub 2" diameter ) with no problems as long as I dont take heavy cuts , as soon as I take a heavy cut I can hear that audible high pitch from the vfd and thats about the time I loose connection with the SS. As long as the cabinet containing the SS is closed I only loose comm when there is a fair load on the spindle.
If I open the cabinet door which faces the vdf I loose comm instantly .
So now that the USB issue is fixed I am just down to chasing down this interference issue from the VFD. Tommorow I will be encasing all the wires to and from the vfd in metal conduit. Hopefully this will help .
Would it help to put the SS in an enclosure of its own? Its in the main cabinet with the servo drives and BOB, plc etc which is aprox 3' wide x 4' tall. There is an identicaly sized cabinet beside the control cabinet that contains relays , control for the hydraulics and a a few transformers should I try moving the VFD from the shop wall into this cabinet ? I can move a few transformers around a squeeze it in if it might help?
I am just not sure if the noise issues from the VFD are being emmited from the unit , its wiring or a combination of both. Should I be looking at isolating the source of the interference or insulating the SS from it .
Ill stop rambling on , just feel I am getting very close to finishing up a year long project . Thanks Richard
-
pana....m,
There was a good post where grounding and noise was discussed, but as usual can't find anything ( in the last year ),and with a similar setup problem,maybe a mill and and eventualy a proper ground system was put in and all was good. Would be worthwhile reading for you. The best i could do is talk
about noise / rf interference and give you some experience / guidance to go by. Otherwise i will be writing a book here and driving you crazy. It's your nickle just send me a PM. Post a few pic's.
Elimination of the problem is prefered, minimize, try to control, it's a matter of degree.
RICH
-
One thing to be aware of is that the VFD creates noise in the supply line also. This noise travels back the supply line and can enter the SS through it's power supply. How is the SS powered? Does it have it's own 5V transformer? Does the supply line for the VFD run near other lines which maybe enter the control cabinet? Which make VFD is it?
-
its a 30 hp VFD from automation direct. I have a 40 hp rotary phase converter on the wall aprox 5 feet behind the lathe . The power from the phase conv runs into a circuit panel where its distributed , one leg to the vfd on the wall right beside it. The rest of the machine receives its power thru a delta to wye transformer. Off to search for the vfd noise related thread so I can stop cluttering this threading thread up with unrelated post
-
Hi Guys:
New version. Liek to know if you can thread now with more slots Chip..Your latest photos looked great other than
that. This version shoudl also slow the Z if the spindle slows in a thread run.
Art
-
Art or Chip,
Is this version for real threading or just simulation?
RICH
-
Rich:
Should work for real in theory.
Art
-
Hi, Art
In simulation it appears that you need both Index and Timing pulses to get threading to start, Slowing Index during pass doesn't seem to take affect till next pass
Number of Slot's work above 80 on both computers now, Scope on top still doesn't work.
Thanks, Chip
-
Chip:
You need Either INDEX and TIMING inputs, or INDEX and Encoder#3 inputs to start threading..
The slowdown is caused when it see's the slot times change or the encoder timing change.
Art
-
Hi, Art
Thanks for the clarification, Yes in fact it dose work, Down and back UP to pass feed rate as Timing changes.
I wasn't changing the timing enough to see it working.
Back to getting both OPTO's working on my Compact 5 for some actual cutting.
Thanks, Chip
-
Got my issue all ironed out , simply put the SS board inside the computer cabinet at the front of the lathe , wired it to an internal USB on the motherboard , mounted the two DB25 connectors and ran 2qty 12' printer cables back to my BOB at the back of the lathe and it seems to be running like a top. Dont know why I didnt think to just move the SS into the computer case 4-5 days ago , would have been much easier since i already had the printer cables routed anyway
-
pan...m,
:) Good for you. My SS is also mounted inside the pc case. Common grounding, case shields the SS, the cable from USB to SS
is short and also has a choke on it. Taking a moment to think now about what you eliminated to get results would be benificial. It could have been a one or combination of things.
RICH
-
Hi, Art
Hear are 3 pic's, First is my cpu with puls ferq issues it seems to thread and not have issues, the other cpu still has issues.
I think I finally have my comp 5 OPTO's working now, 100 slot disk, Both cpu's will not pickup index slot with spindle speed at 250 rpm but will
pickup and calculate the 100 slot numbers value at spindle slow down to stop when it's turned off (spinning down).
(original small index slot on disk). It may be the index opto at fault, The timing opto picks up and triggers at 250 rpm and faster.
Anyway to make the index pulse pickup the smaller slot width the way the timing slot dose on your end.?
Chip
-
Chip:
Sounds like a defective opto or setting of sensitivity. There's no way to fix that, it should trigger on every index, and it shoud be at least teh same size as your timing input slots..
Art
-
Hi, Art
The previous Indexing code needed a very large window to allow Mach to see the change of state of the index pulses.
Was just checking that, In fact this new way of getting Index and Timing values are the same in Scope/Code structure now gathering the Data.
As I stated in previous Post, "Hear are 3 pic's, First is my cpu with puls ferq issues it seam's to thread and not have issues".
( The snap shot was taken with a cut in progress and with a Stable Pulse Freq. During the Scope Data gathering Time ).
( Simulated, Signal Source is a 555 timer for "Timing" with a Divide by 10 Decade Counter/Divider (MC14017BCP) IC used, Both computers sharing the same Data.
The Index Base RPM, Threading Lock RPM and Slot Base RPM are the Same and quite stable on this computer.
"the other cpu still has issues." Pic's 2 & 3. With the Main PCI time base being Large and the Scope readings off Scale as before, But you can see the "10" Number of Slot's & Index Base RPM's are consistent & the Same on Both Computer's.
As you know all this information takes allot of time to gather and keeping it sorted out, So please let me know if it doesn't make Sense.
More to follow in a Bit, A comparison with Index/Timing pin's set the Same.
Edit: Well as usually happens, Had 2 "Comp. 5" opto's sensor's to test with, ( Go figure, "Art" ), It dose appear to be an issue with the "Index" opto's.
( Digging the potting compound out to see what "Emco" did to make them so different in response Time ).
Any way for the computer that threading works with (Pic 1), The values are very close if not write on the money, Other computer, (Pic 2) is still not threading and showing bad data,
If I can find the other MC14017 chip's buried on my desk, I'll do some 100 to 1 comparisons with the 100 slot disk on the Compact 5 while I find another couple of opto's, If the Digging isn't a Success, Eating some "Chile" to see if I can make the Heartburn Worse.
Thanks, Chip
-
Hi Chip:
Thx for the readings. Id say you can ignore the "funny timing" computer at this point. Its numbers seem fine.
The other one I can see is due as you say to "large" numbers being seen. Ill reduce them in next version.
The only question I have is if the Scope @Sample# reading is always 0 on that minimum number..
I dont know whats up with the EMCO opto's.. I dont have one for my emco, I used my own in the end.
So let me know if the @Sample# seems to always read 0 in the minmum DRO, and other that that Id wait for next version,
I think its about done, but the timing will have to be reduced further to fit computers with your very high timing base..
Thx
Art
-
Hi, Art
The @Sample# Min reading is Not always 0, In fact threading is actually working today.
Hears 3 more Pic's.
Chip
-
Hi Chip:
Ahh, I think I see why the scope screws up.. Try this plugin..
Art
-
Hi, Art
Getting Wrong version error, Should there be a new sys file with it.
Chip
-
Chip:
Sorry, this one shoudl work...
Art
-
Hi, Art
That may do it, The Slot Based & Thread Lock RPM show high compared to Index Bash RPM and not like my other computer.
It seems to cycle through 3 or so states, I'm trying to sort it out and get some good pic's of this to post.
Thanks, Chip
-
Hi, Art
Scope seam's good so far, Would you set it to stay on Top in next revision also, Please.
The fast PCI computer, With Number of Slot's at "10", shows proper spindle RPM, With Number of Slot's at "1", It shows Incorrect spindle RPM, Also note Slot & Threading Data info.
Almost There. :D
Thanks, Chip
-
Chip:
1 slot per rev? Shouldnt ever happen. If a user only has one slot per rev, then they should use the original threading scheme in Mach3, but more than 1 is OK.
Weird numbers may result with low counts. When you enter G32, the average slot time is locked, if the spindle speed changes after that weird numbers may result.
In phot #1 it looks as if G32 mode was entered, then the spindle speed ( or slot speed ) was slowed down. This means the RPM was 258 at G32 time, but then was raised to
1016 after G32 was enetered. You need to enter a g0 to get out of threading mode before changing the spindle RPM, (OR ) the spindle didnt rotate enough times to average
before G32 was enetered. It takes 64 slots to average, so if the number of slots is 1 it takes 64 rotations before you could enter G32, if 10, then 6.4 rotations is the
minimum beofre it all averages out and G32 can be entered. Looks like in testing G32 was entered, then more testing and spindle speed was changed during this testing while still
in G32 mode.
In Photo #2, the same effect seems there, the spindle speed was greatly changed after G32 mode was enetered. You have to be carefull that G32 mode is only entered with a spindle that has been running
and has rotated enough that 64 steady time slots have been read before entering G32 mode.
The fact that the average slot time is so far away from the last slot time seems to indicate all this. The average slot time should, except when the spindle slows during a thread, always be close to the average time.
Does this sound true to the way your testing? ( Or are my numbers screwing up? )
Thx
Art
-
Hi Art
As I stated in earlier post, "It seems to cycle through 3 or so states, I'm trying to sort it out and get some good pic's of this to post".
I need to work on video capture some, Then I could post this issue.
OK, Are there any different registers / addresses to get the cpu clock's for Timing value or a method to refresh or set it's mode with the Plug-In.
Also It seems that the "Plug In", Doesn't Re-Set it's self or take another look at the "Number of Slot's" Value for a re-calculation.
At the moment the Fast PCI comp. is showing the 10 slot correct and I haven't been able to get the cpu clocks to shift.
2 pic's of my other computer with "10" and "1" slot's and 2 pic's of the Fast PCI computer,
Same Index / Timing Input's data is used on both. Times are not varied or changed and stable before threading is started.
( Simulated, Signal Source is a 555 timer with a Divide by 10 Decade Counter/Divider (MC14017BCP) IC ).
With 10 Slot's, Timing Input is 555 timer speed and Index is the divide by 10 from the Divider IC.
With 1 Slot's, Timing & Index Input's both use the divide by 10 from the Divider IC.
Thanks, Chip
-
Chip:
they all look good except the last photo. The problem is in the driver for that one. It isnt expecting only 1 slot, so the average tim ebetween slots is too high,
and that causes the trouble. As long as its got the ten slots to work with , it seems all OK, this same problem would happen if the RPM was too low in a 10 slot system though
as well.
So Im not sure if I want to subdivide it more as yet to cure that possability, its only meant to read down to a certain level, and I recommend at least 10 slots on a disk.
Ill wait now till some actual threading runs are done. Steve has been running some for me, so more test results are expected soon. Ill redo a version then to see what I can
do for the rest of it all.
Thats good for tests for now. I think Im about done till actual threading runs are done on various machines. That will tell us how the corrective speeds are running.
Thx
Art
-
Art,
Is Steve using a low count encoder? Make, model, etc....any info on it? I don't have any trouble ordering one and would just skip the fooling around with simulation on my end. I finaly got the loaner pulse generator. So will try
and see if i can get some screen shots to you if things work out tomorrow.
RICH
-
Hi, Art
If "Steve" or others out there could post some feedback on there findings that would be nice, I've talked to Rich and know he's close to doing actual threading again soon.
I'm moving on to encoder A/B timing Test's, While I twiddle my fingers for some opto's to show up, To fix my Comp. 5's index Issue's. Heck maybe a 3'rd computer to test with is in the future.
Scope is working fine on both Computer's as long as the "Average Slot" Time Isn't a Negative (-) Value.
Didn't you Discover an Issue with ( Integer/ Non-Integer ) and "Mach3.sys" Code for Handling CPU Timing Issue"s, " Homing Zeroing Error's ".
It had "Brian" scratching his head as to how I had helped on that one.
Back to the Trenches Hear, How about Someone sending some additional Supply's, Were getting a Little Low Hear. ??? ;D
"Rich", Help's on the way' !!!!!!!!!!!! ;D
Edit: Hi, All, I went back through the Post's, On page 24, "Art" posted this on the Encoder Setup.
"( Oh.. just a note. You input the index pulse to INDEX and use TIMING for the input of slotted wheel, OR turn off TIMING and use INDEX and Encoder#4 inputs as the encoder count input. Thx Art )"
Man, ??? There's been Allot of hard work on this Topic, All the Way Around By ALL, and Again, Thank You, "ART" MR. COOL 8)
Thanks, Chip
-
Hi Chip:
>>Didn't you Discover an Issue with ( Integer/ Non-Integer ) and "Mach3.sys" Code for Handling CPU Timing Issue"s, " Homing Zeroing Error's ".
It had "Brian" scratching his head as to how I had helped on that one.
Cant recall that one, but its likely, Ive gone through a lot of chnages over the past year in the code. Your scope readings showed the total for the averaging was
overloading. Your timer is so high a value, that adding up the 64 numbers required for an average, made the total more than 32 bits can hold. So now that we're
64 bits, it seems OK. Bu tin the driver, even the 64 bit total overloads unless I subdivide it. Thats how large the numbers are that we're dealing with. The counter on your
fast machine is counting from 0 on one slot, into the billions till the next slot hits it. Thats pretty high resoultion, pity I have to nerf it down some. :)
Steves tests, ( Steve hates web forums..:) ), seem to show a well formed pitch, BUT his X was goign too far in , I suspect a separate issue there, and he's going to retest
now that we found a rad/dia issue. It seems the G0 move that preps before the thread is losing steps, so we're checking to see if thats systemic, or just on his machine.
Ill post some pics of the resultant threads when I get them. Heres a post of two threads, one EMC (correct), and one Mach3 (incorrect) , but the mach3 thread is too deep, ( rad/dia issue or something)
but you can see the pitch looks pretty good other than being too deep.. I suspect we're getting close.
Thx
Art
-
ART,
Here are some tests.
Single spindle index was used and a function generator was used to emulate timing impulse signals.
This test: SPINDLE RPM @ 100RPM
100 SLOT TIMING INDEX ( actual timing pulse was 166.44 HZ )
( 100 RPM=1.666HZ SO 166.44 / 1.666= 99.9 SLOTS )
RICH
-
ART,
Here are some more tests same as before with more timing pulses.
Single spindle index was used and a function generator was used to emulate timing impulse signals.
This test: SPINDLE RPM @ 100RPM
400 SLOT TIMING INDEX ( actual timing pulse was 667.9 HZ )
Both test were done on a Dell Optiplex GX520 3gig hz computer using the motherboard PP.
Note that the interupt time changed some when taking the screen shots and they were actualy lower like about
35 us or so range before the screen captures.
When i get a chance will try the Nec laptop that i also use.
Do what anything in particular run / slots combinations?
RICH
-
Hi Rich:
Looks pretty good and stable. Thx for the tests, I think only the actual threading tests over time will tell us how it all works..
Thx
Art
-
Hi, Art
Hears a 2 inch long 1/2 X 20 thread picture, It's done on my Comp 5 lathe, Using Printer Port, 100 slot Timing and 1 slot Index.
The nut I tested with is a MIL Spec. MS aircraft quality castle style nut .570 long and it will run the full length without binding.
Chuck end is on left, Looking from right to left, First .500 thou of thread is real nice then it start's to lose thread profile width. The root of the thread seems to widen/wonder which reduces the thread profile, Peak's diminish and the nut will wobble.
I think the Z feed is slowing a little to much or over correcting some.
Chip
-
Hi Chip:
I see what you mean.. doesnt look too bad though, other than the wandering... Ill give it some thought..
ARt
-
I have just started to use Mach 3 lathe . When I try the threading program it runs but stops at at a line with G76 X0.4 Z-2 Q2 P0.05 J0.006 L0 H0.005 I29 C0.025 B0.0001 T0. I understand that this is a fine boring canned cycle not supported by Mach3 .has anyone else had this problem? and what is the fi?.
mehcjose.
-
G76 is a threading cycle not a fine boring cycle and it is supported by Mach.
If you machine stops at that point is there a message in the ticker window?
Do you have spindle feedback to Mach?
Hood
-
Hi . Hood
I think my spindle feedback may be faulty . am checking.
I did not find G76 in the Mach3 G code list so assumed it was not supported.
mechcjose.
-
G76 should be in the Mach Turn manual, it certainly used to be anyway.
Hood
-
HI ALL,
I know there were problems with the lead changing when threading. Take a look at this thread as i just did some thread testing on the converted lathe.
http://www.machsupport.com/forum/index.php/topic,12484.msg82874.html#msg82874
The lead error and heavier cut ( somewhere during the cycle ) still exist as I have shown.
I know it is not mechanical.
Any thoughts on the matter?
RICH
BTW.........1/2 a good thread is better than none! ;D
-
Rich,
Seems to me the solution is an encoder on the spindle motor and a servo drive. An encoder can be put on just about anything.
The servo drive automatically does all of the stuff MACH is thus far been unsuccessful doing, i.e. compensatng for the motor slow down under load.
I can cut any thread with my 4th axis including tapered NPT and re-cut the same thread over and over with perfect registration.
This scheme would also allow a drill, small milling head or engraving spindle to be mounted on the cross slide for additional machining capabilities.
What would really be slick would be to take an X2 head and column and mount it on a slide behind the lathe. Bada-bing! Mini-Machining center II !
Downside, of course, is cost.
-
It would be interesting to find out where the problem lies, from the way I see things it has to be something to do with either index pulse type or computer or VFD control. Reason I say that is I have never had an issue with threading and I previously put this down to my spindle motor having no chance of slowing down during the cut, but now seems Rich has plenty power so that doesn't seem to be it.
I now have a big servo on the spindle and use the Index pulse from the encoder through the SmoothStepper, however previous to that I had an induction motor (through gearbox for speed change) and an Opto (OPB 916B)for the index pulse and used the Parallel Port. As said previously I never had an issue in either of these setups.
That seems to leave the index input (type) or the computer itself as the culprits, the other thing that it may be is VFD control. I am not sure if Rich is using a VFD on his new lathe or not?
Hood
-
Not using a VFD, but have a 1 hp DC motor and VFD drive for it. Figured I would just use the AC motor and see how all worked and maybe later try out VFD. Not sure on the motor though since i have no info on it.
Can change the Z over to a servo and replace the gecko dirve. My controller ( four drives in it ) is set up and used for multiple machines as it is portable along with the computer and sits on a cart. Thus that option would be a pain and really don't care to do it.
I can say that compared to other testing from the Sherline that the lead relative to length was improved some.
I also narrow it down to the index and computer. If the machanical spindle rpm is solid ( i wathced it during regular cutting and took measurements ) and it stayed within 1 rpm / the accuracy of my indicator consistently.
I know Graig can slave an encoder to the Z axis and provide for slowdown in one direction of a stepper. I was more interested at that time for both directions.
Agree that an encoder would be the ticket. We have used one for threading using DeskCNC. In fact you can turn the motor off and turn the system by hand, even go back and forth on a very small thread and it would just track whatever the encoder movement was doing. Maybe i will try and contact Graig again.
The thread testing back some months ago never came to closure. Art seemed to think it could be computer, but those tests were strickly for the PP.
One thing for sure is that the problem is not going away, it's a tuff one, and a lot of users will experience it.
RICH
-
I havent been having any problem the past few months with either of mine, one with a 2 hp spindle motor and the other with a 30hp . The 30 hp machine uses smooth stepper and the 2hp does not. Both use VFD and a single pulse optical setup . I have cut somewhere over 2k threads on each machine, most 1"x 20 tpi with no problems
-
Certainly looks like VFD can be taken out of the equation then :)
So anyone using a PP, what is the pulse frequency on the Diagnostics page sitting at? I seem to remember when mine was using the PP it was very close to the set kernel and I don't think it varied at all day in day out, wonder if that could be a clue?
Even though I don't have an issue and have never had, it would still be great to see this get a resolution.
Hood
-
Hood,
Mine has never been rock solid and varies. This is true for four different computers i have tried.
You can have a good consistant index input, but, as you elude too, if Mach has a bum
input for controlling the steps then you can end up with the lead problem and even when
the the start of the threading cycle should start.
I'm thinking and that is dangerous. ;)
RICH
-
Hi Guys:
The threading is being re-investigated as of this coming week or two. John S has agreed to run some tests for me to see where the wander is at. We're goign to start with the
Printer port single pulse threading, then evaluate the multislot again to document the differences. The wander is caused by a varying of the time the computer see's the index time.
It seems on some computers there is an inherent delay and this causes an overcorrrection that creates a wandering Z position. On other computers it seems not to exist. I still
dont know though if its the computer or the machien causing the variance. The multislot gives me statistics to see how much variance. When I feed it a time based generated pulse
I see no variance here, but using my Emco lathe, I see the index pulse varying in time.
This means either my motor is varying in speed slightly, ( though I cant see or hear it..) or the sensor itself just isnt that solid in terms of when it activates. More test results should be
coing out soon.
In current versions the driver was modified to a new timing base, which is more solid. My #interrupts display has since read withing a close number of selected kernal speed. 25005 for 25Khz for example, and very solid. I suspect those with further away numbers, and more variance see worse threads. Perhaps future tests will tell us which it is.
Art
-
That is interesting, I can't look at the lathes pulse frequency as it doesn't have a PP on the pico mobo but just looked at the mill when I started it with an old PP profile and the pulse frequency is rock solid. Have also looked at the desktop machine I am typing with and again it is rock steady. Not sure if you actually see it varying in real time though? Have certainly restarted Mach a few times on each and its always exactly the same.
Hood
Edit
This reply was in response to Rich's last post, Art has since come in, was on the phone while typing so was a bit slow, thats my excuse anyway ;D
-
Art,
I assume that the variance will carry over to the SS. Is that true?
During the driver test for my pc i get 22000 for 25KhZ and it varies by 200.
RICH
-
Rich, do you see that varying in real time on the diagnostics page?
Hood
-
Rich:
No, variance doesnt carry to the SS, it has a fixed period cycle that wont ( or shouldnt ) vary. Your computer shows a sign of instability with a low reading of 22000 and a 200 variance. What does the drivertest show? A stright line? or is it more of a sawtooth?
Its my suspicion that the variance can be caused by the cpu being less than perfect in when it triggers the interrupts.
Art
-
Hood,
Thanks,
The TURN DIAGNOSTICS dosen't work for the SS.
I can turn off the drives and check it out as if i was using the PP and get some info and then will repost
shortly.
RICH
-
Art,
The dirver test shows a straight line, a small spike every now and then.
RICH
-
here is a screen shot of the driver test
RICH
-
Perhaps I am missing something, but I see no way that any software can compensate for spindle speed using a single index pulse per rev. It is a physical impossibility no matter how fast the computer or the software is. These are the inescapable conditions that immediately occur to me;
1) No matter how many pulses per rev, the data is always after-the-fact, in other words, for a slowdown to be detected, it must have ALREADY occurred, so it is too late to compensate for deviations between the detection read and the previous read. Unless the delta in time and error is very tiny, AND the mechanical system response is extremely fast, then a correction, (which can only be done as a 'catch-up' unless some type of prediction is made), really looks to me to be undoable.
2) If the spindle motor slows down significantly, then it is a given that the drive motor has insufficient torque to maintain RPM. It would be illogical to presume that the already overloaded motor would have any available excess torque capacity to catch up with the now over advanced threading feed, so the only alternative would be to slow down the feed, which in turn would change the load on the motor since this action would change the effective depth of cut from the last pass in that portion of the thread where the correction is made.
I do not know how MACH attempts to keep the threading synchronized, but it seems to me that it is irrelevant because if my thinking it correct, there are not adequate data for one method and inadequate power in the other.
It occurs to me that only a very high number of samples per rev would have any chance of maintaining sync and then *perhaps* only if MACH had data on how many amps the motor is drawing during the cut.
The fact that people with very high power spindles (relative to the size thread being cut) have no problems tends to support my conclusion, but again, I may have missed something.
-
Rich I was actually meaning Machs Diagnostic screen but thinking about it the Turn screen may not show the pulse frequency. I use my own screen and its based on the Mill screen I made so it has the pulse frequency showing. Would be interesting to see if it alters in realtime as mine doesnt.
Out of curiosity, what make CPUs do you use, all mine are AMD, just wondering if it could be as simple as the difference in the way AMD and Intel do things?
Hood
-
Rich,
Just a comment on your driver test result. The period of time that your pulse goes slow seems massive. I have never had any more than the width of perhaps a single pixel above or below that line, even at 100k.
It would be interesting to calculate the number of pulses effected during the duration of the disturbance
-
Hood,
It's an Intel P4 and all the the others are Intel's also.
I need to look at Threading Diagnostics and compare some data it gives. Was interesting to find that the PP wont read the 53 rpm while the SS would.
I noticed that the variance in the Mega clock rpms varied as the rpm went up, which relates to the locked RPM.
HMM......... the scribed lines i did were at 402 RPM while the actual threading ws done at 115 RPM, but fewer passes .....so if the variance is smaller at the lower rpms i wonder how the scribed lines would turn out at the lower rpms.
RICH
-
Simpson,
One of things that Art did was to provide for spindle slowdown and a lot of time was spent for the hobbiest.
A lot of those punny lathes ( i got one ) will have problems when trying to do anything over say a 40 or 32 thread.
You get spindle slowdown, and at say 24 TPI, it may be some 10% or more, yet the program adjusts , and you can accomplish the thread. I have even stopped the spindle for a second and recovered the threading cycle.
I have cut 1/2-13 in a steel rod with that punny lathe,but , you really need to experiment.
It does work! Trust me i have spent a lot of hours testing it. Just need to keep things in perspective though.
RICH
BTW,I agree with you on that if you have adequate torque / HP ( not only the spindle but the axis system also ), accuracy and repeatability, to begin with ,then there will be threading success. There is a whole community of users that don't have that. That's why i did the lathe conversion. But it is more complex than just the machine part. Computers can just suck at times. ;)
-
Simpson,
"It would be interesting to calculate the number of pulses effected during the duration of the disturbance"
Yep, same goes for the variance in pulses per second, but may not be as simple or relative as you would first think.
RICH
-
Simpson:
Your right..and your wrong. :)
During a period of rotation, there may be as many as say 5000 interrupt periods.. Mach3 is measuring how many interrupt periods occur, or used to. It now measures how many megaclocks occur, at a base rate of about 2Ghz say..
So for each rotation we measue the megaclocks..this is before we actually cut. Now lets say we get 24,000,000 as a steady rate prior to cut. We simply divide to show the rpm..
Now we start the movement, since we're in mm/rev mode, we know the mm's of motion were calculated based on 24,000,000 clock cycles per rotation. If the ortation is sensed to be now 2700,000 clocks per rotation, we know the spindle has slowed by 12.5% .. so we now slow the output during the next rotation by 12.5%, and keep track of this rotation.
SO your right that the correction is always 1 rotation behind in terms of correction, but it can be shown statistically that if one rotation is off, the next rotation will be off the same amount +- a certain %, it may for example keep slowing down.. in which case each rotations motion in the Z axis is further slowed. As a rolling % of correction we begin to approiach the center of the bell curve of probablities of where the spindle is likely at.
Its a fairly good method of correction, and works well as long as the megaclock is stable ( is always is unlike the number of interrupts per rotation which varied much more ) and the sensor is stable..mine isnt and Ive seen many that werent. At any rate, its pretty good to about 10-15% variance on most systems but other influences can throw off the statistics and make the thread wander higher and higher over time. This is why the wandering thread pitch as you go further out. Mach3 cannot speed up from original speed, but can easily slow and speed back up to normal speed. Testign shows this works but we're simply trying to make it better.
The system knows that after so many rotations, we shoudl be in such and such a position and simply tries to get there bassed on the number of ratoations seen, current position, and speed.
There will always be a limitation based on the fact we arent real-time though.
Art
-
I'll address this to Art and Rich both as combining the info implies that the effort is aimed, at least somewhat, at marginally powered hobby lathes. Correct me if that is not the case.
Thank you, ART for the explanation of the function. This is quite a fascinating topic. I see that the new method for measuring is more accurate perhaps, and even if the 'bell curve' could be considered a prediction of sorts, the problem remains that it is after the fact and only once per revolution. And there are additional factors conspiring against the perfect thread.
Measuring the period of a full revolution injects another assumption into the equation. Not only must you assume that slowdown will be statistically similar for the next revolution, with only one pulse per rev, you also must assume that the slowdown is consistent over the entire revolution. I think that is unlikely, especially if the tool entry azimuth does not coincide closely with the pulse azimuth.
For example, if the tool enters at 180 degrees relative to the pulse, your measured revolution will 'see' only half of the slowdown, and therefor misadjust by 50% the needed correction for the next full revolution, and will consider the increase in the subsequent time period as a further slowdown and misadjust again, followed by another change in period, and so on . . . . . if I am thinking correctly. Additionally, it is my impression that forum members here (as well as the available wizards, perhaps?) do single point by a simple plunge with equal depth of cut for each pass. If that is correct, then each pass will require more power and there will be a corresponding increase in the slowdown from pass to pass. This presents a vexing problem that there is no solution for so long as a single pulse per rev is used.
This brings up an interesting question of harmonics . . if you will. It is possible that the 'oscillation' in speed correction described above could be self exciting? That would explain the escalation of the error as the thread becomes longer . . as has been described here and there. I have not followed this closely so I'm shooting from the hip here. :P I have not thought this through at all . . just a mad thought.
-
Threading solutions for the 'stab-in-the-dark' department:
Here are just some thoughts that occurred to me in noodling over the MACH single point threading challenge. These ideas may or may not improve success, (my dime says they will), but they cannot do any harm and are free to try. Hopefully they will prove useful:
1) arrange for the tool entry point to be as close the the index pulse as possible.
2) use a more sophisticated threading technique that will even out the load from one pass to the next.
Alter the G-code to cut only one side of the thread and reduce the feed (or depth of cut if messing with feed confuses the adjustment algorithm) such that as successive cuts take more 'height' of the the thread, a corresponding reduction in depth or feed equalized (within reason) the power required for the cut.
3) use a motor speed controller based on PWM rather that SRC and use one that has good compensation for slowdown. I am using a Minarik drive which has an adjustment for that and does a very good job trying to maintain set speed. Certainly there are others that also work well.
If MACH has less total change and less delta throughout the cut, then as the function was described to me, it *should* be able to zero in on an optimal correction sooner and maintain the correction thru successive passes.
-
Simpson:
I do believe the oscillations of the vfd autocorrections have an effect. But its all more accurate than youd think. Firstly, I keep a rather large
64 bit counter of the actual times involved and keep track of remainders.. While errors can be created by entering the material offset from the actual index pulse, those errors
self correct from rotation to rotation. The way the math works it keeps in in as good a track as possible, but the vfd can negate some of the safety there. I suspect its better
not to have a correcting vfd personally.
Consider a 5 rotation thread, with some fake numbers..
We have planned the motion and filled the output buffer with 1mm ( 2000 steps) per rotation. We start with the trigger.
Unit triggers on index, motion begins...Counters are zero'ed.. static measurement of one spindle rotation of say 26000000 nanoseconds per rotation is now locked in as base. This
is being measured all the time as the unit waits for the index trigger prior to threading..
So motion begins and we wait for next index.
Index hits.
When index pulse hits, we look to the number of nanoseconds passed. Say its 28000000 nanoseconds.
We now subtract 26000000 from the counter, leaving 2000000. We now slow the motion by 7.6% over the next
rotation, but its done by a bresenham division algorithm that keeps track of the remainders, so that each rotation can help
correct for overcorrection on a previous rotation. Each rotation is linked that way to the entire thread. Think of it this way..
I--------I--------I--------I-------I
Before the thread is even started, Mach3 knows that a certain number of total pulses should have come out by the time each "I"
in the above line is encountered, ( "I" being an index pulse). By counting the pulses and the position of the index pulses
we can calucate exactly how many steps short we are ( or over ) at each index pulse. The correction therefore is not based on the last rotation, but on the total number of rotations and the total number of pulses that should have gone out. SO while one rotation may
contain an erronous slowdown due to tool entry etc.. the actual correction on the next rotation will take that into account
as a sum total of the entire thread. The numbers will then always be pretty correctable UNLESS the spindle speeds up in its correction
to make it impossible for mach3 to catch up, as it cannot speed up anymore than the planned speed of 1mm per rotation.
In theory, this is of a high enough order of correction that added corectional steps would have little influence. The trick is
not to look at each rotation time as the correction for the next rotation, but for each rotation time to add to the whole
and be used to correct for position that far into tthe thread it has reached. Keeping track of raminders allows this to be very robust.
Ill be testing over the next few weeks and will update the dialogs to show expected vs real poition and the correction applied as a result.
Thx
Art
-
Hi All,
Took a look at the Turn Diagnostics for 402 and 115 rpm.
I just did a dry run of the threading code at the 60 passes for scribing of the tube at both rpms.
There was a definite difference between the 115 and 432 rpm info:
During the higher rpm the Highest % variation during threading changed four times up to a high ending value of 18.4% while the low rpm only varied by up to an ending value of 1.37%. Additionaly, the Mega Clock variation was greater for the higher rpm. Rotation real time rpm increased by 5 rpm for the higher and only 0.5 for the lower rpm. So there is a difference on what's happening with index pulse and also how the threading cycle is applying correction based on that info.
Now what is also interesting is that the % variation during threading was somewhat stepped for the 402 rpm, such that the first step change went from 10 to 18% after 15 passes, and gradualy creeped to the final 18.4% , which would kind of confirm what was observed when doing the actual scribing,.... at some point during the threading cycle there is a definite change in the Z axis movement.
So as posted before, that the 3/4-13 actualy cut at 115 rpm had no lead problems while the scribed one at the 402 rpm did, this may just provide the explaination as to why.
The difference of when the five scribed lines "ended" is about 10 degrees from each other.
If i did the math correctly, that's o.oo3" of Z travel and that is quite close to what you can measure in the picture.
So i guess it's time to try a scribed line at the lower rpm and see if what i am thinking is just rubish
or not. Or i'm reading to much and incorrectly into the diagnostics info.
RICH
-
Rich:
I suspect your on to it. The problem in my mind may be that if a sensor varies.. its variance is pretty much set, lets say its a uSecond early on one pass, maybe 1us late on another.If the rpm is lower, that constant variance will be less as a % of the total time used. Your example was a 4 time differential between the two periods.. At 115rpm the 1us variance may be 5% of the total, but at 405 it may now reflect 20% of the total timing.. accuracy would fall as the constant lagging or leading variance would slowly make it go out of known position.
Now it may not be the sensor.. it may be the printer port interrupting a bit late at times.. same effect..
I do know that if I feed a signal in my printer port from a frequency generator, its dead on and very repeatable, but when my spindle sensor is measured, its floating about 3us either way at times..
(I think its 3us.. its been a few weeks.)
Art
-
RICH,
Just a thought. Do you think that a photo sensor with a Schmidtt Trigger would be more stable than a magnet and Hall sensor ?
Just wondering,
Russ
-
Russ,
I looked at the sensor signal and it's has a nice crisp on-off / high low of same duration and no ringing to it. My o'scope is not the best in the world and it does seem like the signal is floating some, it should be stable such that it triggers and appears on the scope in the exact same spot, but again i don't trust my scope.
The Schmidtt trigger is good because you can refine / deal with the hysteresis ( however you spell that). So i won't discount using it.
Art,
I tend to agree with you and it may be a combination of both the sensor a little out of time and the computer. There are four of us here that have the same problem. Now it's difficult to put it all into perspective since every system has their owne quirks which could play into the threading problem
differently.So i will stay with my system since the mechanical end is known not to be an issue.
I think i can get my friend to lend me his computer to try as it has a very stable pps in the driver test.
One common problem observed is that somewhere during the passes the Z makes a deeper cut.
Say at pass 10 out of 30 passes. I am thinking that it's when the % variance is accounted for.
I don't have a signal generator that i can use for a pulse. The one i borrowed had the range but can't vary the width of the pulse.
Would it be of any value to add to the Turn diagnostics the pass at which the change in % variance occurs or is implemented?
I will post shortly with a picture and more info since i have tried another scribing cut.
Thanks for the commnets,
RICH
-
Rich:
Each pass is its own entity, there is no difference from pass to pass. Correction occurs only during a pass, all knowledge is lost after the pass,
so if it cuts deeper overall, then it has to be the X depth or its fooling you because its cutting inot a crest making you think its deeper than it should be.
But there is only correction during a pass, and it knows nothing of previous passes..
Art
-
Here's another scribing test.
Attached are two pictures of a threading scribe test which was done at 115rpm and 60
( 0.0001" deep passes ). I used a 30 degree angle so it was radialy cutting thus no Z offsets in the Gcode. Picture 1 shows finished scribing and there was a definite improvement. Picture 2 shows
the end of the passes and the total width of all the cuts was cut in half as compared to the same at
402 rpm and there are five distinct cuts.
Now i watched each cut under the microscope since i can see the actual tip point and what material is being removed. For the first 20 passes it tracked the first pass. Then there was a slight shift at pass # 30 about 0.002" increasing the lead. Then at pass #46 the cuts started oscillating, such the one would be on the first pass line, then maybe the middle of the width, and finaly further down the lead. Pass #53 opened up the width some 1 or 2 thou ( lead increase ) and then pass #54 opened the width up around 1 thou ( lead decrease ). Passes after that kind of tracked the middle of the of all the passes.
So it seems that the sensor is not constantly stable, maybe.......since that's what the o'scope's telling me, but i don't trust it. But then it could be the PC or combination of both.
If anything, i can say it dosen't take much to screw up a thread.
And for those following this, when you post and ask a threading question, and maybe you get so many different thoughts on the matter, some generalized comment, now you know there may not be a simple answer to a system of mechanical, electrical and software all trying to work in harmony!
RICH
-
Thanks Art,
Depth is not even a concern for me, it's the lead / longer threading, as shown by what i just posted.
The x axis is very accurate in it's moves and the Z is almost neglagible.
I am going to guess that i can cut threads out to about 3/4" to 1" all day long and they will be good.
Hope i don't seem anal about the threading. For what i do this lathe will be fantastic.
So over time i will try a different PC and have a friend look at the sensor triggering / timing since he has
the equipment to do it and is extremely knowledgable.
What fooled me was the distinct cuts, and you got to watch each and ever one of them to get the story as i just
posted.
By the way, a good test of the sensor triggering would be to do multiple start threads.
Another would be to pick the thread up and recut it ( it's somewhat of a bitch to do in CNC). I posted something in members docs on how pick the thread up.
I guess the thought here is to eliminate the problem such that no correction will be required. Maybe wishfull thinking with the computer and sensor currently in use, but, wouldn't know unless some testing was done.
As always appreciate the comments,
RICH
-
Rich:
Excellent testing!!
I agree with your comments. Though I suspect a nut would screw on even to the end of the thread.
Interesting that it happens at certain passes, that seems to indicate the sensor blipped a bit late or early in the trigger.
After triggering the thread, if the sensor did blip late a bit it probably wouldnt matter as it self corects during the pass, so
I suspect what we're seeing is that the sensor sometimes delays a bit ( or the computer does somehow ), and the problem
occurs when iut does it during the initial trigger of the thread.
I have to note that of all tests on threading performed to date, yours are the most scientific, and the best documented.
Interesting that 20 passes were good, then the problem occured and toggled about between various pass points. It does seem as if
our collective problem is the timing of the initial start at times, not so much the correction during the pass. Of course you likely have very little
slowdown if any so the nice passes reflect a steady output from initial start point.
Ill dwell on it a bit..
Art
-
Art,
If the test's and documentation provide info such that you can improve the threading or others have a way to analyze what is wrong with their system, then it was worth the time and effort.
RICH
-
Art,
Here is some more testing and a little more interesting information.
I was able to borrow a different computer. The driver test for that computer showed a dead
straight line, no blips at all, and the PPS only varied by a count of 2. That computer was used on test
sample #3 & #4 shown in picture #1.The testing with that computer was with the PP and the threading diagnostics showed the following:
CPU Interupt varability: 0 or .01%
Highest Variation during threading: 0.51%
Rpm Variation: .01 to .07
So I consider this pc about as good as your going to get.
All the thread scribing for the 4 tests was done at 115 rpm, 60 / 0.0001” passes with 30 degree ( no Z axis changes in the Gcode ).
Picture comments:
Picture #1: #1 & #2 were done with my pc and #3 & #4 were done with the borrowed pc.
Picture #2: This picture shows the improvement in the threading with a more stable pc.
Picture #3: Enlarged picture of test #4
Picture #4: This shows the cutting mark both at the beginning and end of a 2” long thread
for test #4. Note that it also is representative of test #3. There is only one SINGLE
cut line and it is consistent from start to finish of the thread in width and depth by actual
measurement. ( the magnification on the pictures were different ).
COMMENTS:
So the stable pc did improve the varying cutting position as you suspected ( single verses multiple cut
lines in #1 & #2). I watched every pass, and there was no oscillating back and forth between the passes for #2 & #3 as compared to #1 & #2 test with my pc. That tells me the sensor is doing it’s job of triggering consistently.
Now you would think life is good. NOT SO.
The lead is increasing on each of the threads and the increase is the same root to root of adjoining cuts.
TEST# PC TOTAL LEAD ERROR LEAD ERROR IN 1”
-------- ---- ------------------------------- -------------------------
2 MINE 0.018” / 2” 0.009”
3 BORROWED 0.016” / 2” 0.008”
4 BORROWED 0.013” / 1.8” 0.007”
( btw, The max lead error of a ground tap is 0.0005” in 1”. )
What is causes the increasing lead error?
It’s not the mechanics of the lathe. I re-checked the triggering, and my Z axis moves. This was done as follows: I did individual G32 –Z2.0 F.050 moves 50 times and the axis stopped each time within the Z backlash. So, that tells me that the triggering is quite accurate since it if the triggering varied much the end stopping point of the axis would be off. The stopping point was confirmed using optical equipment.
Next, I put test piece #4 in the chuck,…. picked up the thread 10 times ….. a little differently than what I posted some time ago because I am using Hall sensor, did G32 –Z ( starting at -1 and increasing the move in .1 increments out to Z-2.0” ) F0.50. The sharp tool point was very close but not actually touching the test piece. This allowed me to check them z axis movement against the scribed test piece along with a guess of where the trigger actually occurs. I could measure the difference between the test piece and the z axis move. And it consistently showed the Z axis move had no error in the distance and I could also check against the know lead error of the test piece. The measured difference was very close each time.
So it seems like the threading cycle is introducing a lead error from what I can tell.
Would it be possible to have an option in the threading cycle to “turn off the compensation during the threading” or maybe be able to put a value into it to adjust a know lead error? Just a thought!
RICH
-
Rich:
I truly love your testing..
OK, so you seem to have proven the effect a computer thats less than perfectly stable will have in terms of creating a variance on the thread.
And youve proven that when perfect ( or as near as Ive seen ) the computer will produce a slight Z variance in terms of an increasing pitch.
( I take it the pitch always increases..never decreases? )..
So now what..
Lets crunch that a little bit...
The lead error ( if always advancing ) would seem to indicate the Z is moving FASTER than perfect speed at a rate of .009 over an inch,
so thats exactly .9% too fast for a Z motion. Thats a very interesting result. Since MAch3 cannot speed up the planned motion for correction, but can only slow it down, it would indicate that the planning is off in speed by .9%.
So the system is planning for steps at 25000 per second. ( Actually, it uses the counted pulses per second, so that may be 25002 on yours for example) anyway.. at 115RPM, thats 1.91666 revs per second. So one rev is .52173 seconds per rev. And the lead must be off .009/.0172" per second. So that seems to indicate the speed of the Z is too fast by .01725 inches per second, or 1.035 inches per minute.
Im thinking thats the issue.
Now Mach3 is seeing the 115RPM call for threading, setting a feed speed of ( pitch/spindle speed),
and telling the planner to output pulses with a corrected time base of ( yourCPU'sPPS / kernalspeed). It does this
assuming that this is the perfect non-corrected thread motion once triggered for one pass of the thread. Since the
driver cannot speed up the motion, but can only slow it down, the advancing pitch of your tests woudl seem to show that
the real problem is in the perperation steps, not the corrective one. To have pitch advance would seem to remove the
driver from the equation because its outputting too fast for the thread.
Now I have to say that a .9% lead error is not something I consider very high in terms of what we're doign in single
point threading.. Id suspect a nut would screw on from start to any length since the error remains the same over the length of the
nut. But having said that, it'd be very interesting if we could eliminate that error, then take on the correction to see if we can
do something similar there to make it more efficient if indeed it does have any trouble at that end.
( this letter is over an hour long in typing as I check code.. :) )
So it all boils down to one thing I guess for the tests youve done.
The motion is moving too fast ( advancing lead ) from start to end, and this seems consistant. To me this can only mean
the spindle speed is not being read correctly in terms of computed number, or the speed of the planner is not properly
being compensated by the difference in your CPU's read kernal speed vs commanded speed.
Now we know the faster the spindle speed the worse the error is. That may be some other effect, so maybe we should ignore that
for now. Lets just consider speed as the problem, only two factors can really affect it.. spindle speed calculation and kernal frequency.
Can you note the kernal frequency your getting on the diags page, if its very close we can eliminate that I think.. unless if 225 off, in which case thats the .9%..?
Do you have any way of telling externally what the real spindle RPM is when you have a reading on the screen?
If you select a higher pitch..say .5 , is the lead error still the same amount or does it scale with the pitch selected?
Ill attach here a new Mach3 executable called MachThread.exe , I need to know what code we're in for testing, this is .028 but my version of it so I can track any further tests we do. If we do indeed solve the issue, Ill send Brian a full update for release in the next version and update of current version. Ill also make up a new driver with a selection for no correction.
Thx
Art
-
Art,
I need to digest what you posted.
I am using rev .027 and will update to version .028.
I need to do a few things ( paper boy decided to put the f'n paper through the front window >:( , so first things first ).
I fixed my pc problem, new pc put together and it is solid! So need to play some, but this pc is showing only 1 or 2
change in the driver test and is as good as the one i borrowed. So this gives us a comparison with another solid pc.
The lead is always increasing for the thread test recently done.
Can you note the kernal frequency your getting on the diags page, if its very close we can eliminate that I think.. unless if 225 off, in which case thats the .9%..?
ANS: My screen ( lathe screen ) dosn't show the kernal speed. I think chip modified a mill screen to show it some time ago and will try and find it. If you have a screen with it on it post it and will use it.
Do you have any way of telling externally what the real spindle RPM is when you have a reading on the screen?
ANS:Yes, I am using a Hasler Speed Indicator which reads to within 1 or 2 rpm and is quite consistant. I always let the spindle run a while and then try check the rpm before, during, and after a test if i can . That's the best i can do.
If you select a higher pitch..say .5 , is the lead error still the same amount or does it scale with the pitch selected?
ANS: I haven't done enough testing to really say. I'll think about the pitch selection and range and see what i can come with like .025, .050, .1 as they are easy to measure on the toolmakers microscope. I am trying to stay at one selected rpm, minmizing axis influences.
As far as the screw and nut, yep the nut will go on. But it depends on the nut length. I know i can tap a piece
and then do a thread on the manual lathe with a min of backlash and it will track the thread very accurately. So say you have a nut 3/4" long and a fine thread, the nut would bind. Sort of like putting a metric nut onto an imperial thread. But let's not divert away from the testing.
Later,
RICH
-
Hello all:
I have read the entire thread this afternoon, and marvel at the efforts to solve this problem. The electronic/technical skills of all involved is certainly high, and a great deal of work has been put forth by all.
However, this problem appears to be escalating to higher and higher levels of complexity, with computer clock microsecond timing and motor speed variables shifting about seemingly at random. I wholly agree with the post's of Simpson36. Perhaps it is time to rethink the problem, i.e. think "simple."
Engine lathes have been cutting threads for a long, long time, and the problem of synchronizing the spindle/carriage is done with a precision lead screw, geared to the spindle, which moves the carriage by means of a bronze half-nut, engaged at the appropriate time as indicated by a carriage dial geared to the lead screw. The machinist was the computer, watching the carriage dial to engage the half-nut at the exact moment, to synchronize spindle and threading tool exactly, after selecting the gearbox change gears for the thread pitch.
The spindle index-pulse signal has now replaced carriage dial and half-nut, and the machinist's eye. The lead screw is geared to the carriage motor and motor encoder. But, the old school gear train between spindle and lead screw is gone; replaced by microsecond time clocking counters, motor speed and torque guesstimates, number averaging, and much more things that this writer does not understand at all. However, it does seem akin to the old-school gearing system, except rubber bands are used where gears and keyways used to be! And, it is not simple.
May I suggest using an encoder on the spindle, with the index-pulse retained of course. The spindle encoder signals become the baseline source of all timing for carriage motor drive synchronization. These spindle encoder signals become an electronic gearbox, if linked correctly with the carriage drive encoder counts. Spindle speed can vary all over the place, as well as the Computer frequency clock ticks, and will in no way affect the "electric gearbox" ratio between spindle and carriage.
Example 1:
500 count/rev encoder on spindle, carriage encoder .0001" linear travel per encoder pulse (2000 count/revolution , .1/5 inch pitch leadscrew)
Cutting a 1/4-20 thread, the pitch is .05" per 500 pulses per revolution of spindle. .05 linear travel = 500 linear motor pulses, per 500 pulses from spindle encoder.
Example 2:
Cutting a 1/2-13 thread, the pitch is .076923077" linear travel. This = 769.23077 pulses per 500 spindle pulses per one spindle rotation. It would take 4 revolutions, or 4 full pitches before a full .0001 pulse step had to be added, if the ratio was 500/769.
With a 500 count spindle encoder, at 600 RPM, the pulses per second are only 5000 pulses per second. If I read the thread correctly, the number of 25,000 PPS is the clock speed of Mach3. I seriously doubt anyone is going to want to do threading over 1200 RPM, and the coarser the thread, the lower the spindle speed becomes. If the spindle speed must be high, i.e. fine pitch, small diameter, the Mach threading program should be able to post an upper limit spindle speed for a given thread pitch.
I am sure there are elegant, mathematical routines to synchronize the lathe spindle and carriage, for any thread pitch. Machining threads to a known standard of precision is fundamental, in the machine industry.
Regards,
John
-
Art,
I am back to using ver .027. If there is a problem that with using that version let me know. Ver .028 was a mess. Four installs and a few hours of agrivation and back i went! It just would not send a signal out the PP. Couldn't run the machine! I think it didn't like the address of the PP and few other things.
John,
Yes, slaving the spindle to Z would be nice if possible in Mach and have used it that way with another program. Maybe the SS will provide for it some day.
RICH
-
Chestermarine
500 line encoder at 600 rpm would be 20,000 per second. also threading above 600 rpm is a daily occurrence for most people that use carbide, most of my threading is in excess of 1,000rpm.
Hood
-
Hi John:
Your right of course, slaving to an encoder woudl give perfect threads. The problem is that Mach3 uses Windows in a semi-real-time environment.
While I managed to make Windows run in real-time, I cant do division in the driver. There is no easy way to do a geared slaving. I do have already
a encoder type of threading driver. We use a 100 slot wheel with a separate index pulse. BUT, its still a game of timing and uSecond timing, though the
statistical revelance of the numbers are higher.
I cant fully explain techincally why we have to deal with it the way we do, but its a result of the technical challenges faced when trying to make Windows
run in a real-time mode. Take an encoder for example, if it runs at 600rpm and has 100 slots per wheel, thats 1000 inputs per second, and the kernal typically
only runs at 25000 , so it leaves only 25 intervals between slots to do corrective actioins, and without a proper floating point gearing, its very hard to arrange.
I worry about accelerative discontinuities and jerk from disturbing the waveform too much due to corrections. In the end it boild down to a rather easy solution in the
mind, if an output is planned at a certain spindle speed, we may have to put out 3 steps per encoder pulse for example.. but the triggering of this is very difficult and its
why the threading is triggered to go, then slowly adapted to changes.. its really all due to the lack of floating point in the driver. There are ways around that, and I
may in the end have to go there, but its far from simple, so all this testing is really about finding all the variables, and seeing exactly whats necessary as a result.
Rich:
Understood, sorry about that version, Im not sure why it wont put out for you, seems to work well here.. but Ill investigate to see if I messed up somewhere.
My entire thrust was to try to make it weasier on you, not harder, so drop that version till Im sure I can make it work better for you.
The problem with .027 is it doesnt have certain corrrections in it to allow me to do a simple driver change to switch the way things are done.
Art
-
ART,
I replaced the ver .027 of Mach.exec in the Mach directory with the file you posted ( Mach3threadOct2 ) from reply #460 and that works and the version now say's .028.
( The original installation of .028, had me really going nuts as i thought something was wrong with the new pc's PP or installation of it ).
So I assume all is good now. ;)
RICH
-
Rich:
Excellent. That will allow me to make some changes.
The tests youve been doing all use the original MAch3 threading code, with no real changes to the timers, they still use the number of interrupts
as thir trigger. Im looking at updateing that to PCI bus timing, which is in nanoseconds. Im thinking that way if the computer is less than stable, it wont matter
as only the actual time from index to index will count. It should make the rpm more accurate ..
Thx
Art
-
ART,
I am loading software onto the pc so won't be till later today for actaul tests.
Till then,
RICH
-
Rich:
Take your time.. no rush on this stuff at all..
Art
-
Art:
Thanks for explaining a little more about what goes on within the program, and the particular problems you are working at solving. I really appreciate, and value your feedback.
My first CNC machine goes back to 1980; teletype machines, and paper tape!
Like a complex machined part, the solution to the threading problem is breaking the job down to the individual pieces of the puzzle, and solving them one at a time.
Thank you, and those involved with you, for your work to make Mach a better tool for us all.
John
-
Hood:
1.) 20,000 per second? Check your math.
2.) My threading comment was a generalization, and I did refer to higher RPM's for smaller diameters.
3.) Are you spinning 2" shafts 1000 RPM when cutting a thread?
I think we all are interested in seeing this particular problem within Mach code, solved in the best possible way. Also, I appreciate this forum because of the vast pool of skilled people willing to help other people. My shop is 4-axis milling (2) machines, no CNC turning yet, and (2) engine lathes.
Still learning.
-
A 500 line encoder will be seen by Mach in quadrature so thats 2,000 pulses as far as Mach is concerned. 2,000 x 600 RPM IS 1,200,000 pulses per minute so divide by 60 seconds and you get 20,000 pulses per second.
Depends on material but I very rarely do as big a thread as 2inch but if I did then if mild steel I would be over 1000rpm, stainless probably about 600.
Hood
-
ART,
Here's some more testing data for you. I have attached pictures of the two test pieces along with
data for each.
The tests were done using my new pc.
Two pitches, namely .025 ( 40 tpi ) and .1 ( 10 tpi ) were done. The leads increase for both at
.0075"/inch.Now the prior tests with a borrowed pc were for .050 ( 20tpi ) and the lead error on those
was basicaly 0.009" / inch.I will do another test with mine at .050 but i think that you could say the
following: The lead error seems to be a constant 0.008" / inch increase.
These threads basicaly all had a single scribed lines.Test #2 ( the .1" pitch ) had two scibed lines
and my best quess is that it happened around the tenth pass or so based on the depth. The graphs
show per pass the led error for each thread root. So you can actualy see the changes between
groups of threads or revolutions. Additionaly there is a list of noted rpm variations from the threading
diagnostics and test#2 data it shows specifics during that threading pass #.
Look the info over and if you have any questions just post.
By the way, for days i have been checking my spindle rpm and it always tested 115 rpm, today 120
rpm ( and read with three different indicators ) . Not even going to mention why i think that is so,
and no, i didn't check the house voltage today. ;D
RICH
-
ART,
OOPS!
I did something realy stupid and caught it today. All of my recent post's which say that the lead is increasing is wrong. The LEAD IS .......DECREASING. The amount of lead decrease is 0.008" / inch.
I found and used Chip's Screen set, so now have kernal speed information.
I'll go back and modify my recent posts. The data is good, just again, it's decreasing.
RICH
-
Some time ago I read the thread in it's entirety. I have since followed it closely. It have been very interesting reading and I,m very impressed on the effort laid down by everybody in trying to get the threading to be as good as possible. I have thought a few times on saying something but have decided to keep shut as I probably not have had something useful to say.
The last post by RICH where he says the lead is decreasing is however particularly interesting. I have been thinking since some time ago on the fact that Mach can't speed up if that was necessary in order to catch up on an increasing spindle speed. The thought I have had is what if the spindle speed measurement done just prior to each pass is slightly slower than the actual spindle speed when threading occur. Then the pitch will be to large. I understand the spindle speed is measured in only one revolution prior to the threading on each pass. It places a huge demand on the exact measurement of the time between those two index pulses on that one revolution. When threading at say 500rpm, that is 3,000 degrees/second or 333 µs/degree. I have been thinking on what is the repeatability of the index trigger. An error of a couple hundred µs of the exact time of the trigger signal and the wrong way may cause a noticeably deviation of the pitch on long threads, especially at high rpm's.
I hope I remember the previous posts by ART correctly as what I have said now else definitely would be incorrect. It may very well be incorrect even if I remember ART's previous explanations correctly. In that case disregard what I have said here.
Steinar
-
Steiner,
The best i can do "easily" is measure visualy when the sensor turns on and off and that is repeatable within 5 minutes of an angle. So that's one ball park useless number. A 0.003" error between two actual scribed lines was around 10 degrees of a rotation. Now doing 50 moves using a G32 Z-2.0" F.050 from Z=0 showed all 50 moves ending within a 0.001"distance which tells me that the trigger is very repeatable and the axis travel and acceleration together was consistent. Then i even broke that down by .1" moves from Z=0 to 1,1.1,1.2, etc and all was good. The start Z=0 and ending point Z=-2.0 was confirmed using a calibrated allignment telescope and scale. The scope is 40X at 12" and has an optical micrometer ( measures to 0.0001" ). So can't do too much electronicaly, but, the end physical result is what is important.
ART,
When i run the driver test PPS is 25455. The kernal speed viewed on Chips lathe screen that we used before for testing, shows a pulse frequency of 25452, but if you go out and come back into Mach it will change to 23654. It will continue to show the 23654 for however many times you exit and come back into Mach. Now reboot and the the above numbers will repeat as described again.
I did a third test piece at 0.1" pitch, the lead decreased by .008" / inch and the pulse frequency on the screen was 23654.
Like that show that was on TV " You Asked For It". Well they are the pulse frequencies. ;)
RICH
-
Hi Rich:
Seems pretty stable.. Almost like its correctable by adding a correction factor for a person to enter. I suppose one could make the feedrate command .8% faster.. but Ill come up with some tests to prove what the heck it is if I can.. Still dwelling a bit while I finish up my workshop..
Art
-
Winters coming and you need to get the shop done.
A user enter correction factor would be nice. I certainly would want others to confirm what i found. So if it's user correctable and they do testing, than at least It comes from a know base point of reference.
RICH
-
Rich:
Well, at least youve proved the kernal speed we end up with is not a factor. I suspect we can eliminate that, there is correction in the code for that, and it appears to work as all kernal speeds appear the same. Im thinking we simply are a few rpm off in spindle speed measurement.. ( .8% perhaps?) or somethign similar..
Art
-
Now we start the movement, since we're in mm/rev mode, we know the mm's of motion were calculated based on 24,000,000 clock cycles per rotation. If the ortation is sensed to be now 2700,000 clocks per rotation, we know the spindle has slowed by 12.5% .. so we now slow the output during the next rotation by 12.5%, and keep track of this rotation.
I pondered this proceedure when Art originally posted it, but a pitch error INCREASE would not be consistent with the above quoted correction proceedure, so it was an unresolvable quandry. Now that Rich has discovered that the pitch is DECREASING, it makes sense.
Therefor, I can submit a possible solution . . . hopefully.
Taking the above quoted proceedure as literal and accurate, a correction of only 100% of the previous rotation error is not adequate. While the error would removed from subsequent rotations, the original measured error remains. Also, as stated elsewhere by Art, the process begins anew with each pass. So absent historical data being brought forward, this remaining error would naturally accumulate.
My suggestion for a solution to this issue is simply to make the correction in a subsequent pass in an amount that will not only eliminate the error in the current pass, but ALSO make the correction for the error measured in the previous rotation, which is still present in the thread at the begining of the 'correction' rotation. Only this combined correction would result in restoring the correct relationship at the end of the adjutment event.
A simplistic example would be that the measured error is 5. If the next rotatation compenstaes by 5, as described in the quoted passage, then the overall thread progress still contains the original error, which will be carried thru the entire pass, and then be componded by the same process occurring anew because the next iteration is blind to the previous data.
It seems to me that adding a correction for the previous (measured) rotation to the calculated correction for the current rotation is the missing link.
-
ART,
Did a few more test pieces today. Same 115 rpm, 40 passes @ .0001" deep for 10,20,40 TPI.
I used the standard lathe screen and threading wizard.
Now we know that the tracking was good but the lead was decreasing. So i tried the tests with adjusted lead.
The rounded lead error was a decrease of .008" / inch. So I just changed the lead to be used in the wizard as follows:
TPI TRUE PITCH MODIFIED PITCH
10 .1 .1008
20 .050 .0504
40 .025 .0252
The Gcode provided by the wizard will post the modified feedrate ( namely .1008 / .0504 / .0252 ) even though it rounds it in the wizard screen.
The lead error in 1" was almost un-measurable ( including each crest / root distance ............ 0 or under .0005" / inch. That's about as perfect as you can get! Heck, what are you measuring, the lead screw accuracy if you know what i mean.
You can also decrease the inputed lead if you want to take care of an advancing cut lead. I haven't tried a 0-80 to see if the lead should be modified to .01256 ( don't cut to many 1" long 0-80's ).
Will relative / ratioed numbers hold true for other rpm? I don't know.
So, if you left the threading code alone, and a user tested ie; cut a scribbed test piece at .1" pitch for 1 or 2" long and very accurately measure the lead, then adjust feedrate accordingly, they may just solve their problem.
It's a work around, an easy one, but users must remember that there are a lot of other influences that can play into threading.
Is John S doing any testing?
:) :) :) :) :) :)
RICH
-
Here is apicture of the threads done in last post. There is only one single scribed line on each piece.
BTW, you need a realy good top notch tach to measure IPM accurately. Just thought i would mention that in case you try to measure and associate spindle rpm to actaul Z feedrate while threading. Myspeed indicator just doesn't cut it.
RICH
-
Rich:
Interesting. Youve proved that computer is very stable, its also interesting that at 115 RPM it seems no matter what pitch, .8% increase in pitch will
make it correct. Be interesting to see how that scales with feedrate. By the way, have you ever used the advanced threading plugin to see how the RPM
measurement differs from the normal Mach3's? Id be curious as to hwo it reports RPM vs how the normal Mach3 reports RPM..
In the advanced threading plugin, if you set the timing and index inputs both the the index pins input, it will act as if you have a 1 slot wheel on it, and will read
the RPM based on actual time, not interrupts.
Simpson:
The code actually does carry history forward.. Ill see if I can come up with a better explaination of how it does that, really I need to get in there and study its behaviour a bit
to refresh myself before I attempt it. Ive been working on Tempest a bit too long, I get a bit rusty on the threading code. :)
Art
-
ART,
Assume the advanced threading plug in was the one we trying to use a few months ago.
Is that correct?
RICH
-
Hmm,
Ok, i have a working opto that i can use and can make up a multislot disc rather easily for it. One is encoder #3 and one is the index in the pin out if i rememeber correctly.Since both work off 5 volts that may be rather easy to do now for me. I thought i could be rather tricky and just take spindle and Z axis ft /min, but quickly found out that my rpm counter is not accurate enough.
I will do some testing at other spindle speeds to see what happens.
RICH
-
Simpson:
Just had a refresher on how I did that in the threading module. I figure a better explanation is in order of exactly how I
manage single point threading. I tend to agree on the face of it with those that say its impossible, but when I developed it
I wasnt aware of that. :-) , so I did as cloase as I think could be done given the restrictions in architecture.
So we have to accept certain givens..
1) Motion is preplanned, in a buffer of steps. This buffer can be considered an endless array of bytes. most of the time each entry will be zero. Each interrupt cycle.. at 25000 times a second, an array iten is retirved, and analysed, if a bit 0, for example is a 1, a step is put out on the X motor. If its a zero, no step is put out, if -1, a backwards setp is put out. That array item is delted, and next interrupt we get the next one( This is all simplified for examplication. )
2) Due to this, the driver of course knows nothing about speed, acceleration, or even if a motor is stepping or not, we simply have an array of bytes, and we step though that array one byte at a time. Mach3 continuously refills this array of bytes so the next stepo will be correct.
3) TO measure RPM, we count how many interrupts between each index pulse. This is divied out to find the rpm. ( The advanced threading uses time as the measurement)
Ok, so we have those limitations, we have no idea what speed any motor is moving.. or even if it is. BUT, we know time is linear, counting at 25000 steps a second. We know prior to the threading starting that the spindle is hitting index every 11345 interrupts. ( for example).
So when threading starts, we start a counter.. we count the number of interrupts between each suceeding index pulse and place it in a var called CURRPM.. Then, every interrupt we add CURRPM to our originally zeroed counter, we then subtract the reference index pulse count. If this number is greater than the reference count, we skip an interrupt processing. This is a bresenham divider time relinearisation of the pulse streams time, not the motor motion directly. A motor moving at full speed, would then have 1 step delayed till next interrupt, but normally, this operation would be a small fraction of one step of a motor in time.
Thats a bit hard to understand.. consider this sequence of events..
Kernal speed 25000. Threading is commanded and spindle RPM is 120. An index occurs every 12500 interrupts. Threading begins..
On each interrupt counter = (counter + currpm) - refrpm
we start with..
Counter : 0 CurRPM: 12500 RefRPM: 12500
The counter wont change for 1 full rotation, its always getting 12500 added to it, and 12500 subtracted from it..
Now the next interrupt comes in at 12900..
So on that interrupt, the counter is now 12900 - 12500 = 400.
Eachinterrupt this number will increase by 400. When it hits 12500, an interrupt is skipped. Not a motor step, an interrupt.
This means time is stretched, the motor motions, all equally are slowed by 1/25000 of their time base. The ref is then subtratce from the counter and it all continues.
This means that as each rotation slows..or even maintains its new speed, the error count grows, and is compunded by further slowdowns
so it actually has a sense of history. Time corrections are also applied linearly across the motion for this correction. And since the number subtracted when an interrupt is skipped is the ref rpm, fractional counts are kept, and spread across the next rotation. As the speed increases to normal speed, the counter approaches equilibriam again with its total zero.. and no further time intervals are skipped.
This is all necessary due to the way motion is planned before the threading begins, so all we can alter is time itself, not anything to
do with motor motion.
You question is well put though, if the spindle has slowed by 1%, we can then pretty much anticipate that the next will also be 1%, so why not double down and correct at 2% for the first slow rotation. You cant really do that though as you cant really make that assumption. It could be just a slightly slow index input for example.. so its best to stay exactly one rotation behind at all times. Mathmatically its the best one can do with a single input, If the RPM is, indeed ,slow on the next by 1% again, then it hasnt changed, nor will the algorithms slowdown, it will be exacly 1 rev behind, but if for whatever reason the rpm increases back to normal, ( VFD self correction for example ), then the algorithm will automatically speed back up to normal and we'll be exactly 1 rev behind it again.
The only way we get fooled is if the vfd speeds up to a speed greater then the start reference speed, in which case the error from the previosu rev cannot be corrected, and will be forever locked in, and will grow on each rev that is faster than reference. However, since remainders are taken into account by the bresenham, its counter goes negative by the uncorrected amount, and should the rpm slow down, the algorithm will not slow down to compensate until the over speed that was uncorrected is eaten up.
Its a pretty simple algoritm, simple enough to be very smart. Overspeeds will be corrected when and if they can, underspeeds will be 1 rev behind at all times, and very small fractions are accounted for. Its why its actually possible to do this without knowing anything about the motors motion, its simply the matching of two varying time bases by a counter than keeps track of total time with no capability of rollover.
Hope this explanation helps, it actually helped me to write it and get reaquainted with how the heck the code works in the first place.
Thx
Art
-
Rich:
John S is at a show, but he'll be joining us soon on this.
For the multislot, you can use an encoder input, ( on ecoder #3 as I recall) OR a timing input, as well as index input . If using encoder I
think its possible to just use the encoder. I need to look at that module now and get back up to snuff on how that worked. Last threads cut on it were
looking good to me, but had variances similar to your initial tests. The two work very differently, so similarities in results will help point us to the real culprit and what
( if anything ) can be done to make it all better.
I do recall the new module was much better at rpm measurment..
Art
-
ART,
Just a few more tests.
I was curious on how things would behave as the spindle speed was increased.
In post # 481 things scaled rather linear at 115 rpm. as shown below.
TPI TRUE PITCH MODIFIED PITCH
10 .1 .1008
20 .050 .0504
40 .025 .0252
So i did some testing at higher spindle speeds. If I go past 600 rpm i would need to change kernal speed
above 25000khz so a little limited ( trying to keep stuff constant).
The threading was for 10 TPI ( .1 pitch ) 40 passes.
RPM PITCH / Inch MODIFIED PITCH USED FOR PERFECT LEAD
(DECREASE)
115 .008 .1008
194 .0055 .10055
402 .0035 .10035
So the pitch decreases also as the RPM increases. I will assume that for smaller threads at the higher rpm
they would proportionately decrease as like the 115 rpm tests for 10, 20, 40 tpi.
Just a note, according to Mr. Smid, a lead error will be intoduced on long threads if you use a Feedrate less than
six figures ( not required for leads divided into 4 or fewer decimal places ).
RPM
--------
I din't try any of the advanced threading plugs in yet. I will confirm my measured spindle rpm's later since a friend will be lending me an accurate time measuring device.
I wonder if the error goes away at 1000 rpm?
RICH
-
Rich:
Interesting. The error decreases as speed increases.. I would have thought the reverse would have been true.
Since any perterbation of the timing in any of the variables would be a larger percentage of the time of one revolution
as we go faster, I would have thought any constant affecting us would then increase the error as we go faster.
It would seem then that whatever the error is..is isnt a constant. It must be progressively getting smaller as the
interrupt timing gets smaller. I woudl think calcuated feedrate cannot then be the problem as its decimal granularity is the same
for all speeds. I have to give this some thought as to why the non-intuituve nature of that result. It may be that any correction
being done is being doen for shorter periods as we go faster.. so any error in correction would then affect the result less and less.
Also, as the correction algorithm runs, its numbers woudl be smaller so interrupt skipping woudl occur less frequently..
I think I may have to send you a driver with speed correction turned off entirely to see what the effect of that would be, I think
Im getting an idea of where the problem may lie, it may be a granularity of spindle rpm measurment causing a correctiion to be applied
that is really not necesaary..
Ill crunch some numbers and let you know what I think.
Art
-
ART,
All i can do is try to give you info that is repeatable here and measured quite accurately. If you want to try something, just send it to me.
It would be nice if the threading diagnostics would "capture" the info it's displaying as that may give you a look at
each complete threading cycle for comparison.
The only other thing we can do on my end is, maybe, is to capture the spindle triggering tiiming and also put an encoder on the end on the Z axis and capture it's movement relative to the spindle. I can't do that, but i know
a friend who would probably do that and has the expensive o'scope that would do it. But not sure it would be of value and that takes some time to do it right.
RICH
-
Rich:
Dont think we need to go that deep. The numbers appear to be telling astory.. Im just trying to decipher what it is. :)
The fact teh accuracy increases as rev speed increases seems to show that the long time of correction between rev's is allowing an error
to creep in, the lower the time between rev's the less the error.
Ill generate a driver with no correction to see.
Art
-
Sounds good to me. I am very curious.
RICH
-
I am not sure how relevant a test using the SmoothStepper is but its all I can test with due to no parallel port on the Pico mobo.
Lathe has 12.5 Kw AC Servo on spindle and Index pulse from encoder is used via the SmoothStepper.
First test was a scratch test 2 mm pitch 200 mm long 24.5 mm dia and 1000 rpm. Measured the full 200 mm with digital calipers and also laying a 200mm mic along side and could not see any error.
Second test was a scratch test 2 mm pitch 200 mm long 29.5 mm dia and 200 rpm and again measured as above and again no error detected over the 200mm.
Also put both threads alongside each other and again could not detect any errors.
Hood
-
Hi Hood:
Well, it proves the feedrate and such are all being computed properly. Thats a help. Any error must lie in th edriver.
Rich, heres a driver that has no correction, its turned off, otherwise all is the same.
To load it, you need to simply remove the driver using control panel, then copy this into your mach3 folder, and run drivertest.exe.
If you get the message "Driver is loaded , Reboot", ( you dont have to reboot), then install worked. If you dont, you didnt remove the old
one properly. ( Id back up your old one just renamig it mach3.sys.old
Good luck
Art
-
Thanks a bunch ART,
I was waiting for it and will do a few tests today.
RICH
-
ART,
First test with no correction. I was just interested what the lead would be like.
Test done at 115 rpm / 40 passes at .1 pitch / .0001" depths same as all the other resting.
There was a single scribed line and the pitch decreased by .007". Now i measured two quadrants of the scribing and that was the average since one was .0055 and the other was .008. So a small change maybe not worth considering.
There is something interesting, maybe:
Ran driver test for 25000khz and pulses now at 24802.
Chips screen shows kernel at 24933.
I rebooted after the threading test and got the same same exact kernel as above. Those are different than what was shown in the other tests.
The other driver showed 25455 and Chip's screen reported 23654.
I didn't see any reason to do some more scribing tests figuring if that one was off the others would also be off.
So what do you think?
RICH
-
Hi All,
Just a little info on the visual inspection and pictures that i am posting for your reading pleasure.
Here is a picture of the scribed line located at about 2". The test was done with a new sharpened pointed tool.
The intent of checking the end of the scribbing is just to confirm that there is a single scribed line that i am measuring to for checking the lead. If there are multiple scribed lines then something mechanical, electronic / electrical, or even software can be causing it. So there is consistentcy here. I will remark that the line is .002" wide and .002" deep after 40 passes. The picture is taken with a camera through the fical micrometer eyepiece at 40x .
So you can measure directly to 0.0001".
During the threading cycle, the actual cutting / scribing is being monitored via a 30x microscope mounted on the lathe carriage. You can see the actual scribing cut and watch the width as the passes increase. Should any "tracking" of the scribed line vary , then the pass that created it is noted.
Now up to this point, most of the error that's been noted is over a 1" distance. If you have error at 1", the error will continue on down the thread. So if it's .007" at 1" of threading then it will be .028" at 4". No long threads have been done because it would just be wasting material and taking a lot longer to test.
I'll try and post something to put the error into "practical" perspective later on.
RICH
-
Hi Rich:
Wow, thats pretty clear. SO the lines are pretty good, the pitchis decreasing by .8% or so ..
>>I rebooted after the threading test and got the same same exact kernel as above. Those are different than what was shown in the other tests.
The other driver showed 25455 and Chip's screen reported 23654.
Not important. What happens is that as the kernal starts up, it measures the number of interrupts per second, and vary's a few internal variables that
control the operating system, when it figures its close enough, it locks them in so they dont fluctuate. Mach3 takes into account what the number is when
planning, so the differing kernal numbers should have no effect, and they dont seem to.
So we're left with a variation, .8% at 115RPM, lower as we go up.. Ill crunch some more numbers tonight to see if I can see where that may be at,
though Im off the mind that its the RPM reading thats off, .8% of 115 woudl only be a bit less than 1RPM, so thats likely where the error is. The error
seems less at higher RPM's, but that may make a twisted sense of logic happy in the driver..
We're thrust next on trying to make the RPM more accurate to see if that helps. The smoothstepper counts the RPM internally on a firmware clock,
and the tests you have done don't. Id like ot know though if a set RPM reads differently in the advanced threading plugin as opposed to the standard rpm ,
the advanced plugin tells you both I think, the ratio between them may be interesting ....
Thx
Art
-
ART,
I'll do the advanced timing test.
I will say that the Threading Diagnostics screen always shows that the Real Time rpm is higher. It will float from 195.5 to 196.1
Till then,
Rich
-
ART,
Made a 78 slot disc for timing, unfortunately, my optio is bad and need to order another one.
So no advanced timing test.
The plug in that i used for the advanced timing test was the one posted on page 24 / reply #238 of this
thread. Can you confirm that is the one to use?
There are only about 15 or so test's that have been posted in this thread! ???
RICH
-
Rich:
Yup, thats the one. If you set the index and timing to the index pin, youll still be able to use it with only an index pulse..no wheel required.
Art
-
ART,
I tried the advanced timing. It only shows that there is one slot and provides no slot or timing rpm data.
I looked at the diagnostics and it shows there is timing.
The index is port 1 pin 15
The timing is port 1 pin 10 ( pin15 and pin 10 are using the same signal )
If i remove the wire from pin 10 then the diagnostics will show 0 slots.
SO that one didn't work!
-------------------
"If you set the index and timing to the index pin, youll still be able to use it with only an index pulse..no wheel required."Ok, that plugin was posted on page 26 reply 253.
The index and timing is port 1 pin 15. Same as the other one no rpm data.
??? ??? ??? ???
RICH
-
Sorry about that Rich.
Ill check why and reissue the plugin after I test it on my lathe for RPM operation. I probably need to make a small
change to allow for single pulse intput..
Art
-
No problem. ;)
RICH
-
Hi Rich:
Just to be sure we're on the same plugin , I publish it here.
My results show the RPM is much more stable under the advanced threader plugin. It shows a normal RPM of 393-395RPM fluctuating constantly,
the advanced threading shows 393.50 to 393.6 RPM and very steady. This fluctuation could accoutn for a highe rpitch error at low RPM, and lower error at high
RPM due to the fluctuation being a smaller % of the total RPM, and your testing seems to point directly at that possability. If this can be confirmed, I will simply
change the single point threading to measure the RPM based on time, not # of interrupts.
Here is a photo of my advance3d threading run, both Timing and Index inputs are enabled and both are set to pin 15 ( my index signal).
I ran a test thread in the air and all runs fine, so I suspect you can thread quite well even with one slot per rev which is what will display under such a setup.
Im of the opinion that it isnt necessary to have a slotted wheel, though it may make things more accurate as instead of being one rotaiton behind, the corrector
will be one slot behind.
Let me know how it goes..
Thx
Art
-
ART,
I love it when a plug in works first time tried!
This is using Mach version .028
Here are screen shots at 115 and 402 rpm.
Even though the lathe screen DRO flickers by 1 rpm in both 115 and 402, the advanced diagnostics is showing the slot based rpm to be greater by percentages which relate to the threading tests that were done ( ref my reply #488) .
So for 115 rpm .9 rpm such that .9/115=.0078 ( .8% change in lead )
During the 115 threading dry run the rpm for threading to the thread based rpm only changed by only .01.
So for 402 rpm 1.27 rpm such that 1.27/402=.0032 (.3% change in lead which very close to the .0035 lead error) and somewhat confirming the testing.
Maybe you have found were the rat was feeding and it's about to get a dose of poison! ;D
Question / confirm?
If i do actual thread testing, then I'll need to have the Advanced Threading checked / Enabled and it will modfy the threading cycle appropriately?
RICH
-
Hi Rich:
Yes, in theory the multislot works just as the single slot does in terms of correction, but though it will thread it isnt heavily tested.
Id be interested in the results, but dont be too disappointed if some other problem develops, I think your testing has shown what
the culprit is, the RPM varys too much when based on # of interrupts, but when based on the gigaclock counters, its much more
accurate and true, so in theory all I need to do is change the normal threading to gigaclock based counters and we should be able to prove a
perfectly working system can thread just fine, though thjose with varying systems may still see some aberations..
Let me know how it goes..
Art
-
ART,
I'll do some testing tomorrow and mid-next week we'll see if we can measure the actual motor variations.
Attached is a file which kind of puts things into perspective. The threading has come a long way thanks to your efforts.
You may want to take a look at the "Rich Chart" on lead error. I think we are close and can get there.
RICH
-
ART,
Only one test done using advanced threading. Picture attached.
Something went wrong after the 6 th pass. The first 6 were a single scribe but the lead decreased .006" in an inch.
Like you said, expect the unexpected and keep the hand on the ESTOP!
RICH
MODIFIED: OOPS, the .0007" dim should be .007" in the picture.
-
Rich:
Interesting that the 6th pass didnt trigger at the wrong time.. it appears to have a much greater pitch is all.. so almost as if the rpm locked in
at a higher rate than the previous ones locked in at. Higher rate of RPM caused the feedrate to be higher.. so the pitch increased..
Ill give this some though. Interesting too that the pitch still decreased by .006" , better than .008 .. but we may be seeing come correction
error since this uses toally different correction coding.
I think Ill change the RPM to do time based on the old single pulse and see what the outcome is..
Thx
Art
PS: Love the document from previosu post. Says it all very well.
-
Rich:
Sorry this one is harder to test. You need to run the enclosed Mach3SpindleTime.exe AND load the enclosed driver to test it. Turn off Advanced threading for this test,
it basically changes the spindle RPM under the old system to a time based measurement. I suspect youll find your reading slightly higher RPM's, and this will
lead to a slightly higher pitch, so its quite possible the lagged thread will be correct. That , at least woudl be one bug poisoned.. :)
Thx, Good luck
Art
-
ART,
WIll try it out later today. A couple of honey do's to do. Should post after 6 pm or so.
RICH
-
ART,
Only one test @ 115 rpm / .1p / 40 passes.
Single scribed line, pitch improved. The lead decrease now 0.005" / inch instead of .008".
I didn't make note of the rpm range changes , DRO stayed at 115.
Want more tests or you going to tweak on your end?
RICH.
-
Hi Rich:
Do you know if SpindleAveraging was turned on or off? Id prefer it off.
Good sign if the RPM stays constant with averaging off though, that would
mean the time nature of it is much more stable
than the old way, that may explain the better pitch.
Im trying now to think what elese may be inaccurate. If we know RPM is now accurate,
( or we assume so due to stability ), then a couple things are possible..
Its possible the PCI clock is misreporting the number of clocks per second, which I base the RPM on.
Since compuiters tend to the binary.. a second can really mean 1024ms or 1.024 seconds. That would explain
another .24% of error. Im leading to the RPM being the trouble since its about the only thing that could explain
why higher rpm's are close to pitch than lower RPM's.
SO I think Ill try a tweak that assumes the reported pci base clock is counts per 1024ms just in case the chip
designer had a prediliction to think in binary when describing a second.
Thx
Art
Back to you soon.
Art
-
Hi Rich:
This one is an experiment. Same driver you just used.. But Im correcting by 1/2 the assumption of 1024ms per second. Seems to large a correction,
but Im interested in the resullt.
Art
-
The spindle speed averaging was on but i'll turn it off for reply 515 test.
RICH
-
Rich:
Thx., Probably doesnt matter if on or off, in fact since you normally have it on and it varys , that shows its more stable with
the changes anyway. So in the end it probably doesnt matter. Might be better on in fact.. hard to say though. ( Am I dithering enough.? :-) )
Art
-
ART,
TEST: REPLY #515 / NO SPINDLE SPEED AVERAGING / NO ADVANCED THREADING / VER.028
115rpm / 40 passes/.1P
The real time rpm increased some to 115.75 and fluctuated by about .5 rpm.
The application rpm increased to 116.6 to about 117.1, DRO read 117.
During the thread:
Real Time application 115.6 ,while application was 116.6 to 117 rpm ( roughly)
I noticed the elongation of the scribing about pass #10 ( didn't have the microscope attached to the lathe ).
So picture #2 shows the cutting about 1.6" from the start of the thread. Notice how it gradualy tapers inward as
each pass was made. That just says the Z axis and timing seem rather consistant, and if it varied a lot
( up and down ) then backlash or or something else is going on.
The lead increased.
RICH
-
ART
To late, test done.....you be the judge.
What next?
RICH
-
Rich:
Hmm, sounds liek averaging should be on. The gradual tappering from pass to pass seems to indicate that its not locking in at all and its sensing a differing rpm as it goes.
We didnt see that before the averaging was turned off I dont think. The increase pitch seems proper, I added 1%, and it seems to lead by 1%. Can you restest just with averaging on,
do we then get a repeatable pitch of .01 over? If so, Ill back off to 0 again.. I think I didnt help much on that one. I need to check the RPM gets properly locked, I think I may have screwed up..
Art
-
No problem. Will due a test in the next hour or so.
RICH
-
ART,
With averaging on got a single line scribe and the increase in lead was 0.0033" / inch.
Made a big difference.
RICH
MODIFIED: All the other tests were done with averaging on.
I will be out and about, returning on Tuesday. I may have some time early tomorrow to do some testing.
Experiment as you wish. I am looking to the day when that lead goes to 0.000" / inch or exceeds my equipment.
Then will try longer cuts, heck, still got 20 feet of copper tubing to play with!
BTW: For excitement all you have to do is forget to do a reset back to G94 after threading, dam a trueing cut
can realy move fast. :D
-
BTW: For excitement all you have to do is forget to do a reset back to G94 after threading, dam a trueing cut
can realy move fast. :D
Do all your lathe work in FPR and that wont happen ;D
Not sure how much of a hassle it would be for you to hook up the SS and do a test, just it would be interesting to see how that works for you as it is perfect for me. I cant use the PP to test as my pico doesnt have a PP but when I had the previous mobo in I did tests with both PP and SS over a 150mm distance and all were accurate and all exactly the same.
Hood
-
ART,
BTW: For excitement all you have to do is forget to do a reset back to G94 after threading, dam a trueing cut
can realy move fast. :D
Rich a line at the beginning of all your code to set the correct operation is the way to go check my toolchanging problem thread again for an example.
This is done in the post processor in my case.
Phil
-
Hood,
SS is still in the old pc and I'll get around to installing it in the new one. I am also curiuos.
Just been focused on trying to improve threading when using the PP with a single pointed tool. Comparitively, using the SS would be an apple and not an orange.The file I recently posted about lead error says it all. I am also curiuos, if as shown by changing the feedrate, if it will hold true for long threading. That was like zero for a 2" length, which implies, 4" of threading should work fine. The long thread would magnify any lead error.
On the practical side of things, in all these years , i have only needed to do very accurate threading to 6" or so and that was for replacing a screw and nut in crossslides. The screw was matched to the nut and was done with a manual lathe. I am hoping that we can refine PP threading to equal a manual lathe. For threading it would be per the
file i posted.
BTW, this testing is not about "Rich's" threading. It's in light of the typical hobbiest that will use Mach threading with
a low end CNC system ( if that is a way of saying it ). It will be nice to be say to a user, with confidence, that his problem is the lathe system.
Any suggestions appreciated, as more viewpoints are a lot better than one,
RICH
-
Hi Rich:
Hmm.. .003 eh? Well, try this one, Im suspecting a 0.000 spread from expected. ( or close to it).
Art
-
btw,, Its Thanksgiving here in Canada, so Ill be hard to find most of the day. :-)
Happy Turkey-Day. ( for Canucks anyway..)
Art
-
Art,
Enjoy the feast. Will do a quick test and post. If it's good, then will do more tests when I get back.
RICH
-
Rich,
wasn't getting at you, what I was getting at is you are testing with the PP and if you can test with the SS then it would be interesting as it could show up where the error definitely is. Example if you didn't have these problems when using the SS then the issue has to be down to whatever threading is using with the PP, if however you still had the problems then it points to a computer issue and it may help Art home in on why some work and others not.
Hood
-
ART,
TEST: REPLY #526 / SPINDLE SPEED AVERAGING / NO ADVANCED THREADING / VER.028
115rpm / 40 passes/.1P
Not zero but close. The threading was done to a 2" length.
The lead increase is .002" per inch. I measured along the length in 4 quadrants of the
piece. Lead as follows:
.5" - .001"
1.0" - .002"
1.5" - .003
2.0" - .004'
Single scribed line. I wanted to make sure, so see attached pic taken at 100X magnification.
The first scribed line looked just as good as the last one along the length." like that.
Just a sharp V and no sloping towards the root.
I can't test anymore until I get back on Tuesday.
How about another tweak if you think worthwhile? If the additional testing with finer picthes goes sour for some reason then i can pull back to this one for comparison when finer pitch's or increased speeds are tested.
HMM......like my music prof used to say......
"Perfection is allways sought after, never achieved, but much is to be gained in the pursuit of it."
RICH
-
Hood,
Didn't take it that way my friend.
These tests are being done with the new computer and converted lathe. There is no comparison, so to spead of, to the Sherline lathe relative to repeatabilty and accuracy. I think the same about the computers. In fact, i am right with you in thinking. Current testing would be one system taken to some level and used as a basis to compare other combinations. I can then mix and match computers, lathes,SS and see what happens.
It could be that what is good for one system is bad for another. If another person starts testing and gets different results, should be able to relate or question more intelligently.
I am still a little concerned about the motor i am using as to rpm and Wednesday a friend will be coming over and we will test and see what we get. You can't use some of the rpm tach's since they read to .05% +- 1 rpm and that isn't good enough. We may not be able to do any better. Gets back to component verses the lathe system as a whole.
I certainly don't want to waste Art's time. Hopefully he's getting a lot of comparative info for his use.
Darn if i am not learning a lot.
Just some thought's,
RICH
-
Rich:
Looking pretty good then so far. I think your right, lets press the envelope and see if we can make it as good as we can. Here's a .001 correction applied to
previous version. Tuesdays fine, and again, as always, thanks for the great results posted. The interesting thing will be how it scales to higher RPM's, if we do achieve zero
runout.
Art
-
ART,
Tests for posted version in reply #532.
TEST#1 - 115RPM / .1P / SCRIBBING TEST STOPPED
I stopped the scibbing test at pass # 11 because on the third pass timing went bad.
The first three passes had a .009" / inch Decrease.
The following 8 passes had a .003 / inch Increase.
Both were single line scribes.
TEST#2 - 115RPM / .1P / 40 passes ( retest to see if test #1 would repeat )
I left the spindle run for a few minutes.
Single scirbe at .003" Increase in lead.
Picture #1 shows test #1 &2
TEST#3 - 402 RPM / .1P / 40 passes ( to test scaling due to rpm change )
The first 10 passes were visualy consistent and a .002" / inch Increase.
Then a slight change at pass # 11 and consistent passes until 21.
Pass 21 changed the lead and was consistent to #39 and there was a .0055" / inch Increase.
Pass 39 changed the lead to a Increase of .008" / inch Increase
SO three passes, and at some time interval ( pass 11, 21, 39 ) you got an increase of lead.
Picture #2 shows the three intervals.
SO this is a mixed bag, but, the change in lead over a some time period reminds me of what I and
others have experienced with the current threading, that sometime during the complete threading cycle,
one or two passes are cutting deeper.( I don't think that is really what happens, i think it's a change in lead
as you can't see / measure it when actual full cut threads are being done. )
I should have left test #1 go on to see what would have happened.
I am going to go back to the version that gave a .002" / inch lead error and expand that testing some.
See if it behaves stable. Can i repeat the one test done?, will there be any pass changes?, scaling at rpm?
Any comments?
RICH
-
Rich:
Thanks to your testing I think I have a grasp of whats going on. What to do about it is more complex.
I'm not as sure as to why the variable lead.. though its pretty close at this point, but I highly suspect
whats going on is the RPM is locking in at variosu values at times. This can be caused by many things.
Mach3 when it gets a threading command, sets up the pass using the current spindle RPM, a split second later
the driver see's this command and "locks in" the current spindle RPM for the entire pass, correcting if the RPM changes
from the "locked" rpm.
So one of two things is causing that intermittant bad pass. The RPM is wrong at some point in the process. On the versions
your testing the correction is turned off, that helps narrow this down. It means for sure the RPM is different by a percentage
from one pass to another. If the locked in RPM is different from the RPM that Mach3 used to calcuate the pass, youll get a
leading or decreasing pitch on that pass. We can see a .001 or .003 or .005 pitch as normal, but then on a particular pass the
RPM gets locked at a wrong RPM.
I have a few things to check inthe code now.. it could be the planner is processing the next threading pass before the first is done, thus the rpm
could be lower due to load when the next thread command is processed. I need to ensure it locks out the next runs processing till the first one is done.
You can stop testing for a bit while I digest the numbers and see what I can do to tighten this up. Hopefully , thats all it is,
otherwise it means the RPM is wrong occasionally for some reason.. and that may be arder t find. :)
I suspect youll find even the earlier version do as this report suggests, specially if the spindle is cold. I have heard runnign it for a few minutes till stable
helps it be stable through the run.
Thx
Art
-
ART,
Post when you want to try something.
Appreciate the effort your putting into the threading.
RICH
-
Hi Rich:
One thing I notice while looking to the code, you really need a G0 move between any G32 moves.. With G76 this isnt a problem as it injects g0 moves to pullout, but in yur testing, did you use G0 moves to reposition the passes back to the start?
The of the g0 makes the next g32 only use the rpm current at end of g0 before it plans the next thread pass speed. Seems I may need to do some work on that..
Thx
Art
-
ART,
Yes.
All the code is generated by the threading wizard and the m1076.m1s is set to true. You get two G0 moves prior to start of the thread. Before Cycle Start is clicked to begin the threading, i always waite some time, not moving the mouse etc. and don't do anything during the threading. Once i opened the threading diagnostics window after a thread pass and it caused a major lead error in the next pass. So i don't even touch the mouse etc during the threading post Cycle Start.
BTW, we checked the spindle rpm out today. The home built counter can read to 1us and is better than digital storage scopes as the sampling rate, and other stuff can be changed. The index pulse was used for input. Basicaly the instrument does what your advanced diagnostics provides minus the graphing. Anybody using a mechanical rpm reader or tach, well I will say, the diagnostics in Mach lathe is better!
RICH
-
Rich:
Thanks for the verification. Now that the RPM is measured based on time rather then number of int's, in theory the susceptability to
switching screens should be less, but still there.
In general operation as the index pulse swings by the sensor, MAch3 will either see it immediately , OR on the next interrupt. So
the typical variation of RPM cant be made better than + or - 40us at 25Khz. SO a variance of 100RPM to 99.99 is what we should get
typically. Its hard to explain why the spindle may get a planning RPM very different occasionally to make the thread advance so much.
Hmm, I guess thats the golden question isnt it.. what rpm WAS used for each line. I think Ill make a version that saves a debug file
to show the planned RPM for each pass of the thread. If it shows the RPM has varied greatly on any pass from previous passes, that will
prove the advance was due to planning at a different feedrate.
Ill post a version soon to do exactly that, youll be able to forensically see what feedrate was the end result just as it was planned.
If that shows very stable, we look elsewhere.
Thx
Art
-
Rich:
Each time a G32 is processed, this version will write into the lasterrors.txt file the velocity in units/sec for that thread move. Be interesting to see the velocity it picks each move..
Thx
Art
-
ART,
I'll try it it tomorrow. My luck, the rat will stay in it's hole and not come out!
RICH
-
Rich:
Yup, I always find that when the trap is set..the buggers stay away. LOL
Art
-
Hood,
Got the SS installed today and decided to run a few threading tests out of curiousity.
These were done using MACH Ver.027 with the SS and also shown below are prior test using using the PP with ver .027.
.1P / 40 PASSES / .0001" PER PASS
PORT RPM DECREASE / INCH
------- --------- --------------------------
PP 115 .008"
SS 115 .006" COMMENT#1
PP 402 .0035"
SS 402 .0032"
COMMENT #1 - There were multiple cuts due to varing lead ( almost as if you were doing an alternate flank cut thread ) but enventualy going back to the center of the scribe. They occured at pass 16, 22, 30, 37, 38.
The SS @ 402 rpm test had similar effect.
Frankly, just based on what has been done recently, i would say the PP threading has improved over the SS based on scribing tests. I would have to explore it some more though. :o
ART,
I did about 20 dry runs and the rat never took the baite, so nothing to say about error reporting. I did everything i could image to screw up the timing, nothing!. The error report did pick up that i disconnected the pulse plug though and resumed the threading. ;D
RICH
-
Rich:
Was there listed in the lasterrors.txt file a bunch of feedrates?
Lines such as "Threading run: Velocity: xx.*********" should have been in the file. Can you let me know how variable they were? Or were they all the same..
Thanks
Art
-
Very interesting Rich, from that it would seem that you have some issue with either the computer or index pulse or something that I don't have. Granted I never did all the passes you are doing, if you post the code you are using I can give it a shot tomorrow and see what my results are using the exact same method.
I dont have the means of optical measuring that you have but if each pitch is off by the amount you are saying it will add up to a lot over the 200mm I will do so I can easily detect.
With my last test to confirm I measured with digi cals, mic and also zeroed the Z axis in the root of the first thread and moved it by MDI to Z -190mm and then wound in the X and again it was exactly in the root so I have to conclude it was spot on.
Hood
-
Art,
They feedrates were were all the same for every pass associated with a thread run. 40 passes with a listing of 4
or five per pass all the same.
RICH
-
Hood,
It is interesting, and you need to remember that this is three computers, before with the Dell and the Sherline i never got good threading past say 1" with the SS, then you have a borrowed computer and my new one. Now i just got a replacement opto so i can do index and timing now if i want. But the tests we just did with a friends equipment kind of rules the pulse out. His instrument can actualy pick up the difference in a timing belt timing riding up in the timing pulleys or not seating properly, but, that is "very small" contributor to rpm or feedrate varience to the "lathe system". He can also identify the effect it has on an encoder. You can actualy measure the effect of say not using an idler on the belt. We didn't do all that but he knows his "stuiff" and has folled with his owne setup.
There are four of us here that all see the same effect of the threading, granted, i'm somewhat different in the sense that i am trying to put data against it.
You would certainly see and can measure the effect on a long thread of 200mm / 4" . If a single point tool is used
the pitch diameter would decrease, the nut would become loose, and you would see the difference in outside diameter also / tapering in.
If you use a tool / chaser insert the lead will be more constant per grouping of threads, but, the lead would also decrease overall. Likewise on the outside diamter, if your using one of those inserts which shaves the thread OD as it cuts the v , you would not visualy see it as compared to a single pointed tool.
There is a big difference as i think you are using servos and encoders with your lathe. I am not putting my pulse into the SS board, but rather into the PP. Not sure what you have there in terms of a PLC and what it's doing.
So the "lathe systems" are quite different.
The code is generated by the threading wizard.
I like to have the M1076 .MIS generate the code as G32 since i can relate to a pass number what i see visualy as threading progresses. Very small passes .0001" cuts and a lot of them ( 40 ) as i figure if something is going to get screwy over time it will happen over that manny passes and most folks won't do that manny in practice. The depth then is limited to .004" which saves time. The angle is set to 30 degrees so it radial cutting / no z offsets occuring. That reduces the trigger/acceleration/feedrate to the equivilant of a commanded move to point as you did.
G01 Z-1.0 F1.0 equivilant to G32 Z-1.0 F1.0 ( it just adds the triggering ) but in terms of distance actauly moved there should be none fom a common start point. It's also a good comparitive test to do if your going to try picking up a thread.The rpm used is always the same ( ie; DRO says 402 i use 402, if you use something higher like 404, if that was a high seen in the diagnostics, i still use the DRO as didn't see any change in the resulting scribe lines. That's the logic i have used.
RICH
-
Here is a typical code and the inputs to wizard. The only change would be rpm if lower or higher.
RICH
-
Rich, its certainly a strange one.
I use a carbide insert cutter but it is just a single point.
Index is now from the encoder and through the SS differential input on port 3 with a servo motor on the spindle.
Previously on the PP I used an opto and slotted disc and motor was induction via gearbox.As can be seen here http://www.machsupport.com/forum/index.php/topic,8040.msg52277.html#msg52277 in these pics I posted a long while back the threads were perfect, two were done with SS and 2 with PP.
So I can safely say I have never had the pitch error with either PP or SS and that is what is puzzling me.
Spindle sensor seems to be out of the equation, firstly by your friends measurements but more importantly is your errorfile results show Mach is seeing it correctly.
I have always had servos on the axis so possibly there could be some issue with steppers but what?
I thread in metric, could that have anything to do with it I wonder.
Hood
-
Hood:
Good question.. I wonder if metric has anythign to do with it. Ill search the code to see if Im clipping to 4 decimals or something, that may explain a mm difference.. ( I dont think thats th ecase though).
Art
-
ART,
Here is a velocity report.
RICH
-
yeah..not muvh difference.. a .197rpm difference overall and only in 2 spots..
Pretty tight.
Art
-
ART and Hood,
I realy don't know. Can certainly use Hoods as "standard" and like you said it's been around a long time, has proven good results are possible.
I have only been at the threading for say a 1 1/2 years. What stupid thing ( the rat where it is ) is the problem?
I am sure we will laugh about it someday, but in the mean time "search and destroy"!
RICH
-
Rich:
Im starting to think its no so much of a rat , rather a problem of numbers. The random runout is looking liek an intermittant missing index pulse to me. That woudl explain it best, but we'll know if we can catch the random
bad pitch problem, if the feedrate velocity near doubles, it will indicate the spindle went to double RPM for one instant. And that just happened to be when the trajectory was planned.
Normally, if you miss a random index pulse, youd never notice, the DRO's arent fast enough to actually show it to you, the scope would if it happened to happen during scope run, ( the advanced planners scope can grab the index pulse repeatedly for up to 4000 pulses , if any of them are double timed.. thats a missing pulse.). Anyway, that random missed pulse would double the pitch.. if averaging was off, if averaging is on and we had 100RPM for 7 of the averages.. then a 50 was seen( missing pulse..), then the average would be (7*100)+50)/8 or 93.76..so the
"random" weird advance would be advanced by 6.2% on that pass.
That seems earily close to what that random runout looked like.. at 115rpm, thats 107.8 it would see for that pass
or 6.2%.. holds across rpm's due to the averaging.. Gotta think about that..
Art
-
ART,
Just some more testing.
These three tests were run with VER .028 / posted version 54 - reply #539 with PP.
Testing was to look for a missing index pulse and relate when it happens and is it repeatable.
Full threading of the piece 1/4 - 20unc @ 404 RPM
TEST #1 - 40 PASSES - Pass # 23, 33 and 40 were bad! In fact #40 broke the piece.
I din't have the end supported so thought that maybe a screwy lead happened and
caught the end of it. So did another pass, very rigidly supported, and wondered if the
lead would change at about the same pass.
TEST#2 - 40 PASSES - Pass # 21, 24, 28 and 32 were bad and stopped it at pass 33.
By bad, i mean a visual change in the lead and thus a heavy cut.
TEST#3 - 18 PASSES - I figured that since all the other passes got screwy at above 21 passes
time / repeatitions, then i will change the threading code to fewer passes.
18 PASSES @ .010" first pass and remaining at .005", no spring passes.
Pass #9,10,12,14 were bad and the 18th pass cleaned up the thread and there was
a .010" lead increase / inch.
Attached are the velocity reports for the three tests. Spindle slow down is not a problem as the
lathe will just break or bend something and dosn't slow down. Maybe you can make something
more of the velocity tests by looking at the bad passes i noted for each test. It was interesting to
see a possible pattern happenng atapprox 22, 32, and 40 pass and the roughly 1/2 of that for pass
when the number of pass was changed.
I have attached a pic of the thread with some notes on it. It shows the change in lead at what i think
werethe passes. At 100x you can actualy see the small stepping of the cutting on the backside
flank per pass.So for the first 20 passes there is a rather even tappering.
If the lahe was a punny one like my Sherline, the RPMs would have dropped and you realy couldn't
get what i am finding.
RICH
-
Rich:
Now thats interesting data!!!. In the report, you can ignore all the ones with vel:40.5 , thats just the program loading up.. Your passes are obvious
when it shows the Pass number due to your comments in the code.
SO we get..
Fri - 01:53:03 ---Decrement = 0.005 pass 14
Fri - 01:53:05 --- Threading pass: Vel: 0.3367
Fri - 01:53:05 --- Threading pass: Vel: 0.3367
Fri - 01:53:06 --- Threading pass: Vel: 0.3375
Fri - 01:53:10 --- Threading pass: Vel: 0.3358
Thatys one of your "bad" passes. Some of the other bad passes show only the variation of .3367 to .3375.
So lets crunch that a bit..
As feedrates go, that per second, so the bad run could be considered..
Fri - 01:53:03 ---Decrement = 0.005 pass 14
Fri - 01:53:05 --- Threading pass: Vel: 0.3367 thats feedrate 20.202
Fri - 01:53:05 --- Threading pass: Vel: 0.3367 feedrate 20.202
Fri - 01:53:06 --- Threading pass: Vel: 0.3375 feedrate 20.25
Fri - 01:53:10 --- Threading pass: Vel: 0.3358 feedrate 20.148
Now thats the highest variation I see in the reports. So we need to divide by the
spindle speed to get the pitch you requested. So 20.202 / 404 = .050000 ( middle case )
and 20.25 / 404 = .050123 ( higest pitch called) , and finally 20.148 / 404 = .04987 ( lowest pitch called for.)
So your numbers seem to indicate that when we consider the spindle speed, and the feedrate calcuated from it,
the pitch varies from a low of .04987 to a high of .050123 or a variance of .000253 in terms of pitch.
Since a 1/4 20 thread is .05000 pitch , we have a pretty tight planning being done according to these numbers.
Seems to be less than 0.5% variation.. all threads , even the bad ones should have been good according to these numbers.
At most you should have seen less than .000253 difference from thread to thread. Tells me that the RPM is NOT the problem,
nor is the feedrate calculated for the pass.
I need to think about this for a bit to see what to test next. This shows an almost perfect reading of RPM, as well as
perfect control of feedrate to match the read RPM. That variance must have meant the feedrate was solid ... hmm..lets calc that
while we're crunching. You planned for .050000 as a feedrate, it varies only due to rpm readings, so we can multiply it out
to see what rpm you were reading on each of the three pass speeds we are getting. Code assumed 404RPM, and what we got was..
perfect reading of 404 would give you .33666666 as a velocity. ( 20.2 / 404 = .05 pitch @ 20.2 / 60 = .336666666....)
.3358 * 60 = 20.148 = 405.04RPM
.3367 * 60 = 20.202 = 404.04RPM
.3375 * 60 = 20.205 = 403.0 RPM
So at most 2RPM was floating. How accurate that was can be measured as a function of the end pitch results, which seem to
be very close, thus the measured RPM must be very close indeed.
So all in all, Id have to say what we're seeing is just and proper. Youve disproved any problem caused by RPM measurement,
or trajectory speed calculations. This pretty much verifies all of Mach3's code with the exception of the driver itself in terms of
created the crazy result moves that have occured with the very weird high advancing leads on some passes.
This may explain why the SS seems to be found to be very tight, it has no PP driver, and results seem good, so it
all makes great sense when you think about it. While its true the SS and Mach3 both may have a sligth advance or a slight
decrease in pitch from nominal, thatr I think may be the result of the planners conception of time, asnd probably something
that can be corrected.
SO its my feeling we're left with "What is it that causes the crazy moves intermittantly?" This is what Id like
to focus on I think. And its where we have to go to see what it may be thats causing the trouble. And this means its
going to get complex from here on. :-) ( As if its been easy so far..)
If we can eliminate the crazy leads, then we'll only be left with making the pitch itself as close as we can get it.
We only have the reports of what the RPM was at the start of each thread.. this doesnt tell us if indeed the RPM slowed
signifigantly DURING any thread. We have the corrrection turned off at this point, so if the spindle slowed during any pass,
the pitch would give us a "crazy" move indication as the pitch would be way off. It would lead signifigantly for that pass.
Although it may start OK, as it slows the thread pitch would advance as the feedrate would not at the moment slow down to
match the spindle.
Im thinking it best to perhaps monitor the spindle rpm during the thread. This woudl create too much debug traffic,
so perhaps I can code up somethign that records the upper and lower limits of RPM seen during each pass. that may help
us better identify the culprit of the crazy passes. Im betting the warmer the spindle the less often this bug hits us,
as I think it may be related to the VFD's correction mechanisms as it slows down or speeds up the spindle to match its own
window of tolerance on the spindle rpm. (But I could be wrong..).
Ill dwell on this for a day or two and coime up with something to feed us more data, so far youve disproved almost
any application side reason for varying pitches, as everything is pretty much as close as I think anythign could be.
Comment on anythign you think I may be missing or screwing up here.. :)
Thx
art
-
Rich :
One other comment on this.. You said you stopped the thread test on pass #33 on one test,, I think this is it..
ri - 00:48:49 ---Decrement = 0.002 pass 33
Fri - 00:48:50 --- Threading pass: Vel: 0.3367
Fri - 00:48:51 --- Threading pass: Vel: 0.3367
Fri - 00:48:51 --- Threading pass: Vel: 0.3367
Fri - 00:48:55 --- Threading pass: Vel: 0.2217
Fri - 00:48:55 ---Decrement = 0.002 pass 34
Fri - 00:48:57 --- Threading pass: Vel: 0.1033
Fri - 00:48:59 --- Threading pass: Vel: 0.0308
Fri - 00:48:59 --- Threading pass: Vel: 0.0100
Look like the G32 motions to approach the start of thread were OK, but the start of pass 33 shows .2217.. which is a spindle slowing way down, followingmotion shows it stopping.. Am I right to assume you killed the spindle poer at that point ? Looks that way.. :) , as if the spindle was slowing as you attempted to terminate the run.
Art
-
ART,
When i say i killed the program, what i have done is flip a switch which disables the drives and stops all switching activity. The drive will continue recieving inputs from the PP but nothing will be sent to the steppers. That switch also kills the power for the Hall trigger. Then i stop the program. So Mach will continue running the program and show that the rpm drops off. That's why you see the velocity taper off in the data. The switch was flipped sometime after the thread pass but before it started the next threading cycle.
RICH
-
Rich:
Great. Just wanted to know I was reading the data properly, that makes perfect sense.
Art
-
Rich:
In case you do any further checks, hers a version that report only on actual passes, and shows req. pitch and actual pitch as well as feedrate for each threading motion.
Art
-
ART,
Thanks for the info as now i know how to interpret the data better.
I delibrately increased the rpm in the wizard becuase you could see the rpm float in the threading diagnostics.
Yep, focus on the crazy passes. They are the killers, since on a punny lathe you could "spiral down into the black hole" and the resulting thread becomes hard to measure.
If the lead error can only be corrected within some tolerance, then a decreasing thread may be a better choice.
This way it starts out meeting some standard. The nut will go on and becomes loose. I will to post something practical as an example and think about it more.
Will try few with the last posting. That gives flavor to the tests i did were i varied the pitch some to get the lead error to zero.
BY the way, those crazycuts are really bad. ie; all of a sudden you go from just a a few tho cut to cutting
cutting .030" to .040" deep / full V cut. The force on a 1/4" dia rod is realy great including the carriage also.
If the material was hard you would probably break the insert.
Again thanks for stayng with this,
RICH
-
Rich:
Thanks, we'll see what the numbers show. Ill add soem code , hopefully tomorrow, to see about monitoring the high and low rpm during the thread run.
Im coming to the conclusion the actual rpmis slowing during the cut, and we're simply not correcting for it. Im not sure why it only slows on some passes, not others
but Im getting convinced its slowing enough to make the pitch elongate. Its possible simply turning on correction may solve it, but Id like to see the numbers prove its happening.
Art
-
Art,
If I read the debug correctly it is 4 rpm measurments or 4 full rotations before each pass starts. If these rpm measurments differ, what rpm is the motion planned for? The last rpm measurment or an average of the 4 rpm measurments?
-
Hi:
Actually, you get only one report per move. The reason there are four entries is the approach moves or any other G1 motion after an initial G32.
For example, if you use a g32 move to approach the start of thread, then do athread, then retract with a g1, that would be three entries in the log.
Art
-
ART,
Not sure what you posted on page page 56 reply 559 is valid report. Here is the readout i get from dry run.
RICH
-
Rich:
Ooops..my bad.. Ill fix that up..
Art
-
Rich:
Its assuming the S word has been commanded. Is it possibel since your manual that the S speed is set to 0? That woudl make it read #.inf
Thx
Art
-
ART,
All tests V.028 per posted MachSpindleOct16 on page 55 - reply 559.
--------------------
Test #1 was out of curiosity doing a thread test at 404 rpm using the following code:
M98 P0001 L20
M30
O0001
G32 Z-1.9 F.1
G4 P2
G01 X.1
G01 Z0.0
G01 X0.0
G4 P2
M99
M30
So i just did 20 looped passes. Pass #6 and #17 were bad, and the lead increse was .003" / inch.
--------------------
Test #2 used code from the wizard.
404rpm/ .1P / 20 passes@.0002"
Pass #14,19 & 20 were visualy observed as bad. I have attached a file which icludes the report for test #2 and test #3.The first pass had a decrease in lead of .0008" /1" and .001" / 1.4" inch. Then there was a correction after pass#1 and pass #14, 19, & 20 were bad visualy and changed the lead to a increase, namely .0035" / inch.
Picture TEST#2 shows the passes at 1.4" along the scribing.
----------------------
Test #3 was the same as test #2.....EXCEPT..... I decided to try correctng the pitch and see what would happen.
So instead of a .1P , the modified pitch used was 0.09965 ..... (0.1000 - .00035=.09965 ). So the first 13 passes
showed a decreased lead of 0.001". Pass #14, 19, & 20 were bad and cause an increase in pitch.
This is shown in picture TEST#3.
Picture TEST#3MAG shows a maginfied view at the 1" point of scribing.
---------------------
SO three different tests and all had a common .0035" total "range" of lead error. I could shift the location of the error relative to a perfect pitch. Note also that each test had a screwy pass all occuring at around pass #14 or #19 or so. Those screwy passes al seem rather close to what happened n other tests. In the other test that went to 40 passes they seem to occur around pass #15,30,and near 40.
--------------------
BTW: I did one additional test. I hate to compare apples and oranges.....but for info ......... It was manualy done on my 30 to 40 year old Rockwell 11" MANUAL lathe. Pitch was .1 @ 10 passes and the change in lead was 0.0003" in 2" of scribing, no variance between lines, single scribed line. Hmm....
all those old belts and pulleys /gears / gearbox, lead screw, half nuts and 23 times more accurate than my CNC lathe!
RICH
-
Rich:
Numbers seem to still show good. This version will output spindle speeds during the thread as well as what its planned at.
You know, if the spindle actually is slowing down..we have correction turned off, so Id expect a advancing pitch.. Perhaps
after this test its time to turn on the correction..
Art
-
ART,
Will do a few tomorow to get some data.
I don't know about the spindle actualy slowing down.Your cutting air with these tests. The 60 hertz AC is rather highly regulated to the motor. The only thing, motor / pulley / belt / pulley/ belt tensioner / gears as a "system " may change but it would be repetative in one revolution. What ever that varience, would be quite small and the sensor if acting repetatively, probably wouldn't pick it up. Or with my driends instrument, you know your measuring the system, but have no clue as to which component .
What bugs me is the occurance of the screwy passes. They "seem" to be patterned somewhat. If 40 passes are done, then keep your eyes around pass 15-20 to get a bad and then 30 and finaly towards the last 38-40.
So it's in terms of threading cycles 20-10-10. Reduce the passes to 20 and it looks like 10-5-5. The real bitch is you can't "see" it by dry running.
I didn't try it opticaly. I need that G4 pause in there to take a measurment. Need to play with that some as that would allow a lot of testing and save a lot of time. Figured i could do the subroutine, put a dwell in to mimic the time, and see if i can catch bad passes. That was part of test #1, since at one time, you couldn't put a G4 into a threading cycle.
My question is, using that subroutine, is it an apple and not an orange relative to doing the scribing via code out of the wizard?
RICH
-
Rich:
In theory, the code should do the same out of wizard or G32 coding. Should be no difference.
The numbers are telling a story, and your next test of rpm during thread will be interesting. My problem is envisioning where the driver coudl possibly make a screwy pass. Its a bit banger at a steady frequency, so it shoudl be impossible since correction is turned off to make a screwy pass. Only a slowing or speeding up soindle could explain it to me.. I guess well have to calculate just how much a speed up or slowdown must ba happening. Its either the spindle RPM OR the actual output slowing since we KNOW the planning is correct via your numbers from all the tests. We're zeroing in on the crazy passes, but Im having trouble envisioning how it can happen.. so far anyway.
After the next series of testing Ill turn on the correction and see what effect that has.. Im a bit stumped..but thats typical till you get to the Ahha moment in these types of things. :)
Art
-
ART,
Three tests for your review. All tests are identical and reports attached for
each. All done with posted version from page 57- reply 568.
402 rpm @ 20 passes / .1p
Note that test #3 was stopped after pass #9.
Test#1
It was the last two passes that did a heavy cut and i just assumed it was 19 shown in the TEST#1 PIC.That was done wth the unaided eye. I KNEW THaT PASS #8 OR 9 WAS BAD AND THEN 10,11,12,13,14,15,16 AS A GROUP SEEMED OK. BUT THEN 17 & 18 WERE BAD. ( MAY BE OFF IN MY COUNT OF PASSES BUT THAT'S MY NOTES ).
TEST#2
Ths one was monitored under the microsope.
Pass 1 to 8 - looked right on as group
Pass 9 was bad and moved the lead to an increase over 1-8 scribe. As a group 10,11,12,13,14,15 followed in pass 9 scribe.
Pass 16 decreased the lead from from 9-15 scibedline.
Pass #17 inceased / moved the lead back to pass #9
Pass 18 and 19 moved the lead.
SO it oscilated back and forth ( i believe that is what happened in test #1 also ) All within the .0035" total lead error / two scribed lines.
I show all the above summarized in TEST#2 pic.
TEST#3
I figured i would try and catch the bad pass by itself and it looked like
#9.......Could be wrong. No pic but i d have an error report.
Under 40x and a side view you can barely see the .001" deep marks.
--------
I didn;t have a chance to compare the above visual descriptions to the reports but they should be close.
RICH
-
ART,
TEST #3 ATTACHED
RICH
-
Rich:
When you take a microscope shot like that, how far into the thread is it?
Art
-
ART,
Your only looking at 0.002" total depth. The lighting when taking the picture can skew the actual outline.
I am going to post another / revised picture for test # 2 with some info to refine the information. I think it's important.
Should take about 15 minutes.
RICH
-
ART,
This picture better shows what was actualy seen. The shift is more logical based on the report ( 8 & 9 ) pass.
I don't understand why #10 to 16 stayed on this side but they did. The report dosn't account for what actualy happened.Now 18 seems logical as it would be deeper and was on that side. Pass #17, 19 &20 are somewhere on the other side, not necessarily as shown ( that's my guess) since all i could see was that they shifted over to that side.
The only way i can take a better shot of the marks would be at 100X and would probably need to cut into the tube and look at a cross section or get my other microscope working.
BTW: Chucked up about 10 lbs of weight to load down the spindle some and ran some dry runs. Yes , the rpm dropped from
402 to 401, but there was no change in the in the error report. Just figured that maybe adding mass to the rotating spindle / inertia would make a difference.
RICH
-
Hi Rich:
My bad.. I meant how far into the thread ( as in 2" from start..1" from start..ect.. ). I was wondering if it went further and further out.. or if it is the same amount out 10 pitches in as it is 5 pitches in..
Art
-
ART,
Progressively decreasing. For TEST#2 at the 1"/ 10 pitches 1line (#18) @ -.0018" and the other line at - .0048".
At 1.5" / 15 pitches #18 @ - .002" an the other @ -.007"
RICH
-
Rich:
OK, begs the question.. if you do a .2pitch , does it scale or does it stay the same runout as a .1 pitch..
Art
-
ART,
Will try one out. You don't know what you have when you get multiple scribe lines.
RICH
-
ART,
115 RPM / .2P / 20 PASSES 0.002" DATA REPORT ATTACHED
- SINGLE SCRIBED LINE / no screwy passes, CONSISTANT DECREASE IN PITCH ALONG THREAD
- @1" (-) .0038"
- @1.5" (-) .0063"
- @1.8" (-) .0072"
Now were do you want to go? I can change kernal speeds and try .2 at 402 rpm.
RICH
-
Rich:
So am I right is saying that .1 and .2 pitch look much the same as var as hgow far out they are? Be interesting
to see .3 or .4 .. just for eliimation.
Art
-
ART,
Yep, looks that way.
402 RPM / .2P / 20 PASSES 0.002" / DATA REPORT ATTACHED / kernal speed increased to 45k
- SINGLE SCRIBED LINE / no screwy passes, CONSISTANT DECREASE IN PITCH ALONG THREAD
- @1.5" (-) .0043"
Just for you i will do a long one. The bathroom still has some plumbing left in it!
Will do two at 402 rpm, one at .1p and the other at .2p , since i can do them from the same starting point on one piece.
RICH
-
ART,
Two more tests as follows all decreasing in pitch. Distances are from the start point.
RPM SCRIBE PITCH 1" DIST 2" DIST 3" DIST 3.4" DIST
------- --------- ---------- ------------- ------------ ------------ --------------
115 1 / SINGLE .1 (-) .001 (-) .0032 (-) .0038"
402 2 .2 (-).0018 (-) .0046 (-) .0078" (-) .0089"
DATA REPORTS ATTACHED
RICH
MODIFIED: ADD PICTURES
-
Rich:
So it does seem to scale roughly linearly, but to pitch, not so much to RPM.. which makes sense based on what youve seen.
I need to crunch some of those numbers to see if they point to any magic number. Ill get back to you later today with results.
Art
-
ART,
Sure seems that way. I quess the only thing you can can do is pick some guideline and then test it out.
For multiple scribed lines i just use the middle as a reference unless i can identify which is which and can relate the difference. ie; different leads but within a tolerance.
What is puzzling is the screwy passes. It seems the data will identify one of them but not provide reason for the
the ones following, it kind of settles out. If it's not the machine or the threading programing, then what is interfering........may just be a Windows thing. Discussed this with Chip and also a friend.....
sort of like that old camera commercial "it has mind of it's owne, you can try to take control, but it will still does what it wants". I will try a few simple things to see the effect ......later. For now i want to stay focused on the data
and whatever you need to make intelligent changes.
Just remember "crap in crap out"........... :D
RICH
-
ART,
How goes the number crunching?
RICH
-
Rich:
What I was concentrating on was the problem of syncronicity. Since the real world is not triggered
digitally as the cpu is, I was concerned that it may be the case of the index pulse being sensed 1 step
early or late depoending on timing and if this migth be the crazy run problem.
Since your numbers all show pretty much no aberation in the program itself, and the driver has no clue
about timing other than it knows to run at kernal frequency, all I could see is triggering.
That however, can IMO, only affect the thread run by 1 step of the pulse train, advancing it or delaying it
by one step. What is the step resolution on your machine. How many steps/inch is it set to. ( Just out of
curiosity, because I dont think your set so coarse that a single step would put you .003 off from target on those runs,
youd have to be at only 330 steps/inch.. I suspect your set to 2000 or so..
In any event, youd have to miss the trigger by 6 steps for that to occur, and that woudl make the entry look bad by that amount.
Am I right in assuming the entry alwasys seems to look good on the crazy passes, but the only thing you notice is the thread
pitch is off, that it gets longer by a set amount and gets more out of position the longer the thread?
If so, then we can only have a feedrate that is moving too fast for that pass. But given that the debug monitoring seems to show
no aberation that can explain that pass, Im left with thinking the kernal frequency must be speeding up for that pass ( or slowing if
the crazy pitch is retarded to the requested, but it seems your crazy pitches are advanced to the req. pitch. ( Am I right in assuming that
as well? ).
Si Im left with the impossible, the RPM varies only by 1RPM at most on your system, bad passes dont report any more than that, and good passes also report 1RPM variation. But 1RPM wont explain it. Weve proved that as the 400rpm tests work similarly to a 115 RPM run, but if
you call for .2 pitch, your not quite double what a .1 pitch does, but there does appear to be an error that grows as the pitch grows.
We may be too small in pitch to tell though. How high a pitch can you get on your system? Can you do .5" at 115RPM? 1Inch pitch?
The gross changes evident from .1 to 1" pitch may be more revealing, but at the moment the numbers appear to be noisy more than actually showing a direction. A .003 pitch decrease over an inch doesnt bother me too much and I can see thats just about at the correctable point,
but Im stumped as to exactly where its coming from. A 1" pitch may show us somethign we hadnt considered if you an do it.
Art
-
Rich:
Just as a following up. I rechecked your error passes.
We can see that the RPM was seen to change by 1RPM from 400 to 401. The feedrate changed
as a result from 40IPM to 401.RPM. Thats the only difference and its not alwasy there so
I was discountiung it. Heres why..
40IPM at 400RPM.. is .666666 inches per second at 400RPM ( 6.666666 revsper second ) so a pitch of .1 exactly..
40.1IPM at 401RPM is .6683333 inches per second at 401RPM ( 6.683333 ) so a pitch of exacltly .1 again..
These numbers are as near perfect as one could hope for. NOW lets assuem the RPM WAS holding at 400, and not
really getting to 401RPM.. ( Ive noticed we have a granularity of 1.0 for RPM, Im going to see why that is, we should
have fractional RPM's really, so why is RPM always .000 after the decimal. )
But before that lest figure out what happens if the RPM was simply wrong at 401, and we were still running at 400.
The difference between 400 and 401 is the diff between 6.66666 and 6.683333 so .016673 inches per second. with
6.66666 revs per second, so the error woudl be .016673 / 6.6666 = .0025Inches per rev. ( Sounds familiar dont it.).
SO Im suspecting now the RPM , always dropping the decimal fraction may explain the lead/advance errors your seeing.
Ill look now to see why the RPM is always an integer, if I fix that we should see a tighter fit to the pitch. None of this
explains the crazy passes.. but lets see what fractional RPM does.. it shoudl fix the .0025 error ..
Art
-
Rich:
Sorry to flood you, but crunching has shown me the error may simply be the integer nature of the rpm whcih should almost always have fractions
to it. SO heres a version that should show an RPM of 400.712536753261 or similar..
Let me know if it indeed does so, if Not, Ill have to rehook my spindle sensor ( disconnect for some shop work... ) and test further. I think we're
onto why the .0025 or .003 error. If this works as I hope, that shoudl now be much closer..
Art
( I found more integers , so I resent this message with an updated code base..)
-
I have lost some of the information here since long. If I remember correctly the RPM measurement is done before each pass but only ONE RPM is measured. In order to minimize the trigger deviation, if there is any, could it be an idea to measure the time of say 5 full revolutions and divide that time by 5 to get the RPM as accurate as possible?
-
Hi Steiner:
Actually, if averaging is turned on, its averaged over 8 rev's..
Art
-
ART,
?- How many steps/inch is it set to.
X is 12700 Z is 20300
Out of curiosity i did a G01 @ F.01 for an .1 travel of the Z a few days ago.
While reading a book, was just like a Swiss watch listening to the stepper pulse, tic , tic , tic,
never missed a beat.
?- Am I right in assuming the entry alwasys seems to look good on the crazy passes, but the
only thing you notice is the thread pitch is off, that it gets longer by a set amount and gets more
out of position the longer the thread?
Yes. As far as i can tell @ 30x mag. Since your almost cutting air, ie; the scribe line is realy fine,
but i would see if it changed by over .001".
?-seems your crazy pitches are advanced to the req. pitch
Yes, even when / if it oscilates, ie; it stays within say a range of .0035", may be multiple scibes
as i had shown in one of the replies.
?- you call for .2 pitch, your not quite double what a .1 pitch does
True, it is not linear along the thread, so if you take the longest length, then the error / " is different
than if you used the 1" mark. A single scribed line provides a definit measuring point. When you
have two of them, then you don't know which to use as one has a different error than the other,
small but different. SO you can play with the mean square root of those readings, but the average
measured between them is what i posted. I would suggest you stay with the single scibed line
numbers and it is ususlay around .0035"/ inch as that has accured so frequently.
?- Can you do .5" at 115RPM? 1Inch pitch?
Hmm... using 115 rpm 0.2P=23 ipm
0.5P=57.5 ipm
0.8=91 ipm
1.0=115 ipm (nope start skipping at 110 or so)
?- We may be too small in pitch to tell though.
Yep, only have a rather narrow range of data from tests.
I guess it would be nice to have data for the following:
RPM PITCHES
------- ---------------
100 .O125
200 .050
400 .1
800 .2
1600 .4
Thats 25 samples, and then should do at least 2 runs, which becomes 50 samples.
I can't thread for that full range .
I believe the lead can be corrected or brought into some range, but again, i would go back to a
standard to quantify just what that error tolerance means.
Good to 0.8 P. I am limited to directly measuring the lead with the tool makers microscope to
2" before i need to move the piece and start from another reference point.
So i introduce some error in lead the measurement when that is done.
As far as the screwy moves:
I want to try something, namely using Chips screen which has a large path display, also fool
around some while threading and monitoring Windows / MACH CPU usage. Basicaly i want to see
if getting more attention to it may have an effect on those crazy moves. Nothing ventured nothing
gained.
Comment on your post #589
That would agree with me changing the pitch in the wizard from say .1 to .99****************** or .100*********.
The rpm was fixed but the wizard did in fact create code with that pitch , even though while in the
wizard it will round the number. The resulting thread lead error was reduced but still influenced by
the RPM change of 1.
I'll run the OCT22-1 version.
Need to do a few things, so back in a few hours.
RICH
-
Just a thought, trust that from a programing point of view, I am just plain stupid.
But, what if for a split second Windows was to divert and then the data would be recieved by Mach a little late,
and it continues and that causes a screwy move, because of Windows?
Or how about Mach not implementing a correction unless it's seen twice?
I am getting a little off track, but want to be open minded on the screwy moves.
RICH
-
Rich:
At the moment we have no correction, so that cant be it.. and if Windows was interupted then the pitch woudlnt start properly I think..
The more I crunch the numbers the more I think its the integer RPM.. Oct22-1 will be interesting..
Art
-
ART,
:) :) :) :) :) :) :) :) :) :) :)
Now this is good news!
Tests all done with Ver.028 - OCT22-1 as shown below:
20 passes @.0002" / pass
Spindle Speed Averaging / Constant Velocity / Debounce Interval=600
Index Debounce=10 Z=60 IPM @ 6 accel / X =80 IPM @ 8 accel
RPM PITCH LEAD ERROR AT LENGTH ( +=INCREASE -=DECREASE)
0.5" 1" 1.7" REMARKS
---- ----- ----- ------ ------ -------------------------
116 .1 N.A. -0.0008 -0.0008
402 .1 N.A. -0.0007 -0.0011
116 .5 +0.0000 /.0014" +.0.0005 / 0.0014 Just measured at two different places abt 180 degrees apart AT 1/2" and 1" lengths.
Attached are the data reports for each.
From a practical point,if actual threading was done and you could hold the diameter and cutting was good, then based on the lead errors above,you would produce a Class 3A thread.
There was a little of the "oscilating" seen but I think what i was realy seeing was backlash. The Z has 0.0008" and the X has 0.0003".
One of the things that come to mind is the acceleration and deceleration.
What i saw was the "oscilating" starting to occur at about 2 threads short of the end of the thread and after 10 thread cycles. Could be wrong. As long as your in these kinds of tolerances who cares!
SO need to have additional testing to see if the above holds true over time.
RICH
-
Hi Rich:
Yes, I was thinking the number crunching was showing too many inferences to the RPM. I'm a bit embarassed
I didnt see it before, the lack of fractional component of the rpm measured seems the pitch culprit.
Im going to turn on correction again after you run your tests, we'll see if that works as it should if you
apply a bit of pressure to the spindle while its turning..
Art
-
ART,
Will just cut some actual threads and see what happens. 1/4-20unc as that one is 0.0433 deep based on a sharp V . Should there be some slowdown and no correction it should show up rather quickly while threading.
In mean time post one with the correction turned on. Then i can compare and comment.
RICH
-
Rich:
Hers a driver that turns correction back on..
Art
-
Thanks ART,
I cut four 1/4-20's, three in AL all were good ( 40 passes) and the cutting. Two of them met Class 2 / 2A external thread.
The fourth was C/S, just took one slow down of 1 rpm ( at around pass #18 ) and no correction and that was it
until it broke. It was not supported in the tail stock and out about 1.25" which is too much. Even if it was supported the thread would have been poor. What happens is that if the lead gets off a little , you will catch the end were it just enters the stock, will deflect the stock, and that's the beginning of the end! I call that lazy operator!
SO lets see what the correction does now.
RICH
MODIFIED: X axis gib was was loose, so that didn't help with 1/4- 20 in steel.
-
Rich:
Great so far then.. Woth no correction required the threads now pass muster. And they should on anyone system then in theory.
Ill keep my fingers crossed for correction..
Art
:)
-
Me t00! And the x axis is fixed. I'll do some threading tomorrow. Time for a nice glass of wine. ;)
RICH
-
ART,
No joy with the correction on!
Attached are the two tests. The AL test errored on the 2 or 3rd pass and i stopped it. The CS ran like a champ for the first 8 passes and then 9 was bad along with 28 and again stopped the threading.
I don't know??????
RICH
-
Hi Rich:
Yes, I suspected as much. The correction code is still based on number of interrupts seen between index pulses, we now know that using PCI bus time is much more accurate, so the pitch is
correct, but I think Im going to have to swap the interrupt based correction code to time based as well, otherwise it may sense a correction when none needs to be done. Id go back to the non-corrected and see if AL threads are generally OK, or material that doesnt slow the spindle.
Ill start work on the correction swap to time based, Im thinking that may solve the issue. Im wondering if the current non-corrected gives us any bad passes, that woudl be a clue thats valuable, if there are no screwups in soft material, then I suyspect the correction is now createing its own "whoops" passes..
Art
-
ART,
"Id go back to the non-corrected and see if AL threads are generally OK"
I did do that in the other post, but will retry just to confirm by doing more passes and a finer thread or something.
Will post something tommorrow.
RICH
-
ART,
The non-corrected seems to be fine. No crazy cuts, lead is fine here are some pictures of a few 1/4- 20 & 40
done at 402 RPM with 20 and 40 passes.
Look forward the time based correction.
RICH
-
Rich:
Wow..Nice threads really.
OK, itll take a coupel days to recode this.. its a slightly complex code in the driver that does corrections, so Ill have to crunch more numbers as I go.
Your tests seem to have proven the weakness of both sides, the correction and the rpm reading. The end result should be much better than it ever was..
Thx
Art
-
"The end result should be much better than it ever was.."
I sure hope so since threading should be a fun kind of thing.
Of course i know your having fun! ;D
Rich
-
Hi Rich:
Report from John Stevenson on the test he did today..
>>>Ran a 1.5mm pitch thread for 50 mm, after 3 passes it was way off so
bailed out.
Did what Rich said and switch averaging off and re ran the thread.
All passes looked to be dead nuts on, bit of double thread at the end
from the first 3 passes spoilt it a bit, quick clean up with
scotchbrite and checked against a 1.5mm tap and it's the best thread I
have done to present. Very slight pitch error over the 50mm, probably
1/4 pitch out at the end.
This is the most promising long thread that I have done to present,
aim to tune in to read 600 better but not certain how critical this
is.
>>>
As you can see he had to switch off averagiung, where you need it on. Ntot sure what that means yet, but it seems both of you are getting better threads than
ever before.
Im thinking if averaging kills the thread, then the RPM must be wavering more than normal OR that the new code has changed it so that averaging doesnt help,
and non-averaging may be better.. Not sure yet..
Anyway, couple days for new code I think..
Thx
Art
,
-
Art,
Does it all have any effect on the Smooth Stepper? My threads with the Smooth Stepper seem all to be perfect, but then I have never run such long threads and never subjected them to the kind of tests Rich does.
Thanks,
Daniel
-
Daniel:
If averaging is on, then the SS is affected, if off, no effect.
Art
-
Thanks Art. I don't use averaging ever since I've put an AC servo on my spindle and use its encoder index for speed reading - displays the speed rock solid.
Daniel
-
ART,
Well, first let me say that I am glad someone else is trying the the threading out.
The M1.5P ( 1.5x.0394=.0591" ) is close to the 20TPI i was running. Additionaly you get some
other uneven numbers in there like .xx91 for a pitch value. And we know that a small difference in
the defined pitch will change lead.
A nice new tap is a good compare against the thread as they are ground very accurately. I will
assume it was a ground tap. Most of mine are for H2, which simply means the diameter on it is held to
provide a tolerance of 0.001" over the basic pitch diameter.
Almost all of my threading has been done with averaging on
If averaging is on then all the rpm reported would be averaged and that is the value that would be
used for the NEXT thread pass. Correct?
If averaging was off then assume that the last reported...Or.... is it the requested used?
Unconfuse me.
I have not remarked much on what you see at the end of the thread. ie; single, double / multiple
lines.
I have used the distance in spacing to reaffirm what i thought i observed during the threading. (ie; a
later pass increases the thread) You would think that the difference between the ending of those
scribes could be used for lead error, or maybe tiiming pulse, rpm....but.... i figured if you have
some runout on the diameter of the piece or a difference of velocity as it pulls out of the thread,
backlash as it changes direction on pullout.....just too many variables to try and make sense of
what that measurement is telling you. SO i just use it as a visual.
I need to remark that no variable speed drive or whatever is used here just a plain good old
fashioned motor.
AVERAGING
If you get a change of speed, a practical example would be while threading and you hit a hard
spot in the metal, or, say you catch material just as the cutter hits the material at the beginning of
the thread, if that value was very influential on the next to last pass, then a good thread
can be ruined if averaging was off . If on, the affect would not be as great. Actualy calculated
forces can easily double.
Now if your in the middle of all the passes, there is recovery, by the additional passes yet to be
done. But then, if it was spring in the material or poor setup, then who knows!
The point is, the mechanical apsects of threading can vary the situation.
Like you, i am not sure what to make of it.
I won't even get into the acceleration and deceleration part of the cycle. I will say that whatever
someone does to test, keep the pullout at the same angle and use a common value like 2 or 3
times the pitch for free cutting before the actual thread is engaged by the cutter.
RICH
-
Daniel,
Can you try out the the threading without compensation and not use the SS?
What is good is that your speed is rock solid. Your an apple and i am an orange ie; my speed will vary a small amount ( like 1000 other users out there ).
RICH
-
Rich:
When it comes to averaging.. Mach3 can keep a running average of the last 8 revolutions. At the start of any pass it either uses the averave OR the last measured time.
So in theory, hitting any hard spot has no effect on the actual planned pitch for the thread, the idea is simply to be as accurate as possible as to what the unloaded speed is, and since
every thread starts with an unloaded spindle, the 8 rev average is typically unloaded average. ( unless your turnign very slowly on the spindle.. no-one is I think less than 8 turns in the air
prior to a thread pass.
SO the correction code is all that controls speed during the cut to take into account the slowdown caused by hitting a hard spot or an average slowdown due to harder material.
The averaging is discounted for correction, it cares only abou tthe real last index to index time, and it compares that to the locked in average or locked in last rev just prior to the
thread pass starting.
Since your threads, as well as Johns seem to be nuts-on with no correction.... we're good till the last step in the chain..correction.
More of a job than I thought.. be a little whlie yet..
Thx
Art
-
Thanks,
Take your time.
RICH
-
Rich:
Before I rewrite all this, I found some troubleing code in there. Can you confirm this driver does the same bad corrected thread as the last correction driver?
Turns out the driver was clippign the value used.. Im wondering if that clipping was causing the crazy passes when correction was on.
Thx
Art
-
ART,
No problem. Will try it out tomorrow.
RICH
-
ART,
1/4-20 thread 402rpm @ 40 passes.
Bad pass in Al at pass #11 in Al and #5 in CS. I only have the error report for the CS one and is attached.
At least the error correction kicked in at an early stage and I didn't need to stop the threading.
After the CS 5th pass it had a lot of passes to recover such that the final few cleaned up the cutting.
The finished threads have a lead error of 0.050" 0.040"/ inch decrease. That's almost a full thread!
RICH
MODIFIED: Added a picture to make it more interesting. ;)
-
Daniel,
Can you try out the the threading without compensation and not use the SS?
What is good is that your speed is rock solid. Your an apple and i am an orange ie; my speed will vary a small amount ( like 1000 other users out there ).
RICH
Rich,
It is really a hassle for me to to make my lathe run from PP. The spindle servo needs 8096 steps per revolution, so even for a 500RPM speed it would require a 75kHz kernel speed. Can't run my computer at this speed. The only choice is to reconfigure the servo drive to use electronic gearing. But then my steppers take 4000 steps per mm, again requiring a kernel of at least 45kHz to be able to get some normal feedrates.
But if it can help you, I could try it after I finish the work I'm doing now on the lathe. Another thing is I don't have any precise means of measuring my threads, so don't know how much of a help would it be.
Daniel
-
No problem at all Daniel. Fingers went into gear before brain interpreted your reply! :D
RICH
-
Sorry Rich, didn't mean to make it complicated :)
Daniel
-
Rich:
Yup, sounds as if correction badly affects things then. From .003 to .040 is quite a jump. Ill see what I can do this week..
Art
-
Thanks ART,
Look forward to the update. Besides, winter is coming and Ruff Van Winkle "LazyTurn" will be waking up.
RICH
-
Hi Rich:
Didnt want to let you think I had forgotten you. I think Ive figured where the weird passes come from. The pitch is planned before motion, and it uses the speed at time of motion
to correct to.. Im making the application lock the planned pitch speed so that is what is used instead. Be a couple more days while I spit and glue the pieces together. I think this will
help greatly. It should in theory stop the weird passes which I think are occuring due to a slight RPM difference between the planner and whet the locked speed it set to.
Art
-
ART,
I just figured your having fun! Hope it's the culprit.
RICH
-
Hi Rich:
Well, I noted serious flaws in my correction logic as it WAS applied, and this test version is new code based on the time of plannng. I cant test this at the moment as I have too much going
on to fix up my rotation tester, so please try this in the air first to ensure I havent screwed up something basic. Its a lot of new code. It should plan a thread at a set rotation and then use that rotation
speed as the correction algorithms reference speed. It also keeps track of higher speeds to subtract from any correction done in slow speed situations.
Let me know how it tests in the air if you can. You need the enclosed driver and exectuable to try this one.
Thx
Art
-
ART,
Will check it out tomorrow and post.
RICH
-
ART,
No rpm shows in the DRO. The index is sensed in diagnostics. The threading diagnostics will give rotation realtime speed but the spindle rotation is not sensed. Thus can't do any threading.
Axis will jog, step , and MPG's work.
RICH
-
Rich:
Sorry about that. This one should fix that, if not turn off or delete the advanced threading plugin, it may affect the reading by zeroing one of my var's..
Art
-
ART,
I figured you are curious on how latest threading post will do.
I cut a few short threads and they looked very, very good, the cutting was smooth, didn't notice any goofy passes,
no lead error problem, so this is looking DAM good at the moment.
Need to cut some CS and see how it goes. I'll post some data later, want to break it first.
So keep the fingers crossed!
RICH
-
Rich:
You just keep stacking up the beer I owe you! :-)
Art
-
Art,
I finished the job I was doing on my lathe and I am willing to help if I can with the threading tests now. Please let me know if there's anything I can do to help you guys. Don't want to switch to PP though... so anything you think I can test with the SS, let me know. You said averaging was affecting the SS as well, so may be I should try it...?
Daniel
-
Daniel:
I think most of what we've done affects mainly the printer port. Though the RPM is now specific to 4 decimals for planning,
so the SS shoudl do better threads now than before. In the end, if Rich's current tests work, Ill have to work with Greg to
make a slight adjustment to the SS to make the threads a bit more accurate. The SS is known to have pretty good threads in any case, so
its not a huge concern as yet. When the PP is complete, we'll get some SS tests under way to ensure its good all over.
Thx
Art
-
ART,
Take a look at the attached files. Any comments?
RICH
-
ART,
Just some scirbing test info as it's easy to post.
402RPM / 20 PASSES / 0.1, .050, & .025 PITCH
115RPM / 20 PASSES / 0.1, 0.50
The pitch error is for those tests were for practical purposes "0". ie; at 1.5" there may be a slight lead error
of -0.0004 or +0.0002 total.
Will do a few more at different rpm's and pitches to see if any scaling happens,multiple pitch ( should be interesting ), and something for alternate flank ( need to think about that one ). Maybe some real high passes just for kicks.
So don't go breaking it in the meam time! ;)
RICH
-
Rich:
I guess my main comment is that if you arent a professional tester or engineer, you otta be. Great work!, as usual.
I guess we slayed the dragon. My sword, your weapon handling. I have to say of all the debug testing running over 7
years now, I have enjoyed this run most of all simply due to the excellent reports, great testing and solid logic you employ.
I agree with all your comments. They show exactly why certain aberations occur and will be posted in the Docs section when
Brian returns.
I wont claim we have it all done or figured, or that strange things wont happen, but with lack of eveidence to the contrary, Ill consider this solution to be
the one we will use. I now see many of the issues as obvious and am embarrased I missed them all this time, but thats the nature of all tough bugs.
I'll see to it that all is incorporated into the next version of Mach3, and the driver will change to reflect what
we've done.
I'll write up a report for the yahoo group to explain what we've doneas well. I think in future Ill have to call it
"Mach3's Rich Threading Algorithm". :)
Art
-
Thanks for the compliments ART,
Hopefully some practical threading by many users of the version over time will hold true. The testing basicaly implies that if you can't do threads on your lathe, it's not the software part but rather your "Lathe system" along with experience using it.
While you were tweaking the program i was compiling a whole bunch of "stuff" which will be put into the members docs as a tutorial or whatever. The write up attempts to capture the big picture on threading so it covers
a lot of territory. If anything it will be a good first stop for getting a handle on threading on a CNC lathe using MACH3 Turn.
I am just glad that you put the effort into upgrading the threading. The threadings problems are very difficult to put into perspective because they are so interrelated and hard to isolate in a meaningfull way.
BTW, My profession is a process engineering designer and background includes code design of equipment, piping, and whatever. This is fun and the profession is work!
I'll look for your write -up.
RICH
-
First let me say that I don't have a cnc lathe, but I have converted a 9 x 52 mill.
I do have a small lathe that I use so this thread really caught my attention.
What a display of professional cooperation between two individuals. Most of the time I got
the impression that both of you were having too much fun.
I can not begin to tell you how much I have enjoyed this thread!!!!!
Great job Rich, Art, and all the others that have taken part in this, and thank you for
helping me to understand a little more!!
olf20 / Bob
-
Yes I have to agree, it is so refreshing to see the detail Rich went to in his testing and more importantly his documenting, far to often all you get is this doesn't work and thats it. Just goes to show what can be achieved when people are willing to put the time in and to work through something :)
Hood
-
I have to agree. It has been very interesting to follow this thread. The last threading by Rich seems very good. If this is the result then it should probably be possible to make close to professional or industrial quality threads :)
-
I too have been following the ups and downs of this thread with great interest.
I guessed when it started that by the time it was resolved i would be up to speed using Mach3 Turn.
I cant wait for the conclusion so i can begin to understand it all. ;D ;D ;D
So well done Rich & Art and all those that made it work.
Phil
-
Phil,
"Let not your heart be troubled" and "you do not stand alone in the valley of darkenness" :D ;D ;D
But in the mean time.....
RICH
-
"Do not stand alone in the valley of darkness" :D ;D ;D
RICH
No gave up on EMC.
John S.
-
John:
Let us know how your testing goes, I know your test lathe has a low torque issue, and the resuilts of hard steel vs AL will be interesting and show me how well correction is maintaining its
accuracy. The number crunching seems to show we shoudlo be able to expect a good thread even if the spindle slows to less than 25% of the start speed. ( Though how much effect on
the pitch from pitch to pitch woudl be interesting to see.
\
Art
-
>>"you do not stand alone in the valley of darkenness"
Christ, am I in a valley? Its so friggin dark I though I was in a closet. :-)
Art
-
Rich's new avatar.
Brett
-
What can i say....... ;D
RICH
-
Phil,
But in the mean time.....
RICH
Rich i s there something missing all i can see is the index. ???
Phil
-
Phil,
That was just for all to see what would be in the document. A few sections are done but it needs a lot of work.
A lot of material to go through. There are a few "hundred pages" of info that was been posted relative to threading over the last year or so. Many of the posts are not relative. Some of the info has to be tested. So more work than meets the eye. I hope to have a draft done by the end of next week to coincide with a new MACH version release.
Any section in particular that your interested in more so than others?
Anything that you would like to see in the manual?
RICH
-
Any section in particular that your interested in more so than others?
Anything that you would like to see in the manual?
Rich,
Your document seems to cover pretty much everything one could think of. Great job!
The "How to Pick Up a Thread" section sounds very interesting in particular to me.
Daniel
-
Rich
Sorry just got a bit over excited.
But i have now done some threading, i am using a Smooth Stepper so i haven't had any issues that i am aware of.
I did misunderstand some of the info in that when i built the lathe i have two encoders on my spindle one a single slot and one a multi slot so i went a bit over the top there.
So just looking forward to a good read.
Phil
-
Hi All,
I don't know if " THREADING ON THE LATHE - MACH3 TURN " will be a "good read" but
the rough draft shouild be of interest. It's in Members Docs and here is the link:
http://www.machsupport.com/forum/index.php/topic,13017.msg85313.html#msg85313
RICH
-
Oh BTW, should anyone have any interesting stuff, better pics, they want in it or want to add to it, by all means feel free to post. Any general comments welcomed but spelling errors or gramar dosn't count.
RICH
-
Thanks Rich! A very informative and useful document you've put together. I am sure many will find it very helpful.
Daniel
-
Rich:
Amazing Job!! . I think Ill ask Brian and Scott to post that in the regular Docs section ofthe website , its the best Doc Ive seen on threading in particular.
I love those tread photo's in it. (Give me a calm comfort. :-) )
Art
-
Hi Rich
I think many people are going to benefit from all the testing you have done together with your excellent write up. Many thanks for all your hard work.
Peter
-
Thanks All,
Most of the basic content is in the doc but need to get some comments in it. There will be more pictures mostly in the testing part. Those pictures wll delineate what things should and should not look like.
The whole intent of that section will go something like this, for an example:
You followed the instructions on how to pick up a thread, but before actualy trying to do it, run the scribe testing....
as the photo's show, if you don't align the tool correctly in the process you will not scribe the same line.......
on a punney lathe you may just make things worst........the lathe may not be accurate enough to do it.....etc.
ART,
I got all the Yahoo group comments and your report and summarized for what what will happen. I'll post the summary and you can proof read it for accuracy.
RICH
-
Rich:
Sounds good. We have posted even thge preliminary as "Rich's guide to Threading" in the Docs section.We'll update it as it goes, but its too valuable IMO to
let languish on the forum. :) .
Art
-
ART,
Here is the summary for your comment. Based on this, there will be some changes in Mach turn configuration, so the screens currently shown in the threading doc need to redone. I figured i would waite to see what new version brings and then add commentary in the doc.
RICH
Mach version ????
There will be an updated version of Mach released using a completely new threading code versus all the other versions. Users should wait for the threading changes to be initiated since the one posted in the treading tests is experimental and not recommended for general use. The code will only be for a single INDEX .
There are two current basic configurations for threading. Single index ( single slotted disc / halls sensor, etc.) or timing ( multi-slotted disc with index, or electronic equivalent / encoder ). The new version of threading will change the current ‘timing” configuration such that a multi slotted disc with a wider index slot used for timing will no longer be available.
There are two current threading plug-ins. TurnDiags-Turn-Diag-1.00.1 called Turn Diagnostics in the PlugIn Control tab is currently loaded on a Mach installation. The second one, namely ThreadingAdvanced-Threading-1.00.0 was in testing.
The new threading still addresses slow down of the spindle. How well it will hold the threading tolerance has not been tested yet, but ‘may be” in the 10-25% range. You will not be able to completely stop the spindle and recover the threading cycle and prior tests for spindle slow down are no longer applicable.
The “future” Advanced Threading requires update per the new threading code and will allow for a slotted wheel with index or an encoder. When using an encoder additional parameters will need to be defined to MACH. If using an encoder, you’ll have to set the number of quads per rev and should work fine if one considers just how many lines can be seen per rev at top speed of threading used and limits their speed to that as a maximum. The Advanced Threading will not be available until after the updated version of Mach is released.
An encoder can be used for threading, and it IS on the books to allow an encoder geared output of the stream, but that may take longer to appear since rework of the code is first required to get it to a more manageable level of interconnection. As the printer port very slowly goes away, it
becomes a question of what the new hardware guru's can put in their firmware with application support from ArtSoft's side.
I suspect Electronic gearing is now possible, but will require a defined development procedure similar to what we just went through with threading.
-
looks good Rich. I just sent the new code to Brian and its now in the next version of MAch3, should be out soon.
Multi-slot or TIMING input based threading will not be available till the advanced threading plugin is rewritten, but single point
shoudl be as good as what you got. Correction should in theory work for up to a 75% drop in speed during a thread.
Thx
Art
-
Rich,
Nice job on the threading guide. It will clear up a number of things for us. Could you please enable the Printing function for the document. I would like to make a copy to read while traveling but the current version does not allow it to be printed. Thanks - Terry
-
I will allow printing for the next posted rev "B" which is a day or two away.
Darn thing turned out to be a book instead of a few pages.
Now that i think of it..............it's your ink and paper! ;)
RICH
-
Rich,
If I may, can you make the contents linked to the corresponding pages? Do you know how to do this?
Thanks,
Daniel
-
Dan,
Don't remember how. Post the easy way!
RICH
-
An updated version of THREADING ON THE LATHE was posted oin members Docs.
RICH
-
Dan,
Don't remember how. Post the easy way!
RICH
Ha..ha..., don't remember it myself :D Did it only once and it was a few years ago. Will mess around with Microsoft Word a bit and try to recall what was the way to do it.
Daniel
-
Dan,
A little off the intent of the thread, think you create a summary and then just use it in Adobe.
I'll take care of it in the end. Still a lot of work to do for and on it.
RICH
-
An updated version of THREADING ON THE LATHE rev "C" was posted in members Docs.
RICH
-
Hi All,
Just fooling around some and decided to try some multistart threading.
Here is a three start thread. The pitches are equal just couldn't hold the camera
correctly on the scope lens. NEVER was able to do this a year ago, couldn't even do a two start.
Used the G76 / 10 passes each thread and using Z offset method for the threading.
I did have trouble trying to use the format:
#99066=0
G76.....
#99066=120
G76.....
#99066=240
G76......
The code would just get hung up on the second G76 waiting for the triggering.
RICH
-
Rich:
Interesting. I suspect the trigger angle when used with DRO #66 wont properly do mutistart threads, Im working on a fix for the angualr sensing, it used to be base don # of interrupts as well.
Ill have some new code for Brian soon I think..
Art
-
ART,
I just tried the latest version .032.
I get no RPM or INDEX at all. So threading is realy broke in 3.042.032.
Unfortunately for some stupid reason my postings bounce / never get posted in the Yahoo group.
RICH
-
Rich:
Thx, Ill try it here in the morning. I downloaded the .32 posted and it runs here, so I just need to figure out whatever small error seems to be in there on some xml's..
Art
-
Can you verify.. you dont get an index led lit on the diags page even if the chuck is hand rotated to the index input?
Im getting confused by the lack of Index.. I cant replicate it..
Art
-
ART,
- In diagnostics, it shows the index is working ( lights as you turn the spindle ).
- In the Turn Diagnostics ,will show real time rpm, but there is no indication of "spindle rotation sensed".
- There is no rpm dispalyed in the main Turn screen DRO.
RICH
-
Rich:
OK, this morning I deleted my driver, downloaded .32 version , and copied in my xml.
I did an M3 ( you have to in this version, spindle must be on to read RPM ), and turned on the lathe spindle.
I get RPM no problem.
SO Im thinking it must be something xml related or that plugin. Did you delete any threading plugins for
your test, they may stop it from working in the release version.
Maybe I should try your xml.. though it usually has to be changed so much to match my system it isnt a great test.
So can you delte that threading diagnostic? And see if you have spindle relays turned on so the system knows the
spindle is running when you do the M3 to turn on RPM sensing.
Thx,
Art
-
ART,
BTW, This is for ver .032 ( same goes for i posted in reply 674 )
Tried using "working off line".
- in MDI line - G95
-G32 Z-1.0 F.050 Z axis moves but you will get the error "No SPINDLE FEEDBACK SEEN....."
Reading your reply i and now using the attached XML, tried the M#, no joy.
I am not using a VFD or any motor control.
RICH
-
Hi Rich:
Use ports&Pins and goto the Spindle options tab, uncheck "Disable Relays" and then apply it. I suspect youll find you now can read an RPM when an M3 is in effect.
Art
-
OK,
I had the the Relay Control and Disable Spindle Relays checked.
Didn't need any of that stuff with no VFD or motor control!
SO......
- On unchecking Relay Control /Disable Spindle Relays ( and M3 is left at ouput #1)
Also have motor control unchecked
- Spindle Enabled ( config >ports & Pins>spindle enabled / green check, but no pins out or ports defined ) - in config> ports&pins >no outputs defined.
Then I will get spindle rpm readout in DRO.
In diagnostics red flashing light for output 1, and Spindle On box yellow.
Now can run a threading gcode from the wizard.
After running the g code, the ouput 1 no longer flashes.
Enabled the Turn Diagnostics 1.00.1
How is someone to know what they need to change in their configuration to run Ver .032 if they just have
no motor controls?
RICH
MODIFIED:ADDED STRIKE THRU ON SPINDLE ENABLED
-
Rich:
You shouldnt need to. Ill change that for the future versions. I found that when the spindle stopped, the RPM locked due to the way the measurment system works. SO I made it zero the DRO if the spindle was off. Unfotunatley theres a long time bug in that SpindleOn/Off sensing requires there be a spindle on signal somewhere in the setup. Ill fix that so that its properly modally sensed, and find a better way to determine that the spindle has stopped.
Art
-
Hi ART and All,
As Hood always says "Every Day is a learning Day".
Will update the config section 7.1 in the "Threading on the Lathe" write up.
In the mean time I'll post just that section here and include Arts last reply.
Good grief, the last 5% of that write up to get to rev "0" is like having a tooth pulled. ;D
RICH
-
Attached is a test file which did run fine in .028 & .030.
Will not run in .032 for me.
Can someone just try it out?
Maybe additional changes have been made in .032 not allowing it to run.
RICH
-
Hi, Rich
After my phone call I played with your file some more and can get it to load, Then it wont load, Then it will and so on.
I think this is a problem that has been in Mach for a long long time, I'll play with it some more and see if I can get a step by step list so we can look at it.
It's pretty much a file load/unload/edit issue, I'll give you a call tomorrow.
Chip
-
Yep, I tend to agree with ya Chip, and you realy don't know the effects.
After "numerous" small changes it actually worked and on the second loop, well ,it kicked me out of Mach and locked up the PC. I also lost the DRO and index, took about six tries of opening and closing Mach to get the DRO back.
Got to admit, at least i gave you something to play with. >:D
RICH
-
Rich:
Two problems with it..
1) Subroutine designations must start with the letter O , in your case its "N50 O9999" , that needs to be just "O9999"
2) On the fist line you have G32 Z-O.99 .... but thats a letter O, not the number -0.99 , change that O to a zero.
Ill let Brian figure out why the oddity in execution, it should never have loaded.. :0
Art
-
In case someone is wondering about the looped file see attached.
Thanks Art, I will come up with something different, but equivilant, it the G32 looping is not to be.
RICH
-
Rich:
I think its fine to loop the G32 that way..
You just need to fix that syntax error with the "O" instead of the "0" ..
and put the "N50 O9999" to "O9999" without any N50 on that line.
Art
-
Hi, Rich
Hears what I was talking about.
N10 (Z AXIS TEST NO 2 )
N20 G20 G40 G49 G61 G80 G90 G94
N30 M98 P01 L10 ; it should be looking for "O1"
N40 M30
%
O12 ; So let's say you made an error with the O12 instead of O1
N60 G32 Z-0.9995 F.1
N70 G95
N80 G4 P4
N90 G00 Z0.001
N100 G32 Z-1.0 F.1
N110 G95
N120 G4 P4
N130 G00 Z0.0
N140 M99
%
O01 ('OK, So why is it loading this.)
N60 G32 Z-0.9995 F.1
N70 G95
N80 G4 P4
N90 G00 Z0.001
N100 G32 Z-1.0 F.1
N110 G95
N120 G4 P4
N130 G00 Z0.0
N140 M99
%
O13
N60 G32 Z-0.9995 F.1
N70 G95
N80 G4 P4
N90 G00 Z0.001
N100 G32 Z-1.0 F.1
N110 G95
N120 G4 P4
N130 G00 Z0.0
N140 M99
%
Sintex Errors ?
There is another interesting issue that crop's up from time to time, If you have loaded a G-code file and then used the File, Close File(s) option, Then when you load another G-code file and Edit it, Mach will Open 2 Files in 2 separate windows, The old one and the new one, Which ever one you close last is used as the current loaded G-code.
Still trying to sort this one out so it's repeatable. ???
OK, I think I figured this one out, You can inadvertently "Mouse Click" open up multiple Edit window's, Mach is not sensing that there is already a open file for editing and allowing multiple copy's, When you close the top one Mach covers up the others.
Maybe theres a simple Fix for this. ;D
Chip ;D
-
Chip, what is the fix? ;D
-
Chip,
See what you mean.
-If you leave the "O oh" 02 in it will incorrectly run then "O oh" 01
- If you delete the O02 , then it will stop at the O01 / wont load or run it
Haven't the foggiest, but i would think it should not work.
RICH
-
ART,
Just a few things on version 032, some may have been posted:
1. Spindle rpm DRO dosn't return to zero....it will if you command M5
2.At low rpm here,ie 55 rpm, the DRO reads properly, but the Turn Diagnostics shows values from -1400 to +700
for the Real Time rpm, the application rpm is ok though. No other problem for the other rpm ranges i have.
3.A G32 command will run even though the spindle is turned off / no index. ( it shouldn't run?, in diagnostics it
shows the triggering even though there is no index ) . Turn Diagnostics not enabled. It runs to the first G32
line / shouldn't execute that line. No error reported.
Note that this is not the case if you run a file out of the wizard, as it will give you an error.
No big deal to me but a newbie may do a bad.
Here is the file to try.
N10 (Z AXIS TEST NO 1 )
N20 M3 G18 G20 G40 G49 G61 G80 G90 G94
N30 M98 P01 L10
N40 M30
O01
G32 Z-1 F0.1
G95
G4 P4
G00 Z 0.001
G94
G32 Z-1.0 F.1
G95
G00 Z0.0
N130 M99
RICH
-
Is it possible to have a setting / check box / option added to Mach3 Turn, such that you would not need to go into the M1076 macro via VB Script editor to change the true / false for code output ?
RICH
-
Rich:
Problems noted.
Ill discuss with Brian an easier way to turn on the G76 diags .. must be an easier way than what we use. :)
Johns machien reports a bit of RPM sensitivity, threads OK, but slightly different at different RPM's.. He suspects its the machine,
Im tempted to agree, but over time more info will come in.
Thx
ARt
-
Hi All,
Rev 0 - Threading On the Lathe was posted in Members Docs.
Good until the next version of Mach, ;)
RICH
-
Has anyone with lathe spindle control successfully updated to the latest lockdown? I have a Wabeco lathe that has never had a problem and I've been using the .029 release with no issues. The recommendation for improved threading seems to be to update to .032 the latest lockdown and so I did. After the update my spindle dro indicates -602 rpm when commanded to 1000 rpm and a tach measurement shows the 1000 rpm to be the actual speed. The index pulse is functioning. I'm using speed averaging and index feedback control. Threading doesn't work anymore. Going back to .029 solves the problem. I went back and forth three times and the spindle issues follow .032. At leat three others have reported similar issues and eventually went back to much older versions.
I was following the threading improvement progress in this thread which seemed to finally solve the lathe threading issues and so .030 was released as the new lockdown after the improvement were included into the .029 release. Unfortunately the guys working on the threading issues used manual spindle control and a few reports from others resulted in two more quick releases to .032 which is where we are now. I waited a week to see if any other reports came in before upgrading, and when I did I ran into spindle problems. It could be just my particular setup but I'm curious as to whether anyone else has gotten it to work with auto spindle control. - Terry
-
I don't think it is a problem of auto versus manual spindle control, as I am seeing the problem under both, although it does appear that others who are not having any problems are running the spindle under manual control.
The index signal is getting through as can be seen by a reasonably stable and true speed indication in the rotation speed realtime box in turn diagnostics. The problem appears to be in the conditioning of this signal as displayed in the application end RPM which is negative and is the same as the spindle speed indication given in the true speed DRO. Further details in my other posting " Indexing problem with R.042.032"
The same problem existed in versions .30 and .31.
Peter
-
Can you attach the xml that you have when running the latest version, probably wont see anything wrong, but you never know.
Hood
-
Hi Hood
XML attatched,
Peter
-
Ok try this, when using the 032 version go to Ports and Pins and disable the Spindle relays and click apply. Then enable and apply again and see if that cures your problem.
Hood
-
Hi Hood
Thanks for your help. No, the problem remains after carrying out the test with the spindle relays.
Peter
-
Do you see the index pulse on the diagnostics page?
Hood
-
Hi Guys:
In theory the spindle timing is done in 64 bit, while I only used 32 bits of it. If you have a vcery fast cpu, it may cause a rollover. Im checking it out now. Can anyone confirm, as on my machine, the RPM reads OK?
Thx
Art
-
Yes the index is indicating on the diagnostics page.
Peter
-
Hi Peter:
Actually, I was wondering if the rpm was OK on any machien but mine. :)
This is hard to test here as my RPMis fine and I suspect its computer mothervaord related.
Here is a version of .32 that has a unsigned interger fix.. Can anyone confirm if this helps or not?
Thx
Art
-
Hi Art
I loaded the application you attacthed into Mach 3, replacing the existing one from version .032. (Was this right?) Version in help/about shows 0.030.
It seems to solve the problem. RPM indication is showing true and application end RPM is closely following rotation speed realtime in turn diagnostics.
One observation is that in turn diagnostics, spindle feedback is showing as being disabled, whether or not "use spindle feedback in synch mode" is enabled in ports and pins.
Peter
-
Hi Peter:
The new code makes the thread diags bad.. Id delete them. The version is correct..I just didnt update it.
Art
-
Hi Art
Understood.
Another observation as follows:
Start mach 3, run M3S1000 from MDI or G code program, spindle LED lights but spindle motor doesn't start.
Repeat this test several times, same result.
Load 1000 into required RPM DRO and select spindle button on screen.
Spindle starts at 1000 RPM
Now run M3S1000 from MDI or G code and spindle starts correctly every time.
I have repeated this several times powering down the computer between tests. It seems that M3 will not start spindle motor unless it has previously been started manually (by the spindle button)
Peter
-
Peter:
What happens if you do a S1000, then an M3 on two separate entries?
Art
-
Art
It's the same.
The spindle on LED comes on but the output LED for the spindle in diagnostics does not flash. After spindle has been switched on once manually, then entering S1000 and M3 as 2 separate entries works the same as entering them as one entry. Spindle LED illuminates, output LED flashes and spindle starts.
When I went to the shop to do this, I noticed that I am now not getting any speed indication at all. Reading is always zero RPM and Index LED is not registering a pulse. This was working fine a couple of hours ago. Restarted mach, rebooted computer, but at the moment I am not getting a pulse on the index.
Peter
-
Art
System index restored. Oil in switch. Status is now the same as my post number 706.
Peter
-
Last message should read status is same as messages 704 and 706. The RPM indication is working correctly but spindle start problem remains.
Peter
-
thx peter. Ill check it out.
Art
-
Peter,
Did you check to see if if threading now works or if it hangs looking for an index pulse? - Terry
-
I didn't get a chance so far due to work commitments, but I will try it tomorrow and post findings here.
Peter
-
I tested threading today with the special version of .32 attatched to Art's post number 703, using the simple threading wizard.
At first the spindle would not run at the speed programmed in the wizard and I was getting an error message "Scripter Compile Error. In: Spindle Speed.mis" Could not resolve this, so reloaded version 042.020 and ran threading wizard succesfully.
Reloaded special version of .32 and tried threading wizard again. This time spindle speed was as programmed with no error messages.
Threading program ran OK but the pitch was incorrect. Further investigation showed that the pitch varied with spindle speed. Testing with a pitch of 1 mm the following feed rates were noted:
RPM 600, Feed 0.31 mm/rev
RPM 200, Feed 0.72 mm/rev
RPM 100, Feed 0.98 mm/rev
Z axis velocity is set at 1000mm/min
At 100 RPM the feed rate was unstable and the Z axis motor could be heard to be continuously hunting.
During testing, the programmed spindle speed, indicated spindle speed and measured spindle speed (tacho) were all within 2 to 3 RPM.
During threading the tool engaged correctly during each pass (although at the wrong pitch) except at 100 RPM where the fluctuating feedrate destroyed the thread.
Peter
-
Hi Peter:
Hmm. Ill check this out. What was the G76 line you used. That pitch seems strange.. cant figure what its related to.
Better yet, can you try 600rpm again, and then p[ost whats in the lasterrors.txt file.. Itll tell us why the pitch was wrong..
Art
-
Peter:
My appologies, I think I may have found the problem, I had forgotten your machien was the fast one that overwrote the neg bit in the timer.
I found the correction had to be fixed up for that as well. It may explain the pitch error. Try this version and let us know what happens.
Thx
Art
-
Art
It looks good.
I cut 4 threads today as follows:
1.75mm pitch at 600 RPM
1.25mm pitch at 200 RPM
1.0mm pitch at 400 RPM
0.5mm pitch at 100 RPM
Spindle RPM and pitches were correct as programmed and were stable. 1.75mm pitch was gauge perfect, the others fitted nuts well (no gauges available) Threads look good, everything ran smoothly.
Thanks for your help on this.
Peter
-
Peter,
Save me some reading. Can you post your XML so i can see your configuration?
ART,
I assume that this fix doesn't affect threading when setting the rpm manualy?
RICH
-
Rich
XML attatched as requested.
Peter
-
Hi Rich:
No, the fix specifically was for CPU's over 2.1Ghz on PCI timer speed. Originally, the PCI bus ran at 1Mhz,
but it seems over time to have sped up, and some actually run at over 3Ghz.
Now if you have less than 2.1Ghz, you were fine, but after that the RPM oudl read negative, and the correction would be
negative. Ths version fixes that.
Peter: Thx for the confirmation, Ill notify Brian as to the fix.
Art
-
Art,
Just to clear up a little confusion, with this fix are the Turn Diagnostics still valid? - Thanks - Terry
-
Terry:
No, the Turn diags are now outdated due to these changes. Ill revisit them when I know the release version of Mach3 is OK with threading. Theres a few changes I need to make to the Theading dll to be usefull again. It was only experimental as it was.
Thx
Art
-
Your new .exe nicely fixed the negative rpm problem in the lathe S true DRO and threading seems to also work well. Thank-you. I also run my mill from a second PP card in the same computer. After switching to V.032 with your 'fix' the mill spindle will now not spin up from from either the MDI or g-code unless it is first started at least once from the screen spindle start button. Then it will start up from either g-code or the MDI until the system is restarted again. The spindle uses step and dir outputs and the 'disable relays' option is unchecked. The mill spindle works fine in V.029 but not in V.032 with the fix. I've really not tried it on the mill without the fix. - Terry
-
Terry:
Thx.. It may be a general bug with other code, but Ill run a check tomorrow on it and let Brian knowwhereit lies..
Art
-
Guys,
Tried ver. 32 and 33 and cannot get acceptable results threading.
Before I go further, I'd like to know if this older PC would not be expected to handle the latest improvements to the SW.
It's a Dell Optiplex GX1
Pentium III
600 MHZ
384 Ram
Manual spindle motor with pulleys, single slot INDEX.
Diagnostics Information screen shows:
Rotation Speed realtime 1317 - 1318 RPM
Application end PRM 1198 - 1498 RPM constantly alternating the 1 (hundred) and the 4 (hundred)
The Spindle Speed DRO on the screen does the same as the App RPM.
In older versions, the RPM fluctuates 1 or 2 rpm on the normal screen.
Averaging ON or OFF......same results.
Just checking before wasting too much time on it.
Thanks,
Russ
-
Russ,
Do you have the turn diagnostics on?
Do not use or enable the plugin. It is no longer functional.
RICH
-
Hi all,
I am sorry about not updating the write up.
I have comments marked in mine and thought that i had updated it some time ago and posted the update.
Obvioulsy not.........
The main thing is that the diagnostics is no longer functional, so....
Ignore most of page 19/ fig 3.7.1 & 3.7.2
Page 42, ignore the third paragraph
Page 45, ignore verbage related to and figure 7.1.5
Page 46, ignore the whole page
,and you need to use an M3 or spindle button to turn the spindle on or you won't get an rpm reading in the dro...
this was done so Mach would be able to read low rpm's ie; it informed MAch to start looking for the index pulse as it relates to rpm
RICH
-
Russ,
Dell Optiplex ........I have a Dell Optiplex GX520 and the signal out of the pc's PP just plain sucks and there is nothing i could ever do about it. Also the kernal speed was not that solid. Worked fine with a SS.
On my new pc the kernal will be like 25004 +- 1 or 2, and never changes, but, the new rpm that is displayed is not a manipulated one ( for lack of better words ) and is based on the index pulse / real time. Max velocity with the Dell
was 20 IPM and that was a stretch........new pc 120 ipm if deisred via PP.
My DEll is a great machine otherwise,for everything, but for MAch via PP, well it just plain sucked!
FWIW,
RICH
-
Russ,
Do you have the turn diagnostics on?
Do not use or enable the plugin. It is no longer functional.
RICH
I looked through this lengthy post rather quickly and did not see mention of that....sorry.
Yep, I had it running.
My fault...I followed the manual to a T again, all that info that is now RED ::) :D That IS a great work you got going there Rich.
I'll try it again with the diag OFF then let you know what I get.
I had a GX270 on this lathe.....it went TU. It output 3.3v and worked great through a buffered BoB. Best conservative rapids were about 80 ipm.
This old dinosaur on there now pumps out a solid 5v to the same BoB and now the rapids are at 200 ipm......never skips a beat. I was pleasantly surprised.
Don't know what else may be different, but all I did was change the PC. On-board PP BTW.
Thanks Rich,
Russ :)
-
HI ALL,
The manual is updated to reflect comments in reply #727 and was posted today in Members Docs.
RICH
-
Hi friends!
My problem is that the thread cutting 30mm round is longer than miss, but the following cuts of all good in the beginning but then miss the 30mm length of sync.
setting the timing gap 8 (a gap twice as large as the others), the PWM spindle - Hitachi L100 inverter, half ratio, 50 Hz - 700 rpm M30x1.5mm l = 130th
The 12 passes and only 30mm high early next Threading bad!
What is the problem? Mach3 2.61, WindowsXP SP2, Intel pentium4, 1Gb RAM
Sorry but the google translator I wrote!
Kola
-
Hi
Upgrade to 2.63 ... there was small syncing bug in 2.62
Art
-
Hi Art!
The situation has not changed even after the update!
The lathe spindle number of pulses is best?
Timing 8 to me that a lot of gap now?
Kernel 65 000 Hz, 2.7 GHz Intel Pentium processor.
I ask you to debounce interval 500 and 100 index debounce setting to good?
Hi Kola
-
Hi Art!
test: spindle true 500rpm , the programmed G95 feedrate 1mm Spindle 250 - true feedrate 0.5mm
spindle true 500rpm , the programmed G95 feedrate 1mm Spindle 500 - true feedrate 1mm
spindle true 500rpm , the programmed G95 feedrate 1mm Spindle 1000 - true feedrate 2mm
why is this problem?
Kola
-
Hard to say, is this the latest version?
That shouldnt happen unless the license is invalid though, so Id check the license is installed
properly, and also check the "Use Spindle Feedback" option is checked.
Art
-
Hi Art
License name Kola cnc
Version R3.043.000
Spindle Feedback" option is checked.
I have to link intrnet turning the ID check?
Kola
-
>>I have to link intrnet turning the ID check?
Not sure what that question means... Id report it as an error to machsupport.com , sound sliek something is screwed up..
Art