Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: mmcdade 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
-
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...
-
Hi,
I have no experience with threading so cannot offer a solution.
I do now however that the LED on the diagnostics screen will never be able to keep pace with the index signal.
It sounds like you have made considerable effort to ensure a clean index signal and that the index LED operates
as it should when turned by hand. Even more, when running that the spindle speed should be accurately displayed
and feed per turn work correctly all suggest that the index signal is good notwithstanding the intermittent operation
of the LED.
Craig
-
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
Since threading was written for the parallel port, could it STILL be expecting a slow pulse signal of only "1 pulse/rev"?
Art Fenerty said:
"when you consider Mach3 was designed for the printer port, and its
architecture is derived from the treacherous territory of Windows kernel mode, then it
will be understood more easily, why the design architecture, which has evolved over
time, must reflect the original printer port operation in terms of its internal limitations.
This means that the simple fact you are using an external engine does not mean you
will not necessarily have a limitation enforced by the original specifications of the
software."
So I would try to use simple pulse of 1 pulse/rev.
-
Hi,
I'm pretty sure that the UC300 supports lathe threading but are you sure it supports G32?
Could it be that the UC300 is expecting G76?
Do you have any documentation from CNCDrive as to exactly what is supported and how?
Craig
-
UCCNC (unlike MACH3) does use G76 (instead of G32) for Thread Cutting.
But listen to the horse's mouth...
"Post by cncdrive ยป Wed Jun 06, 2018 9:28 pm
We advice to not to use the UCCNC on lathes, because several lathe functions are missing for comfortable lathe usage.
With Mach3 the syncronous thread cutting is working, but there are a few bugs in Mach3 about the thread cutting which can cause issues with some type of thread cutting codes. (I can't remember at the moment which are the cases.)
With Mach4 the UC controllers can't cut threads. We have tried to implement thread cutting some time ago, but found out that it did not work at all on the Mach4 side, so we gave up on it.
Later it was reported to be fixed, but we could not find the time yet to make another try.
With the UCCNC the syncronous thread cutting works perfectly, but again there are missing lathe functions..."
-
I think "cncdrive" was taking about some types of "Metric screw threads" used in Europe & elsewhere, that MACH3 doesn't support.
Mach3 should have no issues threading all Imperial Threads (based on TPI) and most common metric threads.
Correct me if I am wrong.
-
Do you have a legitimate licence for Mach? If not threading doesn't work in demo mode.
-
...
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.
-
...
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.
-
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
-
duplicate answer
-
...
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.
-
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.
-
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...
-
Hi,
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
-
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?
-
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
-
Hi,
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
-
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.
-
Hi,
MACH4 - Does not support G32 only G76
Incorrect, Mach4 supports three Gcodes for threading, g32, g34 and g76 as detailed in LatheGcodeProgramming.pdf
in the Docs folder.
Note that just because Mach, be it Mach3 OR Mach4 supports a Gcode the motion controller is still the device which
enacts it. From OP's account he has discovered that the UC300 does not synchronize thread re-starts....a bit of a problem.
Other motion controllers do support it, in Mach3 the parallel port does, as does the ESS, 57CNC and Hicon.
In Mach4 the ESS, PMDX_424, 57CNC and Hicon all support lathe threading but NOT the Darwin parallel port.
Craig
-
The uc300 requires an A/B encoder and a single spindle pulse per rev. The encode signals tell teh UC300 what direction the spindle is turning and at what speed. The single spindle index signal sets teh starting point of the thread.
From what I remember from testing all this years ago Mach3 threading with a uc300 worked OK . There were just a few quirks to contend with on certain types of threading.
You can turn threads just fine with UCCNC and the uc300 or the uc400. Being it is encoder controlled you always have perfect thread pitch control.
Last I knew Mach4 cannot thread with a uc300 due to plugin restrictions
(;-) TP
-
Hi,
MACH4 - Does not support G32 only G76
Incorrect, Mach4 supports three Gcodes for threading, g32, g34 and g76 as detailed in LatheGcodeProgramming.pdf
in the Docs folder.
Craig
Craig, you are only HALF RIGHT
Copied from the Doc...
G32 1 Threading* N 31
G34 1 Variable Lead Threading* N 33
G35 1 Clockwise Circular Threading* N 34
G36 1 Counterclockwise Circular Threading* N 34
Didn't you notice the * marks?
It means Mach4 Hobby version users will have only G76.
-
Hi,
really, pages 7 and 8 of the Mach4Lathe.pdf...
Craig
-
Hi,
really, pages 7 and 8 of the Mach4Lathe.pdf...
Craig
Exactly what I am saying.
Only G76 does NOT have "*" mark
It means G32 G34 G35 G36 are ONLY available if you pay $1,400 for the Mark 4 Industrial Version??
-
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
-
Hi,
could it be that when the G32 move is executed it is in incremental mode?
If that were the case then the X parameter in the G32 line of code would be X0.0 for a constant diameter thread,
any other X parameter would cause an increase or decrease in diameter.
May I suggest putting a G90 prior to the line containing G32.
Craig
-
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