Bug list comments, update

["Keith Rumley" <DSCadCam-at-yahoo.com>]

Matt,

    My comments on the 'bug' list (Running essentially BDI 2.14)

> I think this, or something like it, is inevitable if war between the
> "stickies" and the "transients" is to be averted ;). Personally, I've
always
> used G92 for part zero, and it's been "sticky". When the change to
> "transient" came along I just switched to offsetting the G54 or G55
> coordinate system and didn't touch G92. Although that meant losing the
"right
> click" feature, I was able to use Ray's "Set Coordinates" script as a
> substitute. The bottom line is that I sympathize with both sides. Feel
free
> to comment on the syntax or mechanism for implementing this option... Joel
> also noted that G92 is cleared on an abort as well as M2 & M30 in the new
> interpreter.

The issue I see is that EMC interpreter uses G92 to set offset values
(5211-5216) from the current coordinate system, instead of the machine
coordinate system (home switch zero's/origin, G28/30). Essentially EMC uses
G92 as a temporary coordinate system, local to the coordinate system within
which it was used, but then it arbitrarily applies those local variables
'globally' to ALL the coordinate systems!?

To recap: in EMC, G92 is implementing an OFFSET ORIGIN(stored in 5211-16)
from the CURRENT coordinate system's origin, which makes it twice removed
from machine zero. In my experience that is not typical machine behavior.

IMO G92 is normally expected to set a coordinate system's origin from
machine zero, which doesn't affect the other coordinate systems. (EMC
equivalent to using G10 to set G54 variables in 5221-26, G55 variables in
5241-46, etc)

I'd like to see EMC's G92 set current coordinate system's offsets from
machine zero, or at the least the G92 variables (5211-16) be confined in
scope to apply only to the coordinate system within which G92 was set.

> Bug #5 - Annoying nonsensical errors
> Fred fixed this at N.A.M.E.S. It turned out that the first error wasn't
being
> displayed, and subsequent errors would display the previous error's text.
> This also caused (MSG... not to work. This should be OK in current BDIs,
but
> it would be nice to know when the fix was put into Sourceforge.

BDI 2.14 has this..., work around is to run EMC from 'konsole', and read the
errors there.

> Bug#6 - Joel's Homing Bug
> Quoting myself:
> > ... I think his "backlash value is added
> > to the home position every time you re-home an axis" ...
>
> Needs test and confirmation (and fixing if required).

BDI 2.14 does this - homes, then added the backlash to the machine origin,
in a cumulative manner. (Watching on the Mitutoyo DRO hooked up to my mill)

> Bug #6 - Joel's Software Limits Bug
> Quoting Joel:
> > It's been a while but I remember the software limits seemed to move at
> > times.  I only have home switches at one end and it would be nice to be
> > able to rely on the software limits to keep from hitting the stops on
the
> > other end.  I forget exactly what they were doing - I think they were
> > following the g92 offsets around instead of staying relative to machine
> > home.  I ended up putting huge working lengths in the ini to disable
them.
>
> Same deal, test, verify, fix...

I've seen that, but not in BDI 2.14

> Next we move on to some Keith Rumley bugs (BDI 2.04), all of which need
the
> test verify, fix routine. Also, if anyone else has experienced these
> problems, speak up.

My comments (Keith speaking) updated to BDI 2.14

> Bug #7 - M1 Bug
> Quoting Keith:
> > I've run into problems with the M01 command. Every so often it will
> > apparently not recognize an 's' keystroke to resume. But instead it has
> > 'double buffered'  the keystroke, so that it doesn't pause for the next
> > M01.

Not seen this since 2.14

> Bug #8 - G-code Init Bug
> Quoting Keith:
> > The .ini G-code initialization doesn't happen until F6 is pressed.

Not really an issue anymore. Turning 'machine on' reads in the .ini. I
changed the stg2.c code to fit my IO arrangement, and the e-stop bit at some
point in the EMC initialization is not recognized, so it starts with a
'E-stop bit not set.." error in a popup. All is fine after 'machine on'.

> Bug #9 - .var File Bug
> Quoting Keith:
> > The .var file requires MM for the machine coordinates. (perhaps related
to
> > the above G-code init thing.)
> > Or, maybe that's just Paul's BDI 2.04 revenge? :)
>
> Not sure what this means, someone help me out here.

Not an issue in BDI 2.14
It meant that the values in the .var file had to be in MM, even though the
.ini set linear units to 0.03937...., and the interpreter took inches from
G10 (setting the .var file variables) in the MDI.

>
> Bug #9 - Coordinate Offsets Not Initialized
> Quoting Keith:
> > The G54+ coordinate systems don't activate on startup - have to cycle
out
> > of a system (g54, etc) and back in again.
>

This is a display update thing, it happens when switching coordinate
systems, using G92 sometimes. Not consistent in its' appearance. EMC always
uses the commanded coordinate system, for me anyway.


Bug #11 - Arbitrary axis motion from MDI commands entered mid-motion.
There was some discussion on this a week or two ago.
For example, an MDI command is given G00 x5 y-5. While the machine is
traversing, the MDI command is entered G00 x2. As soon as command #1 is done
the machine heads for x5 AND y(x), headed back toward where it came from in
Y.  Y(x) on my machine is proportional to the time it was entered in during
the traverse move. The earlier entered, the more y motion.