Build Thread - Emco 320

[suntravel]

Some parts of the lathe manual are from the mill with G91...

Uwe

Exactly. Its not like I havent read through the manuals, extensively. For example, if you search for Incremental, nowhere do you get UVW references.

I also wouldnt mind some feedback on questions posed earlier. I do recognise that its holiday etc, so not been too pushy - Ive done a LOT of work to understand and make this work. Currently not having a reliable A 'home' is a problem as the starting position is critical. I'd love to know if I can do a position move and look for the turret 'bits' to then interferre but I think the position moves have to be completed before the next step can be taken.

Thanks

UW is also mentioned in several positions in the lathe manual, only in some spots G91 from the mill sneaked in.

8.2.10 U – Incremental X-axis Move Command
To specify an incremental move on the X-axis, use U in place of X in the command line (see example below).
8.2.11 W – Incremental Z-axis Move Command
To specify an incremental move on the Z-axis, use W in place of Z in the command line (see example below).

Uwe

[Chaz]

Some parts of the lathe manual are from the mill with G91...

Uwe

Exactly. Its not like I havent read through the manuals, extensively. For example, if you search for Incremental, nowhere do you get UVW references.

I also wouldnt mind some feedback on questions posed earlier. I do recognise that its holiday etc, so not been too pushy - Ive done a LOT of work to understand and make this work. Currently not having a reliable A 'home' is a problem as the starting position is critical. I'd love to know if I can do a position move and look for the turret 'bits' to then interferre but I think the position moves have to be completed before the next step can be taken.

Thanks

UW is also mentioned in several positions in the lathe manual, only in some spots G91 from the mill sneaked in.

8.2.10 U – Incremental X-axis Move Command
To specify an incremental move on the X-axis, use U in place of X in the command line (see example below).
8.2.11 W – Incremental Z-axis Move Command
To specify an incremental move on the Z-axis, use W in place of Z in the command line (see example below).

Uwe

Fair enough. I clearly didnt go through all of them but had spotted the G91 which is what I tried.

Ive managed to get another way to do it for now. It means however I dont use the grey logic at all.

I use bit 4 for home, its only used once in the sequence so this is my reference. I edited the .hom to do A home. It does sometimes time out, I need to see what the reason is for this (if I'm too far).

From this point, I have repeatability and have got T1 and T2 to be repeatable. Ill work out the coords for T3 onwards.

The turret does have an odd 'rollover' thing - its something to do with the locking setup and you can basically 'fall' either left or right of the locking mechanism and then it has an offset. As long as I dont 'engage' this rollover, I'm fine and my calcs are repeatable. Not sure if its a mechanical issue once it hits some limit or if the turret is designed to do this.

[suntravel]

My advantage is working with CNC lathes for decades, most systems are using UVW for lathe incremental moves, not G91

Uwe

[Chaz]

So, Ive got it working reliably as far as I can tell but im not using the encoder feedback for anything other than home. It would be good to know if a move can be performed and interrupted by an input changing.

Thanks

[Muzzer]

my turret's 4 bit encoder seems hyper sensitive to what direction I come in from as it has a part that reads, then doesnt read, then rolls over to the next number. I'm now landing on the right tool consistently but sometimes the encoder thinks Ive gone just too far. The 'fix' will either be to ensure that I always come in from a positive A direction or maybe messing with the turret alignment which I'm not keen on, so will fix via software.

On my turret, the encoder is easy to adjust, having slotted holes to allow the encoder to be advanced or retarded relative to the turret. It sounds as if that would be well worth looking into on your machine, if you are finding that the encoder is struggling to decide on a consistent position just where it's needed.

My encoder has 8 lines, rather than use Gray code and as it's hydraulically operated, there's no reversing required. However, I'm using 8 of the ETHER1616 inputs and the programmed delay between the correct tool being "seen" and the tool stopping seems to be consistent enough to avoid any misses, even if the response of the inputs and outputs is fairly slow. There is no clever feedback or sequencing going on beyond the encoder position.

I see that (like mine), your machine runs with a clockwise spindle direction and wants to use "left hand" tools mounted "the right way up" at the back of the machine. That complicates tooling, particularly threading inserts and boring bars.

[Chaz]

Hi Muzzer.

Thanks. My turret can run both ways. Its the the way it locks / unlocks. What drives your turret? If its just a motor like mine was before I burnt it out, its just 'left and right' contactors. Its stopped with a Pin. But, on the servo. I cant stop on a pin, well, I risk breaking something as the servo has a lot more torque. Ive thought of detuning it but not tried yet.

[cnckeith]

thanks for picking up on that, will get the mill stuff out of the lathe manual.

[Chaz]

thanks for picking up on that, will get the mill stuff out of the lathe manual.

Hi cnckeith,

Possible to pick up on some of my questions in the thread?

1. PNP, needs Ether1616, so the latency is what it is (ie, no option to use Acorn direct, unless using some 3rd party board to swap from PNP to NPN)?
2. Is there a way to 'interfere' with the turret's position command if the status of an input changes? A bit like homing, I've got A axis now homing to the 4th input of the encoder. I now at least have a consistent starting position and the current code uses this.

On the old system it just had a normal 3 phase motor with contactors that initiated CW or CCW movement. A pin then stops the turret at the location once it is correct, and some logic then locks it.

Is it possible for me to instruct it to go to a position, trigger an input, and stop there and then? I could understand how to do this with speed control, just take away the run signal and have a constant speed set which can then reverse as needed. However if I use code like G53 A0 (in position mode , as its currently set) and lets say its at A200 and it detects the correct 'stop' signal at A30 on its way from 200 to 0, will it try and complete the A0 move before it checks for an input or can you do a move which is conditional to an input?

It might be poor coding / practice but you could move 1 degree, check the status of the input, repeat until you get to the desired location. Not sure how well that would work in practice however.

Thanks

[Muzzer]

1. PNP, needs Ether1616, so the latency is what it is (ie, no option to use Acorn direct, unless using some 3rd party board to swap from PNP to NPN)?

Can you dig into the turret and reconnect the position switches so it is NPN rather than PNP? If it's constructed using reed switches, microswitches or contacts, you may be able to flip the polarity of the signals.

[Muzzer]

Hi Muzzer.

Thanks. My turret can run both ways. Its the the way it locks / unlocks. What drives your turret? If its just a motor like mine was before I burnt it out, its just 'left and right' contactors. Its stopped with a Pin. But, on the servo. I cant stop on a pin, well, I risk breaking something as the servo has a lot more torque. Ive thought of detuning it but not tried yet.

My turret drive is actually very simple - it's purely hydraulic. Enabling the solenoid drives the turret from its seating and operates a hydraulic motor to turn the turret. Once the correct tool position is detected, the hydraulic pressure / flow direction is reversed and the turret is clamped back against its seating. The hydraulic motor can only go in one direction so it doesn't try to reverse. The speed of rotation is fairly consistent and there's a bit of leeway on how accurately the turret needs to stop at the right position, so the programmed delay I've set between the position feedback and flipping the solenoid seems to be at the sweet spot. I guess that includes the propagation delays in the ETHER1616 loop too. There's a microswitch to detect that the turret has fully retracted again but it doesn't seem to be needed.

Here's an example of a tool change (at about 1:40)