Messages

601

General Mach Discussion / Re: Should we re-install Mach 4

« on: July 24, 2022, 04:34:06 PM »

Hi,

Our cnc is stopping in random places throughout a job. We are having trouble with Mach 4 recognizing the Smart Bob (PMDX) and when we try to restart it, it errors that there is another instance of M4 already running.

This occurs when Mach does not shut down correctly, the GUI hangs up and you cannot restart Mach. The correct procedure is to use Task Manager to end the GUI task, thereafter you'll be
able to start another instance.

Would it be a good idea to uninstall Mach 4 and reinstall it and how would be do that? We've done dry runs with the same results which would seem to indicate that static is not the issue. Thank you.

You could certainly try re-installing Mach, but I think you are clutching a straws, the most likely explanation is the USB connection faulting. Try a very short USB lead maybe, or consider upgrading
to an Ethernet connected motion controller.

Craig

602

Mach4 General Discussion / Re: Jogging multiple Axes

« on: July 22, 2022, 01:06:17 AM »

Hi,
in order to jog two or more axes together precisely would require coordinated movement which in turn requires that Mach offer multi axis trajectory data to the motion controller.

To my knowledge that is not how Mach jogging works.

My understanding is that Mach jogs one axis at a time. What Mach might do is to jog first the X axis  closely followed by the Y axis, and repeat. If this happened often enough
and fast enough you might get the desired effect of two axes moving at once. What would not happen is that one axis would move in a precisely coordinated manner, lets say X moves 50mm and Y
also moves 50mm.

May I suggest that you could write some macros, with each macro enacting a small but coordinated moment, something like this:

m500()
mc.mcCntlGcodeExecute(inst,"g91/n,g1x0.1y0.1/n,g90")
end

Note this is just a sketch, this macro would need a ton of work to run, just the idea is that each time this macro ran the X and Y axes would move 0.1mm in coordinated fashion.
You might have another macro, say m501(), that would go in the other direction. Note also that I transition to incremental mode to execute the move and then transition back to absolute
mode. That's fine if you started in absolute mode but would cock up if you started in incremental mode. In practice you have to test that on each occasion.

Craig

603

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 19, 2022, 05:49:53 PM »

Hi,
Reinshaw have a magnificent reputation, and prices to match. Certainly the circumstances of use preclude the use of a wire, and if
you can alter the probe result after detection then you can recover the accurate position.

Can you afford one of these things? Even second hand?

My probe circuit is two wires with clips, one going to the spindle nose, and the other to the PCB blank, cost....near zero, and repeatability of
several um.

Craig

604

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 19, 2022, 05:29:29 PM »

Hi,
well if you ask me I would say that probe is junk, 40um overtravel before the motion controller detects the event?
Irrespective of whether the position is latched at the probe event OR after the axis is decelerated to a stop....40um is BS.

I probe printed circuit board blanks, inevitably there is some bow or warp that needs be accommodated, the copper layer is only 35um thick
and I require the tool to cut that 35um but do not want it to cut into the substrate. In practice you do have to have some cutting into the substrate to
reliably cut the 35um copper layer. In practice I use a cut depth of 0.08mm, or 80um. With the corrections provide by probing the surface prior to cutting
this results in 100% reliable cutting of the copper layer without unduly cutting into the substrate. For this to work I require the probing to be
10um or better....40um would screw me.

If I used a probe that had 5ms latency then I can kiss making PCBs goodbye.

I have read that much of the latency that these RF probes exhibit is because it can take 5ms for the radio link to synchronise. If it were a straight wired
probe (like the only type I can afford) then there would be no latency, or at least reduced to 10us or less.

Craig

605

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 18, 2022, 05:31:35 PM »

Hi,
maybe UCCNC operates differently however when operating with Mach a UCnnn motion controller latches data when the axis is stopped.
Read the excerpt I posted earlier, that is the instructions o0ffered by NFS as to how a motion controller must handle probing in
order to work with Mach, UCnnn works with Machs g31 probing therefore it must comply with the procedure set out by NFS.

