Hello Guest it is March 29, 2024, 07:42:04 AM

Author Topic: Mach 3 Threading Hangs  (Read 5164 times)

0 Members and 1 Guest are viewing this topic.

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Mach 3 Threading Hangs
« Reply #10 on: March 31, 2019, 03:05:38 PM »
IF you are using a UC300 controller with Mach3 then you HAVE to have aspindle encoder and an index signal in able to do threading. A single index signal will not work. And then there are problems with some type of threading such as with pullouts and leadin/outs.

Others have tried it but were never successful in it creating a perfect threading function for all type of threading.

Just a thought, (;-) TP

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Mach 3 Threading Hangs
« Reply #11 on: March 31, 2019, 03:08:04 PM »
duplicate answer

Offline reuelt

*
  •  520 520
    • View Profile
Re: Mach 3 Threading Hangs
« Reply #12 on: March 31, 2019, 05:25:43 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.
Sorry, I think a pulse cannot be a square wave. A pulse is like a short spike. You generate 1 spike when the headstock turns 1 revolution e.g. using a hall-effect device.
At 500rpm you should see 500 spikes per minute on the Oscilloscope and NEVER a square wave.
« Last Edit: March 31, 2019, 05:30:30 PM by reuelt »
"the gift of God is eternal life through Jesus Christ our Lord"
Re: Mach 3 Threading Hangs
« Reply #13 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.

Re: Mach 3 Threading Hangs
« Reply #14 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...
Re: Mach 3 Threading Hangs
« Reply #15 on: March 31, 2019, 06:23:15 PM »
Hi,

Quote

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...

No, it can't be. The UC300 handles threading timing at the hardware level itself. Mach supervises but due to
communication delay it cannot initiate a threading pass, that has to be critically timed by the UC300.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Mach 3 Threading Hangs
« Reply #16 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?
Re: Mach 3 Threading Hangs
« Reply #17 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
Re: Mach 3 Threading Hangs
« Reply #18 on: March 31, 2019, 08:40:07 PM »
Hi,

Quote
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...

Remember that the UC300 is made by CNCDrive and is tailored to use with UCCNC software, a direct competitor to Mach.
To my knowledge UCCNC does not have lathe specific operations and single point lathe threading was not required.

The important point here is that as you have now gathered that the controller enacts the threading and timing of it,
not Mach.

This is the broad principle of  buffered control. A Windows PC has that much going on inside it using the interrupt system that it
cannot respond instantly to external events like index pulses. As such it is not a realtime system. The best a Windows PC can do
is generate a series of instructions, called the trajectory planner, and issue a stream of them to a buffer of several
hundred (or thousand) instructions to be consumed and executed by a controller which is by necessity a realtime device.
The hope is that despite the PC not continuously producing instructions the buffer has 'enough to go on with' and that
it doesn't run out before the PC gets back into gear. All PC based CNC software solutions are of this buffered type.

But what about Mach's parallel port I hear you ask? In the early days Art Fennerty wrote a bunch of code that lived
in the kernel at level 0 and it could (almost) take complete control of the CPU and he caused it to generate
pulse streams and do things like lathe threading which requires realtime support. This became known as the parallel port.
In truth it is very much more than that and an exceptionally clever piece of work. Art was kind enough to share
that code with a burgeoning hobby CNC community for free. It was this ability to use a Winows PC as a quasi realtime device
cheaply that allowed Mach to build up such a huge user base.

So when you run Mach3 with a parallel port you actually have two pieces of software running, Mach3 the Windows application
and Mach3's Pulse Engine/Parallel Port Driver.

Despite being very clever the parallel port is somewhat of a bottle neck and that provided fertile ground for external controllers
like the UC300 and the SmoothStepper. They relieve the PC of the realtime tasks and the controller assumes responsibility
for those tasks. You have encountered a controller that does not perfectly emulate the parallel port.

Just as a matter of completeness LinuxCNC IS a realtime system. This comes about because certain Linux distros
have Real Time Extensions which allow a CPU to respond to external events within a few microseconds. Given that Linux
and LinuxCNC are free and open source and enjoy a level of flexibility because it is a realtime system explains why it
is so popular with CNCers.

Back to your UC300. It would appear that you can thread but can only do one pass because of the synchronization problem.
Does you lathe have the rigidity and grunt to cut a thread in one go?

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'

Offline reuelt

*
  •  520 520
    • View Profile
Re: Mach 3 Threading Hangs
« Reply #19 on: March 31, 2019, 10:05:31 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.



OK
Thanks for your explanation.
Engineering-wise people don't refer a pulse to a "square-wave".
"Square Wave Waveform (by definition) is symmetrical in shape and has a positive pulse width equal to its negative pulse width resulting in a 50% duty cycle".

UCCNC - not good enough for lathe - turning. Does not support G32 only G76 in threading
MACH4 - Does not support G32 only G76. BUT UC300ETH does not support MACH4 THREADING using G76.
So the threading in MACH3 supporting both G32 and G76 are all MACH3 features and has not much to do with UC300ETH.
If it is me,
I would try to satisfy MACH3's necessary conditions even though an external motion controller is used
The people in Europe do not do threads based on TPI (which is a superior Imperial design)  That may be why CNCDRIVE people maybe trying harder because metric threads have very different inferior design. Rotate a 1.6mm metric thread 16 times - you get 25.6mm which is NOT = 1 inch. Rotate a 16tpi thread 16 times and you get exactly 1 inch.





"the gift of God is eternal life through Jesus Christ our Lord"