Wrong G81 Z retract

andypugh wrote:

I wonder if the % at the beginning is cancelling a modal G98 code somehow?

I thought that G99 was the default behaviour unless you specifically programmed a G98?

There is no G98 or G99 in plasdoms code and my simulator shows G99 as the active G-Code.
The movement I saw coincides with that retraction model.

However I think I have solved the mystery.

The code does not start anywhere, just jumps straight into G81.

If you place Z at 2" before calling G98, the program retracts to Z2 every time after drilling a hole

regards

eg

g17 g20 g40 g49 g54 g80 g90 g94

G0 Z2
G98

g81 f8 x.225 y-.125 r.08 z-.02

Cool, but this is an old file i use many times. never changed anything
til it went coco:). i added the below to the start. retracts to where it
should but plot is wrong on bottom holes. shows z0, but runs at z-.75.
added g99 to below and plot shows correct path.

g17 g20 g40 g49 g54 g80 g90 g94 g92.1
(C-Drilling)
m6 t5
g0 x.1 y.1
z.2
g81 f8 x.225 y-.125 r.08 z-.02

p.s. i have no % in file

i tried g98 below and the plot changed back to wrong retract on
bottom holes. and all holes retract to 2". if g98-99 are for z retract,
what is the 'r' for in g81? used g81 for two years now, first time
all goes coco:)

g17 g20 g40 g49 g54 g80 g90 g94

G0 Z2
G98

g81 f8 x.225 y-.125 r.08 z-.02

ran dmesg and found below. this could be my trouble ?




[ 195.229143] RTAPI: ERROR: Unexpected realtime delay on task 1
[ 195.229163] This Message will only display once per session.
[ 195.229164] Run the Latency Test and resolve before continuing.
[ 676.316260] PNPBIOS fault.. attempting recovery.
[ 676.316263] PnPBIOS: Warning! Your PnP BIOS caused a fatal error. Attempting to continue
[ 676.316265] PnPBIOS: You may need to reboot with the "pnpbios=off" option to operate stably
[ 676.316267] PnPBIOS: Check with your vendor for an updated BIOS
[ 676.316270] PnPBIOS: set_dev_node: unexpected status 0x3a
[ 676.316272] probe_parport 00:0b: disable failed
[ 676.396251] RTAI[math]: unloaded.

Another thing to sort out, but I can't see how, not going to change how G81 picks up the Z axis position.

What I found goes back to what Andy said at the beginning

My impression was that it would always retract to the last G1 Z position, not anywhere jogged to. I didn't check G0.

It looks like G81 uses the last linear move to a position for Z and does not read it's actual position.
It would anticipate a move like G0 X0 Y0 Z2 as a precursor to any G81 canned cycle

If you move to a location by jogging and then run G81, as effectively your program does, it has no Z position set by a move and it acts as observed.

regards

just wondering if the developers changed something or if something
changed on my comp i don't know about. if i use below, file runs as should.
doesn't use .2" as retract.. uses .08"

g17 g20 g40 g49 g54 g80 g90 g94 g92.1 g99
(C-Drilling)
m6 t5
g0 z.2

g81 f8 x.225 y-.125 r.08 z-.02


and i seen epp somewhere and saw it today in the bios.

selections;
normal
bi-directional
ecp
epp
ecp & app

set at bi-dir.. does this matter to emc or is this
for printers ?

Thanks
kenneth

Thanks John,
maybe i should go back to 2.4 ?



kenneth

p.s. got 2.5 to use glade, but somein rong.
don't really need now.

and i seen epp somewhere and saw it today in the bios... set at bi-dir.. does this matter to emc or is this for printers ?

BIOS should set the parport as EPP for emc

Bi-directional is for older printers and devices to be able to report back ink levels, confirm ready for next data packet etc. as far as I am aware.
Was overtaken by IEEE 1284 ECP for most new printers.

Whilst EPP is bi-directional, there is a different protocol.

regards