Discussion:
won't start on line 310 (run from here)
(too old to reply)
Stuart Stevenson
2017-06-05 20:56:53 UTC
Permalink
Raw Message
Gentlemen,

Debian Wheezy
latest linuxcnc release - installed today - but the last release did the
same thing
Axis interface
Kasuga 3 axis mill

when starting (run from here) on line 310 I get the error "length of cutter
compensation entry move is not greater than the tool radius"

This only happens when I 'run from here'.
When running through the program the machine runs this code just fine. I
cannot run through the program as I must change tools in the holder - set
the tool length - and - start by picking 'run from here' (right click on
the mouse).

status window shows G40 prior to initiating 'run from here'
after initiating 'run from here' the error shows and the status window
shows G41
mdi g40 resets the status window
reinitiation of 'run from here' shows the error and sets the status window
to G41

Editing the G41 and G40 out of the program allows 'run from here' to start
the machine and run the tool.

snippet of code from the program

N288X.1684Y-.6104
N289G01Z.105F100.0
N290G41X.0024F4.0
N291Y-1.428
N292G40
N293X.1024
N294G00Z1.115
N295M05
N296M09
N297G91G28Z.0
N298(MSG)
N299(MSG TOOL T4.0000 IS)
N300(MSG DIA 0.5000)
N301(MSG CRAD 0.0000)
N302(MSG FLTLEN 0.2500)
N303(MSG STKOUT 0.5000)
N304(MSG)
N305(MSG 1/2 SPOT DRILL.)
N306(MSG)
N307(MSG SPOT DRILL HOLE)
N308(MSG)
N309(MSG)
N310G91G49G28Z.0
N311T04M06
N312G64P.001
N313G90G00G43
N314S1400M08
N315X1.375Y-3.0M03
N316Z1.115
N317X-.3Y-.1
N318G81X-.2Y-.2Z.075R.275F2.0
N319G80M05
N320M09
N321G91G28Z.0

thanks
Stuart
--
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.
Jon Elson
2017-06-05 22:32:26 UTC
Permalink
Raw Message
Post by Stuart Stevenson
Gentlemen,
Debian Wheezy
latest linuxcnc release - installed today - but the last release did the
same thing
Axis interface
Kasuga 3 axis mill
when starting (run from here) on line 310 I get the error "length of cutter
compensation entry move is not greater than the tool radius"
This only happens when I 'run from here'.
When running through the program the machine runs this code just fine. I
cannot run through the program as I must change tools in the holder - set
the tool length - and - start by picking 'run from here' (right click on
the mouse).
status window shows G40 prior to initiating 'run from here'
after initiating 'run from here' the error shows and the status window
shows G41
mdi g40 resets the status window
reinitiation of 'run from here' shows the error and sets the status window
to G41
Editing the G41 and G40 out of the program allows 'run from here' to start
the machine and run the tool.
The displayed status is NOT the current status of the interpreter, it is
the status of the screen preview, which has normally run to the end of
short programs. When doing run from line, you have to be careful to
clear any mode settings like tool length/radius compensation, arc
planes, absolute/incremental, circular arcs, etc. to the right setting
for the following lines.

There have been times I couldn't figure out what crazy mode I got in,
and just restarted LinuxCNC instead of fooling around longer.

Jon
Jon Elson
2017-07-01 22:50:07 UTC
Permalink
Raw Message
A guy brought me an HP elite 8300 desktop machine that he
was having trouble getting working with a stepper controller.
After trying a few things with no result, I put a scope on
the parallel port. What I see is a pulse every 33 ms on pin
1, which is the old parport data strobe. I shut down all
modules such as lp, parport, parport_pc and ppdev, and it is
still doing it. So, some BIOS code or kernel module seems
to be talking to the parallel port card. That is a PCIe
Netmos 9900 chip, which I've used on a bunch of Dell boxes
with no trouble.

Does anybody have any idea what module might be doing this?
(and, how to turn it off)

Thanks,

Jon
Jon Elson
2017-07-01 23:29:42 UTC
Permalink
Raw Message
Post by Jon Elson
A guy brought me an HP elite 8300 desktop machine that he
was having trouble getting working with a stepper controller.
After trying a few things with no result, I put a scope on
the parallel port. What I see is a pulse every 33 ms on
pin 1, which is the old parport data strobe. I shut down
all modules such as lp, parport, parport_pc and ppdev, and
it is still doing it. So, some BIOS code or kernel module
seems to be talking to the parallel port card. That is a
PCIe Netmos 9900 chip, which I've used on a bunch of Dell
boxes with no trouble.
Does anybody have any idea what module might be doing
this? (and, how to turn it off)
Actually, I counted wrong, it is pins 14 and 17, which are
the EPP datastrobe and addrstrobe pins.

