Hello,

our company have build a few plasma machines under mach3 control, using the Purelogic PLCM E3 controller and their THC, this works pretty good.
We also made our own screenset for it, completely from scratch with all kind of macro's etc.

In the past I had some issues with G31 in a macro moving the wrong axis. Instead of Z-down it was moving X to the right.
I found out that the button that switches between work and machine coordinates was giving this problems, the machine had to be on work coordinates. So I removed the button from the screenset and changed the homing routine to have it always set to work coordinates.
If GetOemLED(16) Then
DoOemButton(256)
End IfSince then never had any problems with G31 on any of our machines again.

Now we have a new customer, and the machine sometimes has this problem again.
We have a M900 macro for finding the plate surface, move to ignition height, start the torch, move to pierce height, wait during pierce delay and then move to cutheight.
This is our G31 line. It tells the machine to probe to a maximum depth we want, at a certain speed.

Code "G0 G53 Z" &ProbeStart 'Move to startheight of probing, in machine coordinates
ProbingMax = CurrZ - ProbingDepth 'Max probing movement based on current Z-position
SetUserLED(Platesearch, 1) 'Set Platesearch active LED, to override lifter error in macropump
SetUserLED(O_Plasma_Safety_Relay, 1) 'Enable the plasma safety relay
sleep(200) 'Wait for the relay to be enabled
Code "G90 G31 Z" &ProbingMax & "F" & ProbingFeed 'Probe with max movement and probing speedSometimes after a few parts, the machine suddenly starts searching for the plate on the X-axis instead of the Z-axis. The machine then goes all the way left to the hardware limitswitch, and gives a Cypress Enable Error in Variable: GetCtxtr... because it can't finish the macro.

Why is it sometimes moving in the wrong direction? In the past it was the button work/machine coordinates, but that is already eliminated. What else can cause these errors?

Hi,
I can't answer your question but have learnt something that may help you get a handle...

This comes from Mach4 but Mach3 I believe operates identically. When Mach encounters a G31 it interprets it as a G1, ie a linear interpolated
move to the 'end' co-ordinates contained in the G31. Commonly we call G31 and do not wish any movement in X or Y just in the negative Z
direction. When the probe strikes the remainder of the move is aborted and the current position is returned to Mach.

We dot not as a rule specifically mention X or Y in our G31 command but they are implied.
G31 Z-1 F10    is interpreted as
G31 X[current x coord] Y[current y coord] Z-1 F10.

Could it be that the error you describe occurs because the implied X co-ordinate somehow changes?

May I suggest a means of testing this theory would be to re-write your G31 such that the current x co-ordinate is specifically
mentioned, not sure offhand what the pound variable number is for X...

G31 X#nnn  Z-1 F10

Craig

I don't think that is the problem, since the Z-axis isn't doing any movement at all. The machine starts immediately moving in X- direction towards the end switch.

Don't recall a past  post on this and not sure what is causing it.
What version of Mach3 are you using?

RICH

Version R3.043.066, the same we use on all our machines, and it's licensed.

Version 066 has been reported to be buggy and not recommended by many users.
Try .062 and see if it behaves the same way.

RICH