EMC Bug List (was G92)

[Matt Shaver <mshaver-at-erols.com>]

First off, I'm moving this thread to the EMC list as requested by Les. He's 
right about it being archived there. I've cc'ed C_C_E_D to let folks on that 
list know where they can continue following this discussion if they like (if 
you don't know where that is, go to http://www.linuxcnc.org/EMC-list.html ). 
If you reply to this message, don't cc C_C_E_D as I'd like to move this 
thread, not fork it in two directions... ;).

Bug #1 - G92
I'll quote Tim's response, but almost everyone else said the same thing:

On Wednesday 17 July 2002 12:41 pm, Tim wrote:
> Answers below in [ ]
>
> Some questions are:
>
>   1. When you use G92, do you:
>
>     A. right click on the axis display and set the axis value using the
> GUI? [Yes]
> or
>
>     B. enter the G92 command in MDI mode?
> [Yes]
> or
>
>     C. use G92 in your program code directly (this shouldn't be a problem)?
> [Yes. Depending upon the occasion I use G92 in all three methods. C is a
> problem in my program as G92 is called just before exiting not at the
> beginning.]

My original proposed solutions were:

On Tuesday 16 July 2002 11:45 pm, Matt wrote:
>   1. If the problem is only with situation "1A", we could change the GUIs
> to use G54 (or whatever offset is in effect), rather than using G92.

Whatever else we do, I think we need to clarify what happens when you do 
this. I'm the one who is to blame for this feature as I requested a "zero the 
axis" button like a DRO has, this is how Fred implemented it, and I think 
everyone likes it. Right now, if you right click on the X axis, leave the 
value at 0.0, and click Done, it's the equivalent of entering G92X0 in MDI. 
The people who want G92 to be "sticky" probably want this to be left as it 
is, while the people who want G92 to be "transient" might prefer something 
like G10L2P1X<negative distance from machine zero> if G54 is the currently 
active coordinate system. If G55 is active it would change to G10L2P2.... 
Thoughtful comments on this are appreciated!

>   2. If the problem is with situation "1B", we could add an ini file
> parameter like G92_BEHAVIOR = TRADITIONAL or CONTEMPORARY so the user can
> have it the way they want.

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.

>   3. If there are other interpreter problems (situation "2") we could make
> it easy to specify which interpreter you want to use, the old or the new
> (ini parameter rather than recompiling).

Tim wrote regarding this:
>   2. Other than the G92 problem, are there any other problems with the new
> interpreter?
> [Yes, rotary axis is unusable...

I don't think this is an interpreter problem, I think it's a problem with how 
basic units are handled (see the "Angular Axes" thread on the EMC list, 
particularly Paul, JohnG and ChrisW for details). I'd like to continue with 
only the new interpreter in the interest of progress, but I acknowledge the 
"angular axis" bug...

Matt then continues:
>   4. If there are other OS problems (situation "3") we'll have to do some
> more thinking... ;)

Tim also had good comments on this:
>   3. Other than interpreter problems, are there any reasons not to upgrade
> from RH5.2 systems to BDI (RH6.2) systems?
> [As Les mentioned there are problems with the display (Tkemc) not
> displaying where EMC really thinks it is. Definitely related to the use of
> G92. Also a problem with steppermod.o and Tkemc. When you start EMC the GUI
> comes up with the axes displayed in robot mode (numbered) instead of
> machine mode (XYZABC). To get the display correct you have to enable then
> switch to auto. Now you can toggle to machine mode display. When you switch
> to manual mode you get an error that is not fatal, but annoying. This
> happens whenever going from MDI or Auto to Manual if I remember correctly.]

Actually, what I meant was, "Is there any reason to keep using RH5.2/RTL0.9J 
over RH6.2/RTL3.0 ?". These are all bugs, but I think they can be solved on 
the BDI platformm (I'll spread them out individually later in this post). So 
far my experience is that the BDI works flawlessly except for a few 
(admittedly serious :<( ) bugs. In other words, servo systems don't 
unexpectedly run away, etc. The ease of installation and KDE make the BDI 
worth fixing, rather than staying with RH5.2. I'll consider this a success 
when Tim & Jon upgrade...

Continuing on with the list of bugs:

Bug #2 - Angular axes move slow/don't work
We need to distill the wisdom of the "Angular axes" thread and put it in this 
bug list (or we could fix the bug, either way...). Probably related to:

Bug #3 - "Units" handling is inconsistent
It's been so long I don't remember the issues. Someone remind me what was 
said in the discussion at N.A.M.E.S. and we'll put it here.

Bug #4 - TkEMC comes up in "robot mode"
I think this is only with the steppermod/TkEMC combination (XEMC is OK). Fred 
looked at this at N.A.M.E.S., but I forget what he said about it. I think 
steppermod needs updating and we also talked about combining steppermod and 
freqmod since they share a lot of common code.

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.

Bug#6 - Joel's Homing Bug
Quoting myself:
> ... I think his "backlash value is added
> to the home position every time you rehome an axis" ...

Needs test and confirmation (and fixing if required).

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...

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.

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.

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

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.

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.

I don't think this happens to me, maybe we need to send Keith a new BDI 
disk...

Finally there's my bug:

Bug #10 - Too many ifdefs
Need a good housecleaning, switch to autoconf/automake, etc.

Let's develop & expand this list so we can make progress.

Thanks,
Matt