Jon
Gene Heskett
2017-07-02 00:52:56 UTC
Permalink
Raw Message
Post by Jon Elson
A guy brought me an HP elite 8300 desktop machine that he
was having trouble getting working with a stepper controller.
After trying a few things with no result, I put a scope on
the parallel port. What I see is a pulse every 33 ms on pin
1, which is the old parport data strobe. I shut down all
modules such as lp, parport, parport_pc and ppdev, and it is
still doing it. So, some BIOS code or kernel module seems
to be talking to the parallel port card. That is a PCIe
Netmos 9900 chip, which I've used on a bunch of Dell boxes
with no trouble.
Does anybody have any idea what module might be doing this?
(and, how to turn it off)
I would first look in the bios for likely suspects, but I expect you
have, and failing that, see if there is an even newer bios for that
board. I've solved odd-ball stuff 3 or 4 times with a bios update.
Post by Jon Elson
Thanks,
Jon
----------------------------------------------------------------------
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Jon Elson
2017-07-02 01:54:24 UTC
Permalink
Raw Message
Post by Gene Heskett
I would first look in the bios for likely suspects, but I expect you
have, and failing that, see if there is an even newer bios for that
board. I've solved odd-ball stuff 3 or 4 times with a bios update.
I definitely don't want to get involved in BIOS updates on
somebody else's computer, but you may well be right!
Anyway, instead of the PCIe card, I tried a VERY old PCI
card, and it works perfectly. So, it looks like some crazy
interaction between the BIOS and the NetMos 9900 chip on the
PCIe parport card.


I did try turning off some options in the BIOS, and managed
to completely turn off the PCI slots, but that was about the
only effect I was able to have. This is the first time I've
seen something this crazy. I can't imagine what function
would be pinging the parport every 33 ms, unless it just
didn't configure properly at all.

Jon
Gene Heskett
2017-07-02 04:00:01 UTC
Permalink
Raw Message
Post by Jon Elson
Post by Gene Heskett
I would first look in the bios for likely suspects, but I expect you
have, and failing that, see if there is an even newer bios for that
board. I've solved odd-ball stuff 3 or 4 times with a bios update.
I definitely don't want to get involved in BIOS updates on
somebody else's computer, but you may well be right!
Anyway, instead of the PCIe card, I tried a VERY old PCI
card, and it works perfectly. So, it looks like some crazy
interaction between the BIOS and the NetMos 9900 chip on the
PCIe parport card.
If your memory is better than mine Jon, you'll recall I pitched a netmos
parport card with a boomerang flip, but then I'd never had a boomerang
come back yet. That was the intention, and a $15 Startech fixed things
right up. Must have been about the time I set up the micro-mill at
least a dozen years back. Other stories this list has exposed over the
years have convinced me to never ever put my fingerprints on the box
when I could buy this stuff at Staples. But memories fade, and I expect
thats the case here. :(
Post by Jon Elson
I did try turning off some options in the BIOS, and managed
to completely turn off the PCI slots, but that was about the
only effect I was able to have. This is the first time I've
seen something this crazy. I can't imagine what function
would be pinging the parport every 33 ms, unless it just
didn't configure properly at all.
I didn't see anything in the logs that I can recall now, might have been
a try something else for S & G, and it worked. I tend to have a better
memory for that sort of thing. You mention netmos and those memories
suddenly connect again.

Glad you got it fixed Jon, and now of course you are THE magician to that
machines owner. :) I rather enjoy those sorts of feelings myself. :)
Post by Jon Elson
Jon
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Jon Elson
2017-07-02 17:50:06 UTC
Permalink
Raw Message
Post by Jon Elson
I definitely don't want to get involved in BIOS updates on
somebody else's computer, but you may well be right!
Anyway, instead of the PCIe card, I tried a VERY old PCI
card, and it works perfectly. So, it looks like some crazy
interaction between the BIOS and the NetMos 9900 chip on the
PCIe parport card.
The NEtMos 9805 chip is admittedly pathological, even in the
manufacturer's data sheet.
later PCI chips apparently fixed those bugs. I tried 3
different PCIe parport cards in that HP machine, none of
them worked. I tried another PCI card, which enumerates as
a serial/parallel card in several other systems, the HP
discovered the card, said it was serial only, and was not
able to enumerate it (the lspci -v listing showed no
addresses associated with the card). So, I think the BIOS
in that machine really DOES have problems.
Post by Jon Elson
Glad you got it fixed Jon, and now of course you are THE
magician to that machines owner. :) I rather enjoy those
sorts of feelings myself. :)
Yeah, I really DON'T like all this magic! If I had known,
in 2001 when I started the PPMC project, that the biggest
hassle in the whole thing was going to be the vagaries of
different parallel port chips/cards, I would have backed
away from it. I've gone through all sorts of hell with
various motherboard, chip and card problems. The EPP cycle
requires the CPU to go to a wait state until the cycle
completes. I had one that probably had a defect in the
motherboard, where the CPU would not wait for the handshake,
and just roared ahead. No way I could fix that kind of
bug. It settled down for a while with PCI cards, but then
I ran into this issue with the PCIe cards recently. I was
not using the right software sequence to control the port.
But, the REAL issue is, there is no definitive document that
tells how to operate an EPP port! Everybody invents his own
code, and tries it on a few cards, and hopes that it is
right. UGH!!!

