Advanced Search

ArcEye wrote:

BIOS should set the parport as EPP for emc

I don't actually think it matters unless you are using the Mesa or Pico cards.

Certainly a problem there will have no bearing on the behaviour of the G-code interpreter

ArcEye wrote:

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

Thanks ArcEye,
i'll change that as soon as i can.

BigJohnT wrote:

Kenneth,

The only way I can replicate your findings is to press the pound key and switch to machine positions...

John

i tried changing views and it did make a difference. changed the preview path from
z-.75" to 0". in actual/relative now.

BigJohnT wrote:

Nope, runs fine on 2.5 too.

On the DRO tab do you have a leftover G92 offset that was not cleared by some other program that you ran?

John

this is at the beginning of all my files, so i'm guessing no ?
dro, all 0....g54 set

g17 g20 g40 g49 g54 g80 g90 g94 g92.1

Kenneth,

The only way I can replicate your findings is to press the pound key and switch to machine positions...

John

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

Nope, runs fine on 2.5 too.

On the DRO tab do you have a leftover G92 offset that was not cleared by some other program that you ran?

John

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.

Kenneth,

I ran the file on the 2.4.2 Axis sim and got the expected retract points... I'll go down to the beer cave and see what 2.5.x does.

John

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

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

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.

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

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

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