Messages

2731

Mach4 General Discussion / Re: incremental mode, absolute movements in cycles

« on: April 01, 2019, 04:42:22 PM »

Hi,
I think you are misinterpreting what the G82 command does, its not a fault of Mach nor your controller.

Note in the manual that g82 is the same as g81 but with dwell at the bottom of the hole. The picture attached
is the diagrammatic description of how g81 works.

Your initial point is 29 mm above the material.
The first movement is the rapid from its initial point to the retract plane which you have specified as -15.25mm
BELOW the surface of the material. Note the retract plane is NOT a RELATIVE move, but an absolute one.

Try this code:
g82 x0 y0 z-2.65 r5 p0.06 f56

Now what will happen is that the first move will be a rapid from its initial 29mm to 5mm above the surface then
drill to a depth of 2.65mm below the surface at a feed rate of 56mm/min then dwell then retract at rapid rate to 5mm
above the surface.

Note also that I have deliberately coded all letters as lower case and stripped out all leading zeros.
The Gcode interpreter does just exactly that, so it would convert G082 to g82 for instance. Usually this
happens without fault but every once and a while it fails and you end up with a weird fault which is really hard
to spot. As a consequence I am slowly getting into the habit of lowercase letters and no leading zeros.
Note the interpreter also strips out white space but I find it just too hard to read without blank spaces.

Another trap is that the Gcode interpreter expects a certain number of arguments and if it does not get them it
can fail. In this regard Mach3 was quite slack. For instance this was acceptable in Mach3:

g82 x0 y0 z-2.65 r5 p0.06 f56
g82 x10 y10
g82 x20 y20

but it would fail in Mach4 because if it encounters a canned cycle declaration it requires all parameters to be on that
line. In the code snippet above the second and third lines are effectively new definitions of the canned cycle and as
such require complete parameters. This is how you would code it in Mach4:

g82 x0 y0 z-2.65 r5 p0.06 f56
x10 y10
x20 y20
g80

So the g82 canned cycle is MODAL and therefore the second line repeats the g82 cycle but with x and y parameters
only modified to 10 and 10 and all remaining parameters stay the same. The g80 at the end concludes the cycle.

In interest of completeness I would add the 'l' parameter to the coded line. I believe however a l parameter of 1
works because each time the canned cycle is executed it gets called anew. If you had l=2 then the hole would be
drilled twice but in the same location.

g82 x0 y0 z-2.65 r5 p0.06 f56 l1

Mach4 is somewhat stricter about canned cycles whereas mach3 was slack.

Craig

2732

Mach4 General Discussion / Re: Using the Serial plugin from a macro

« on: April 01, 2019, 04:02:16 PM »

Hi,
I'm not familiar with the serial port plugin.

I set up a trial port, seems to work OK.

Would you explain what CoolTerm is?

I imagine that you send/receive data for the port using registers like you would with Modbus. If that's
the case then writing some code to update the registers should be easy enough.

Craig

2733

Mach4 General Discussion / Re: hold all axis also on jog

« on: April 01, 2019, 03:46:04 PM »

Hi,
how about having a test in the PLC script that if the machine is not Homed then the
feed rate override, the raid rate override and jog seed are all set to zero?

Code: [Select]

local inst=mc.mcGetInstance()
local homedX=mc.mcAxisIsHomed(inst,mc.X_AXIS)
local homedY=mc.mcAxisIsHomed(inst,mc.Y_AXIS)
local homedZ=mc.mcAxisIsHomed(inst,mc.Z_AXIS)
local homed= homedX and homedY and homedZ
if (homed ==0)then
mc.mcCntlSetFRO(inst,0.0)
mc.mcCntlSetRRO(inst,0.0)
mc.mcJogSetRate(inst,mc.X_AXIS,0.0)
mc.mcJogSetRate(inst,mc.Y_AXIS,0.0)
mc.mcJogSetRate(inst,mc.Z_AXIS,0.0)
end
Craig

2734

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: April 01, 2019, 01:49:33 AM »

Hi,
really, pages 7 and 8 of the Mach4Lathe.pdf...

Craig

2735

Mach4 General Discussion / Re: How do I make the Extents mode visible

« on: April 01, 2019, 12:28:41 AM »

Hi Smurph,
all very kool.

I'm going to experiment with the tool path and see what happens. You pegged me correctly, I don't have the first
idea about using OpenGL, if I can't use a solution like Machs tool path then my idea will probably progress.

I find that I have to reduce the acceleration of my machine because it tends to shake itself and wander around the bench
despite the steppers being capable of rather more. It may be that a 3rd order planner would tame it somewhat, I loo
forward to it.

Craig

2736

Mach3 under Vista / Re: Internet and license

« on: March 31, 2019, 10:36:57 PM »

Hi,
no trouble Ron.

In Mach3 each licensed user gets one license file. You could copy it and put that into as many Mach3 PC's as you like.
This has indeed been a problem for NFS, with one pirate license file turning up on thousands of PC's around the globe,
none of which have been paid for.

Mach4 licensing is different. Each PC has a unique PCID, identity code. A Mach4 license is issued for that C only. If you copied
it and stick it in another PC it wont work. If you buy Mach4 you may have up to five actively licensed machines. If one of them
craps out and you buy another PC with a  unique PCID, you go to the NFS website and release the old license from the PCID of
dud PC and get a fresh license for your new PC. You are allowed seven such license transactions in a two year period.
So it pays not to be profligate with them! Still should be plenty flexible enough for a hobby user.

Craig

2737

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: March 31, 2019, 10:18:30 PM »

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

2738

Mach3 under Vista / Re: Internet and license

« on: March 31, 2019, 10:06:27 PM »

Hi,
is the licence for Mach3 or Mach4?

If its for Mach3 just download the licence file on any Internet connected PC, copy the licence file to a thumb drive
and load it into the Mach3 Directory on the target PC.

If its for Mach4 then you need to get the PCID from the target PC. Paste it onto a thumb drive.
On any Internet connected PC supply the PCID to the NFS self managed licence page and wait for the licence file
to be emailed to you, usually a few minutes. Transfer the licence file form the connected PC to the target PC in
the Mach4Hobby/Licenses folder.

Craig

2739

General Mach Discussion / Re: Mach 3 Threading Hangs

« on: March 31, 2019, 08:40:07 PM »

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

2740

General Mach Discussion / Re: Mirror probing

« on: March 31, 2019, 07:56:09 PM »

Hi Don,
I had these switches in mind:

https://nz.element14.com/honeywell/bzc-2rq1-a2/switch-basic-top-pin-plunger/dp/1525197

Note this is the New Zealand site of Element14 so the price is in NZD. Works out to about $13 USD. Element14
I think might be called Newark in the US.

I thought that if you could drill a small hole in the plunger and glue in a 1/8 bit of wire as a probe extension.
All three switches could be attached to a flat plate of some description which would have a shank that fitted
in your spindle.

These switches are pretty good quality and 'guess' you could get 0.001 repeatability with them. One of the features of
these switches is about 5mm of overrun. That is the travel that the plunger can make AFTER the switch event without
bottoming out and damaging itself.

As you can see I'm thinking that you could make a thee axis probe for under $50. I imagine that there would be some
coding required, but that is time and brain power intensive, no dollars involved!

Craig