Emco Turn 220 P

[zmajmr]

[zmajmr]

[zmajmr]

[zmajmr]

[zmajmr]

[Hezz]

From the angle that I am at it looks like some of the tools are going to crash into the vice. It could be the controller is shutting off the program to keep the machine from crashing. The controller knows how long those tools are and in some controllers there is an envelope for the chuck that if any tool interferes it will stop the machine. Take out the long tools and tell the controller that there is no tool in the turret in that position and see if the problem persists.Or move them so they are as far away as possible from each other. You should have a side turning tool between the boring bar and the threading tool to give more clearance. Because the turret is so small on this machine this is going to be a problem. Of course the controller needs to be programmed properly so it knows what is in each tool position.

That's why I'm thinking that there is a safety envelope programmed into the controller. And the long boring bar is going into that zone. Also, check and make sure there is not a faulty z offset for one of the other tools. If the controller is a smart one it may check these values for safety even if the tool is not in the active machining position. Every time a new part is programmed and run all of the tool positions need to be managed to make sure there is not collisions with the chuck. And the tools have to be rearrainged and touched off in both Z and X. Maybe you did all of this and it is something else but this is what comes to mind.

[zmajmr]

From the angle that I am at it looks like some of the tools are going to crash into the vice. It could be the controller is shutting off the program to keep the machine from crashing. The controller knows how long those tools are and in some controllers there is an envelope for the chuck that if any tool interferes it will stop the machine. Take out the long tools and tell the controller that there is no tool in the turret in that position and see if the problem persists.Or move them so they are as far away as possible from each other. You should have a side turning tool between the boring bar and the threading tool to give more clearance. Because the turret is so small on this machine this is going to be a problem. Of course the controller needs to be programmed properly so it knows what is in each tool position.

That's why I'm thinking that there is a safety envelope programmed into the controller. And the long boring bar is going into that zone. Also, check and make sure there is not a faulty z offset for one of the other tools. If the controller is a smart one it may check these values for safety even if the tool is not in the active machining position. Every time a new part is programmed and run all of the tool positions need to be managed to make sure there is not collisions with the chuck. And the tools have to be rearrainged and touched off in both Z and X. Maybe you did all of this and it is something else but this is what comes to mind.

Hi I saw what is problem, tool changer can not go lower then it goes in x direction, and if it can not go lower then threading tool need to stick out little more out of turret in x direction (towards ground).
Yes look like tools will crash but it only look, I check before machining will something crush, yesterday I cut threading tool and and welded it on 16 mm rod so it is moved in x direction for additional 16 mm which is too much (I was not able to rotate turret safely, I am using - and + buttons on screen to rotate turret for small amount), so now need to make it again, hopefully I will fix problem today. Will show how it works.

Other thing before I start cycle start I every time get notification soft limit warning even nothing bad will happen (in most cases), it is been told to me that it is Mach3 bug for that version but also it has been told to me that that version is with least number of bug for my CSMIO controller, anyway when I started with conversion I downloaded newest Mach3 version and did not had any problems , but when I bought new motion controler from CS lab I had lot for strange problems (still have some like ePID fault almost every time I reference toolchanger) so I got advice from support to use version which I am using today, when e PID fault did not want to diaper even with recommended version I got advice to stick with recommended because it is much more reliable. Anyway I thought newest version of Mach3 that means it works better then previous one, but I guess it is not like that.
I am also couriers will machine cut internal thread normally @600 RPM when I move toolchanger from x boundary for x movement of machine, I assume it will, but will see, I can not claim anything until I try

[zmajmr]

[zmajmr]

Another day new problem, so I thought that tapered gibs are to tight but they are OK.
Here is what is happening, when I am cutting internal thread I need CLW spindle or M3 (I mange to cut threads even @1000 RPM, first thread was faulty but that is not important, motor manage to rotate normally, want to tell that even 20 kg of tool changer and all what is connected with it, was not problem for motor to move while it cut threads).

Now when I wanted to cut threads internally I need M4 and things that happens, when command G32 arrives motor make impact sound, like you take hammer and you hit on it and that sound is louder how I choose higer RPM, for example @ 400 RPM I can cut internal threads, @ 500 motor sometimes suffers overload sometimes not, @ 600 RPM same second while I see G32 on Mach3 screen as active command motor is dead (driver shuts it self down after strong "bum"/ "boom").

