Messages

1

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: April 04, 2019, 05:20:35 PM »

OK - now I have localized the problem with G32 using Mach 3 Lathe on a Win7 UC300ETH/UB1 setup.  If I call Tool 0, G32 works as expected with no problems.  If I call any tool with a non-zero X-offset in the tool table, G32 moves in X while it's moving in Z (even with no X motion programmed).  I can work around this by doing threading as a separate operation with T0 or by using the threading tool as my reference tool.  Still, I don't understand this problem and would like to fix it.  As usual, any ideas are appreciated - TIA! -Mark

In the example, below, tool 2 has an X offset in the tool table and this code will fail, as it is, by moving the tool in X during the run - if I change the tool call to T0, it runs correctly.  FWIW, the example code uses "made up" values - it isn't a real threading operation. 

G0 G40 G18 G54 G80 G50 G90
T202
M3 S600
g94
G0 X0.525
G0 Z4
G0 X0.5
G32 Z3 F0.01

G0 X0.525
G0 Z4

G0 X0.490
G32 Z3 F0.01

G0 X0.525
G0 Z4
M30

2

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: April 03, 2019, 06:52:10 PM »

So I am on to the next issue.  I installed a 3rd channel on the original encoder wheel so it now has A/B and Z for an effective ppr of 400.  G32 now works in Mach 3 but with an odd behavior.  I cannot figure out how to cut a straight thread with no movement in X.  In the tests I'm running, it always wants to move X negative by .100" (running diameter mode so it's moving 0.50 radius).  If I enter an X parameter in the G32, the behavior changes but not to any expected number.  The Z movement appears to be correct.

Any ideas on this?

Thanks,

Mark

3

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: March 31, 2019, 07:54:55 PM »

p.s. again

So with some reading in the UCCNC manual, it looks like the card doesn't use an index pulse at all.  That has a sad and probably unanticipated consequence: it means that you cannot manually pick up and restart cutting a damaged or partially finished thread because you don't have a fixed clocking of the spindle on which the thread started.  Not that important most of the time - just sayin'...

Mark

4

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: March 31, 2019, 07:34:32 PM »

OK - Craig's comment sparked some real progress!  I realized that I have been working without thinking about the interface between Mach 3 and the UC300ETH, particularly relative to signal timing.  After thinking about the timing comment, I went into the UC plugin and entered the (same) input pulse pin into both the A and B spindle encoder fields.  It doesn't work happily since there aren't really A and B signals but it does cause Z motion on a G32 for the first time.  The point is that the timing is entirely handled by the UC300 card.  The UC300 assumes a real encoder and I'll need to install one.  That said, I'm not sure why it wasn't engineered to optionally use a single pulse like Mach 3 but that's a theoretical question at this point...

Anyone know if there is documentation of what encoder inputs the UC300 expects?  PPR, separate index required, etc?

5

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: March 31, 2019, 06:11:16 PM »

p.s. - Maybe it's a timing issue introduced by the Ethernet interface???  I'm not sure I see how that could be but maybe...

6

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: March 31, 2019, 06:08:34 PM »

Sorry, I wasn't clear in my description of the signal I have.  At 500 rpm, it's a pulse that's about 5% duty signal.  By "square wave," I just meant that the signal is clean with square edges as if it had been shaped with a Schmitt trigger rather than the somewhat sinusoidal raw signal off an opto-sensor.  It's a roughly 6ms pulse out of about 120 ms that it takes the spindle to make a revolution at 500 rpm.

--

On a related topic, I don't understand why application of a UC300ETH with Mach 3 requires the use of a full A/B+Index input.  From Mach's viewpoint, what has changed?  Does the UC plugin actually change the Mach 3 trigger code/behavior?  If I understand the default Mach 3 setup instructions, the threading trigger normally functions with a single index input of 200us or longer.  As a related data point, Mach is happily taking the single input pulse and giving me the correct actual spindle speed.

7

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: March 31, 2019, 03:03:50 PM »

...
Do you have a legitimate licence for Mach? If not threading doesn't work in demo mode.
...

Yes, I am using a licensed copy of Mach 3.  Your comment makes me wonder is threading is something that can be "turned on," though.

8

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: March 31, 2019, 03:01:58 PM »

...
So I would try to use simple pulse of 1 pulse/rev.
...

Yes, I'm using a 1p signal about 6ms long at 500 rpm.  The pulse is a clean square wave.

9

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: March 30, 2019, 04:27:52 PM »

p.s. When I run the G32, I can see the waiting for trigger light come on and then go out but there's no axis motion...

10

General Mach Discussion / Mach 3 Threading Hangs

« on: March 30, 2019, 03:22:37 PM »

Hi,

I just retrofit an Emco PC Turn 50 lathe under Mach 3 with a UB1/UC300ETH interface.  I'm using the original index pulse circuit from Emco and I get a very clean square wave about 6ms long at 500 rpm.  The index light lights up on the diagnostics screen when I turn the spindle by hand (the lathe diagnostic plugin appears to be incompatible with the UB1).  When the spindle is running, the index pulse light comes on erratically but a scope on the signal shows the pulses to be very regular.  I can see accurate actual spindle speed and can run feed-per-revolution moves just fine.  When I enter a G32 threading command, though, that block of code just hangs with no axis movement.

I've tried setting the debounce time from zero to the default of 100x40us and it doesn't seem to matter.  Also, have tried spindle speed averaging both on and off with no change.

Any ideas about where to look for the problem?

Thanks,

Mark