Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Promech on April 18, 2011, 01:08:50 PM
-
Hi all,
I am testing my lathe with threading. My index pulse is generated by the machine original encoder. The signal is fed to a bb board where it is supposed to be properly conditioned and then on to Mach. The RPM reading seems to be accurate and stable. But when I do threading the thread cut is not repeating its trayectory. I have used both the G76 cycle and G32. Any ideas what could be going on?
The fact that there is a an RPM reading makes me think the signal is o.k. My threading is all within max feed limits.
Thanks,
Jorge
-
On the ports and pins under spindle have you check to use spindle sync?
-
Yes I did and still having trouble. Could there any reason why the RPMs read o.k. and the thread trayectory is random? The pitch seems to be o.k.
Thanks,
-
I agree, if the RPM reading good and steady you ought to have a good trigger.
What Mach version are you using? Par port or SS?. There have recently been a LOT of work and changes made to the driver code for threading- see mostly the Yahoo group for lots of detail. If you are runing anythng less than the latest version you are wasting your time.
-
Running Version 3.042.029
I am observing that the index pulse signal goes on and off with an unstable frequency. I do not know if this has any meaning. How should it behave. Should it be constantly on?
Thanks,
-
You should be using Mach3 version 3.042.32 and above and if not upgrade.
I assume the encoder is only giving you 1 pulse per revolution....ie; same as if you were using a single slotted disc. Multi slotted
discs or encoders are not supported for threading and will not provide for greater accuracy even if they were.
Are you providing for 3 to 5 pitch lengths to allow the Z to accelerate to desired speed?
Do you have any backlash?
Is the rpm fluctuating or the spindle slowing down when cutting the thread?
You may want to have a look at the Threading on The Lathe write up located in Members Docs.
Do a scribe test.
RICH
-
Upgrade your Mach Version and the problem should go away.
Let us know how things go.
RICH
-
Rich, I got a very rigid and accurate machine. The control is on an Emco CNC lathe that is in very good mechanical condition. It has a repeatibility of 0.005mm or less. From this post and other posts on the subject it seems as the problem is clearly related to the Mach version I am using.
Questions.
1. If I upgrade (meaning I install a new version). Which is the best way to configure the new version. I have spent a lot of time configuring the existing version (including modbus communication) motor tunning etc.. Are there configurations files I can save and then transfer on to the new version?
2. If my existing version is licensed, how do I make the new version licensed. The downloads which I find are demo versions.
3. Will any upgrade above 3.042.32 work? The latest one seems to be 3.043.022. Is this the one I should download?
Thanks,
Jorge
-
Jorge, It is allways good idea to save a copy of your XML, and any of these you may have that are custom: Macros, Brains, PlugIns Screen sets and related bitmaps. I also save a copy of my *****Lic.dat (licenses)files. All of these can be found in your Mach3 folder.
When you update Mach will recognize your licenses.
In the downloads link above, Mach and Lazycam, under the lockdown version you will see the development version.
Bret
-
I have not tested every version above 3.042.32 but have not seen any reports of threading problems above 3.042.33.
So anything above them should work.
RICH
-
Thanks all. To be practical the entire Mach3 directory should be backed up...
-
I upgraded to the latest lockdown version R3.043.022. Upgrading was very simple. The threading problem did not go away. I did some tests and the behavior is repeatable. I was able, with three similar passes go over the same path. The trick is that I had to offset each pass by 0.17mm. I turned the control on and off and the behavior was the same. I am attaching the program file I used for testing. Maybe I should ´downgrade´ to R3.042.033 which has been proven to work well with others. I would like to know however if anyone can understand this behavior before reinstalling again.
Thanks,
Jorge
-
I turned the control on and off and the behavior was the same.
WHAT CONTROL?
Are you using the threading wizard to generate the code?
Do you have any backlash in the Z or X axis?
You should not need to do anything. Do a simple scribe test as that will tell you a lot.
RICH
-
By Control I mean turned off and then on the computer and repeated the test.
Installed V3.042.033 just to discard a Mach problem.
I just ran a test with code generated with the threading wizard and the problem remains. The resulting thread has a fishbone shape. As the tool penetrates more in each pass it is also displaced a small amount in Z, therefore this shape.
I may have backlash, but I am sure its neglegible compared to error the thread is showing.
This behavior makes me suspicious of my Z axis setup. Will check that tomorrow.
Jorge
-
Jorge,
Your threading quality will only be as good as your lathe "system".
It's that simple. Do a scribe test.
RICH
-
Rich,
Here are some results from this morning.
Checked Z axis for backlash with a dial indicator: 0.03mm
Mach backlash compensation is disabled.
Check repeatibility precision of Z axis: In 6mm its dead zero. Checked arrival point both with G1 and G32 and they behave exactly the same.
Then did a threading test (see attached). Made three passes and they are off about 0.3 mm from each other.
I am attaching the photos of the test and the code used.
The spindle encoder is a Heindenhain that came with the machine. The index signal is processed by a Machmotion B B board. RPM reads well, and even RPM control with feedback is very accurate too.
Still cannot understand what is going on........
Thanks,
Jorge
-
Hi
Does your offsets change with pitch? So if you cut a 1mm thread then it's out by .3mm but when you cut a 2mm is it out by .6mm?
-
Jorge,
Post your xml file for the lathe that you are using.
RICH
-
Try the Dev version and see if it helps. Art found an issue recently that has been there since the start and has modified the driver, dont think the lockdown has that fix.
Hood
-
Hood,
Do you remember what the issue was?
RICH
-
It was basically the way Art was calculating things and I think spindles speeding up slighly threw things, most common with VFD controlled spindles. The latest driver can now account for spindle speed up, think 125%, so that should be more than adequate for most.
The problem has always been when a few reported threading issues Art would work with them and a fix would be found, problem was because of the small user base it was not widely tested so it was thought it was cured but in reality it had just been tuned to the testers machines.
Hood
-
Rich,
Attached XML.
Jorge
-
Hood,
Ok good to know since i haven't been following the Yahoo group and didn't notice anything here. Back when ever, you needed to set the speed manualy even if you had a VFD.
Thanks,
RICH
-
Jorge,
First can you set the spindle speed manualy?
Tick the box for Spindle Speed Averaging.
You never replied back telling me what kind of index you had. Is it a single pulse per rev or multi? You only want to have a single index.
How close is the PPS during the driver test to the selected khz setting?
Mach looks at the pulse and determines the true RPM, the more stable the better. Lets assume that it is exactly the same for now.
If the DRO is fluctuating by say one rpm or so that should be ok.
So if the rpm is stable and the same, then when the index is sensed, the G95 mode is allowed / the G32 coded line is implmented . Mach provides for a Z axis move such that the controlled cutter point will hit the same exact start point of the thread. That is true for your posted code as you have the Z sitting at the same location waiting for the index and doing the same move.
So do another scribe test with the rpm set manualy and see what happens.
RICH
RICH
-
Hi Rich,
I think I can set the spindle speed manually. By this I guess you mean directly from the VFD without commanding it from Mach. I will try that.
Ticked Spindle Speed Averaging, same behaviour.
Ticked Spindle speed feedback. Spindle variation less than 2 RPM, but no improvement in threading.
I have single pulse. It is the index pulse from a heindenhain encoder, that goes through a break out board (otherwise it would be too fast for mach).
Attached PPS test result
Installed latest Dev version and behaves the same.
Clue: Tried a 10 sec delay (G4) before each G32 and the offset between threads diminshed. >:(
Will try manual control of the spindle and see what happens.
Jorge
-
Sorry, I got the wrong driver test photo in my last post.
BTW I am using Windows 7
-
Tried a 10 sec delay (G4) before each G32 and the offset between threads diminshed.
Hmm ........ that would be similar to using a high index debounce ( how manny times the index signal must be seen before accepted ) in configuration.
Some work with a setting of 0, I use 10, and think yours was set at 100.
By manualy setting the rpm ......and should the scribing turn out good.... then you eliminate the index as a possibility and the problem lies in control / reading of the VFD rpm. By scribing you are eliminating any cutting forces which could alter the rpm. Just trying to pinpoint the problem.
BTW, XP Pro here.....see no reason for W7........guess i am getting old and cheap! ;)
RICH
-
Instead of the encoder tried a slotted disk with a hall effect sensor. Problem got solved at least to the naked eye. Problem could have been related to the signal stretching circuitry of the BB board or to the encoder itself, or any other unknown cause, not sure.
Tried V42.033 and worked fine. Then installed V43.022 (latest lockdown) and unusual jerking in the Z axis started (just in threading movement). Installed back V42.033 and jerking continued. Installed latest dev. version and all went back to normal. Cannot explain what happened...........
-
Link to how i installed a Halls sensor.
http://www.machsupport.com/forum/index.php/topic,12484.msg82818.html#msg82818
RICH
-
Hi, can Mach3 make threading conical? If i define G76 Xend Zend conical could make this but i now no have implemented my turn and can`t probe this.
regard
Renato
-
You can make a tapered thread by specifying the taper in the wizard. I would need to find my notes on doing it. The taper
input is "twice the angle" ,I think ....... just dont remember. The "T*********xx" in G76 defines the taper. Been a long time since I did one.
RICH
-
Then this is possible make threading conical.
Other restlessness when mach3 turn think implement timing pulse, namely several pulses por revolution of spindle?, i see several turn cnc and all use encoder in spindle.
This must be at least a few slots per revolution for more precision long threads. because several factors can alter the velocity of spindle in one revolution and the mach no informed of this.
thanks
Renato
-
When using the parallel port Mach just uses a single index when threading and it works well. There used to be an option for multiple slot discs but there was no real benefit to using them.
Hood