I tried to decrease acceleration from 400 to 200 m/s/s, decrease rapid federate from 3000 mm/ min to 2000, increase number of steps per revolution, nothing did help .

When I compare G code program where everything is same expect in one I use M3 and I do not have "boom" and in other I only have M4 instead M3 and I HAVE BOOM,
so I do not know what is going on, will send this to CS Lab support so I think they should help me, I guess . If somebody have idea what it could be I am all ear.

[f1oat]

Sounds like there is a logic problem in the digital pulses sent to the Z motor driver, and not a mechanical problem.
If that does not occur with G1, that means the problem should be around Z/spindle synchronization.
As the problem is with M4 and not M3, I think the issue is linked to the quadrature encoder management.
Do you use index pulse on top of A/B quadrature signals ?
Depending on how this index pulse is managed, it can disturb the counter tracking A/B, with different effect depending on rotation direction.
Frederic.

[zmajmr]

Sounds like there is a logic problem in the digital pulses sent to the Z motor driver, and not a mechanical problem.
If that does not occur with G1, that means the problem should be around Z/spindle synchronization.
As the problem is with M4 and not M3, I think the issue is linked to the quadrature encoder management.
Do you use index pulse on top of A/B quadrature signals ?
Depending on how this index pulse is managed, it can disturb the counter tracking A/B, with different effect depending on rotation direction.
Frederic.

Hi Frederic, you are right, it is not mechanical problem, it does not occurs with G1 , only with G32 and M4, with G32 and M3 no problems.

About encoder, I do not have much to change/adjust, I entered that total pulses is 10000 like it say in manual and it all works good until I want to cut threads with M4 spindle rotation.
Basically you have block for encoder where you plug its connections and you plug that block/module on motion controller (it is like black box) so I do not know what is going inside but have feeling that that what is going on is not good.

So hoping if that is problem guys in CS lab can repair software for firmware or something like that because I really do not know what I can change (tried everything that crossed my mind).

how encoder interface looks like


I recorded also video what all data encoder gives (it is position and angle in degrees) but can not find video, too much of them , probably it uses index because it can chase threads without of problems.

[f1oat]

I see the config panel: not much parameters.
If my assumption about faulty index pulse management is correct, you should have the Z axis "hammer noise" synchronize with the index pulse.
Should be visible by using an oscilloscope to monitor index and step pulses simultaneously.
You will need help from the tech support.

[zmajmr]

I see the config panel: not much parameters.
If my assumption about faulty index pulse management is correct, you should have the Z axis "hammer noise" synchronize with the index pulse.
Should be visible by using an oscilloscope to monitor index and step pulses simultaneously.
You will need help from the tech support.

I sent mail to support so will report what they say, that is word - hammer noise
good night

[zmajmr]

[zmajmr]

this is material 1 month old, so maybe it will be useful for someone

about hammer sound, I am still waiting for support to fix software for firmware (they (support) have same problem as me when M4 is used with G32) , I thought it will be fixed for day or two but I think I am waiting almost 1 month now, not good

[zmajmr]

[f1oat]

You need to keep pressure in the tailstock when machining.
If not, due to small internal air leakage, the air which is in the right part of the cylinder will migrate to the left side.
As a consequence, the tailstock will move backward slowly.
I experienced the same issue on my machine when parking the tailstock to right side : after 10 minutes the tailstock was in middle position without any command!
I solved the issue by adding a gasket between the piston head and the road.
Will try to remove the gasket and use teflon tape on the thread because I am afraid of potential gasket worn when applying pressure in the piston.
But, even if you fix the leakage issue, I recommend to apply permanent pressure when machining to avoid any issue due to small remaining air leakage.
Frederic.

[f1oat]

I sent mail to support so will report what they say, that is word - hammer noise
good night

Another idea.
As an interim solution, you can try to configure the controller for a 2 wires encoder (pulse A + index), and not 3 wires (A+B+index).
That will be similar to the original Emco encoder.
Of course, by doing that, the controller will not be able to sense the direction of rotation (CW or CCW).
But that should not be a problem as you are not changing the spindle rotation direction during the threading operation.
It will forbid only rigid tapping.
I guess the controller will react identically in both rotation directions. and should not show the problem anymore.

[zmajmr]

Thx Frederic one more time on you ideas, they made update (CS LAB support) of firmware so now it works

[zmajmr]