The two motion controllers that I've use are the ESS and Machs parallel port, and both operate identically, namely the trigger event
causes the axis to decelerate to a stop and then the data is latched once still.

Why don't you do some experiments and probe a surface at varying approach speeds. Another way to illustrate what's going on is to  as an experiment,
reduce the z axis acceleration down to 10% of normal and try probing again. In both of these circumstances I would expect the the overtravel
change and therefore the position latched into Mach. If you choose to experiment with a fast approach speed AND a low acceleration you will end up with
overtravel and you'll need some springiness in either the probe or the probed surface to avoid damage.

Craig

606

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 18, 2022, 02:36:51 AM »

Hi,

But it seems a crazy way to do it when it would be simple to just copy the value of the DRO,

Yes, you might think so but trying to latch an 32 bit integer during one clock cycle??? Seems that no-one does so, but rather latch the number
when the axis has stopped. All of the motion controller manufacturers do it that way, including Machs parallel port.

if you were using a Renishaw probe with a delay of 5ms,

So where does this 5ms delay come from....thats BS, you could not possibly achieve anything like accurate probing with that sort of delay.
I would anticipate that the motion controller can start to decelerate the axis within ten microseconds, and the deceleration phase should not last more than
a few hundred microseconds. Total delay from probe trigger to stop less than 500 microseconds, and the value latched into the motion controller register
a few hundred microseconds after that. There may well be a delay of tens of milliseconds before the integer value is reported to Mach, but the delay
in the trigger-decell-latch phase should be well under one millisecond.

Craig

607

General Mach Discussion / Re: Limits Override Problem

« on: July 17, 2022, 07:33:39 PM »

Hi,

I was planning to join their forum but I read in a link that the forum has no traffic and so I didn’t signed up

Rubbish, I've posted on the Warp9 Forum dozens if not hundreds of times over the years, and as recently as a fortnight ago. Andy, Warp9's support person monitors the site
and always replies.

Craig

608

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 17, 2022, 05:27:29 AM »

Hi,

- The value of R and the start position are used to derive the axis point at which the probe triggered - note that this is NOT the same as the final position the axis stopped at because of the inevitable over-travel.

This is incorrect. The motion controller decelerates the axis until it stops. When it is stopped that is the value that is latched into the register. So there IS overtravel
in EVERY probe command. For this reason you want the probe to happen at low speed and have the machine decelerate as fast as possible so that the overtravel is
minimized, but you can't eliminate it.

To give you an example:
My current mill has an acceleration of 1.5m/s². I regularly probe at a feed rate of 100mm/min or 0.0017m/s. The overtravel is:

OT= 1/2 x a x t²  where a is the acceleration and t is the time taken to stop. The time to stop is:
t_stop=v_initial/a
=0.0017/1.5
=0.00067 seconds
OT= 1/2 x 1.5 x 0.00067²
=0.33um

So I expect my machine to overtravel less than 1um when probing from 100mm/min.

If you read closely the excerpt from the Mach4 documentation I posted you will see that the position is latched only when the axis is stopped, and Mach3
behaves exactly the same way and always has.

Craig

609

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 17, 2022, 05:26:06 AM »

Hi,

This post I deleted because I used the wrong value fpr acceleration, see following post.
Craig

610

Mach4 General Discussion / Re: m6 macro

« on: July 16, 2022, 06:56:39 PM »

Hi,
m6 macros are highly dependent on the machine meaning you usually have to write your own m6.
The expectation that you can download and install an m6 from who knows where and have it work is not realistic.

Have you tried running the code in the editor, step by step?

My guess is that this line is not working:

Code: [Select]

mc.mcCntlGcodeExecuteWait(inst, " G91 G31 Z-5. F5.")--probe the new tool

You need to run it in the editor and de-bug it.

Craig