Jon
Gene Heskett
2017-07-02 23:37:17 UTC
Permalink
Raw Message
Post by Jon Elson
Post by Jon Elson
I definitely don't want to get involved in BIOS updates on
somebody else's computer, but you may well be right!
Anyway, instead of the PCIe card, I tried a VERY old PCI
card, and it works perfectly. So, it looks like some crazy
interaction between the BIOS and the NetMos 9900 chip on the
PCIe parport card.
The NEtMos 9805 chip is admittedly pathological, even in the
manufacturer's data sheet.
later PCI chips apparently fixed those bugs. I tried 3
different PCIe parport cards in that HP machine, none of
them worked. I tried another PCI card, which enumerates as
a serial/parallel card in several other systems, the HP
discovered the card, said it was serial only, and was not
able to enumerate it (the lspci -v listing showed no
addresses associated with the card). So, I think the BIOS
in that machine really DOES have problems.
Post by Jon Elson
Glad you got it fixed Jon, and now of course you are THE
magician to that machines owner. :) I rather enjoy those
sorts of feelings myself. :)
Yeah, I really DON'T like all this magic! If I had known,
in 2001 when I started the PPMC project, that the biggest
hassle in the whole thing was going to be the vagaries of
different parallel port chips/cards, I would have backed
away from it. I've gone through all sorts of hell with
various motherboard, chip and card problems. The EPP cycle
requires the CPU to go to a wait state until the cycle
completes. I had one that probably had a defect in the
motherboard, where the CPU would not wait for the handshake,
and just roared ahead. No way I could fix that kind of
bug. It settled down for a while with PCI cards, but then
I ran into this issue with the PCIe cards recently. I was
not using the right software sequence to control the port.
But, the REAL issue is, there is no definitive document that
tells how to operate an EPP port! Everybody invents his own
code, and tries it on a few cards, and hopes that it is
right. UGH!!!
Jon
I've done some googlesnooping on that very faint trail myself, a fair
amount of time back though, and came up just as empty.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Valerio Bellizzomi
2017-07-02 06:20:00 UTC
Permalink
Raw Message
Post by Jon Elson
A guy brought me an HP elite 8300 desktop machine that he
was having trouble getting working with a stepper controller.
After trying a few things with no result, I put a scope on
the parallel port. What I see is a pulse every 33 ms on pin
1, which is the old parport data strobe. I shut down all
modules such as lp, parport, parport_pc and ppdev, and it is
still doing it. So, some BIOS code or kernel module seems
to be talking to the parallel port card. That is a PCIe
Netmos 9900 chip, which I've used on a bunch of Dell boxes
with no trouble.
Does anybody have any idea what module might be doing this?
(and, how to turn it off)
Thanks,
Jon
have you tried to turn off acpi support in the bios ?
Bertho Stultiens
2017-07-02 08:42:05 UTC
Permalink
Raw Message
Post by Valerio Bellizzomi
Post by Jon Elson
So, some BIOS code or kernel module seems
to be talking to the parallel port card. That is a PCIe
Netmos 9900 chip, which I've used on a bunch of Dell boxes
with no trouble.
Does anybody have any idea what module might be doing this?
(and, how to turn it off)
have you tried to turn off acpi support in the bios ?
Could it be that the card is in ECP mode (instead of EPP) and there is a
device auto-detect process probing the port at intervals?
--
Greetings Bertho

(disclaimers are disclaimed)
Jon Elson
2017-07-02 17:53:59 UTC
Permalink
Raw Message
Post by Bertho Stultiens
Post by Valerio Bellizzomi
Post by Jon Elson
So, some BIOS code or kernel module seems
to be talking to the parallel port card. That is a PCIe
Netmos 9900 chip, which I've used on a bunch of Dell boxes
with no trouble.
Does anybody have any idea what module might be doing this?
(and, how to turn it off)
have you tried to turn off acpi support in the bios ?
Could it be that the card is in ECP mode (instead of EPP) and there is a
device auto-detect process probing the port at intervals?
Well, there is BIOS support for on-mobo ports, which this
machine does not have. The BIOS support for PCIe plug-in
cards should handle PCI PnP enumeration and then leave it
alone, I would think.

Anyway, 3 different PCIe ports all malfunction in various
ways, and another PCI card is misidentified and doesn't
enumerate, so their BIOS seems to be pretty pathological. I
finally found ONE PCI card that does work.

Jon
Jon Elson
2017-07-02 17:50:55 UTC
Permalink
Raw Message
Post by Valerio Bellizzomi
Post by Jon Elson
A guy brought me an HP elite 8300 desktop machine that he
was having trouble getting working with a stepper controller.
After trying a few things with no result, I put a scope on
the parallel port. What I see is a pulse every 33 ms on pin
1, which is the old parport data strobe. I shut down all
modules such as lp, parport, parport_pc and ppdev, and it is
still doing it. So, some BIOS code or kernel module seems
to be talking to the parallel port card. That is a PCIe
Netmos 9900 chip, which I've used on a bunch of Dell boxes
with no trouble.
Does anybody have any idea what module might be doing this?
(and, how to turn it off)
Thanks,
Jon
have you tried to turn off acpi support in the bios ?
They didn't list it as such, but there were power management
options. That did not help.

Thanks,

Jon
Loading...