RE: Agenda Ideas for Monday - v1.0

["Craig Edwards" <cedwards-at-ceinetworks.com>]

Hi Matt,

How bout an agenda topic of "Best way to enable porting of EMC to boarder
range of hardware platforms" or something along these lines. If one of the
goals of the group is to broaden the acceptance of EMC, I'm thinking this
topic might be appropriate.  I know John K's and others efforts in
documentation will go a long way towards making ports easier, but I'm
wondering if there aren't specific architectural changes to the code that
might be considered to facilitate a broader range of hardware devices /
platforms that could be supported.  

Possible subtopics....

a.Could all of the "hard real time" I/O be separated from all the standard
Linux code?  I'm sure this is already the case to a degree...maybe it's just
a doc issue.  But in terms of future features and new applications, is there
more that should be considered here?  I guess I'm thinking alone the lines
of a "hardware abstraction layer" built just for the real-time I/O part of
the code, realizing this could be impractical due to performance tradeoffs.

B.Should a set of "CNC" centric API's be defined, with the goal of making it
easier to extend EMC into new applications? Again, this might not make sense
in the context of the current implementation of EMC or may already exist at
some level within the code base... But as a EMC newbie and 'hardware guy"
I'll leave it to you and others more knowledgeable to decide if more
could/should be done here. 

This is probably enough for you to get the general idea of what I'm
suggesting.... I think anything that could be done to enable "easier"
software ports would expand the range of options available to users.  And to
be fair, since I've never worked with the EMC code base, it may not be that
hard now.....again it may just boil down to documentation, but I think it's
worth discussing.

-Craig Edwards



-----Original Message-----
From: emc-at-nist.gov [emc-at-nist.gov] On Behalf Of Matt Shaver
Sent: Friday, April 11, 2003 2:43 AM
To: Multiple recipients of list
Subject: Agenda Ideas for Monday - v1.0



I thought this would be a good time to accumulate suggestions for things to 
talk about on Monday. I'll throw some out here to get this thread started, 
and you can feel free to add your own potential topics.

Notes:
	1. I'm not looking to debate these ideas here and now on the mailing
list, I 
just want to collect up a list of possible subjects for the EMC Monday 
meeting.
	2. These aren't carved in stone, they're just what I could come up
with off 
the top of my head (edit at will)!

OK, enough prevaricating:

1. Education and documentation:
  a. Getting people with software skills up to speed without a huge time 
investment reading the source code.
  b. Discuss, edit, and expand John K's diagrams, the handbook, and other 
"loose" documentation.
  c. Milk knowledgable attendees for all they're worth and write down what 
they know to create comprehensible documents that can be shared.
  d. EMC development history?

2. Bugs (see my list at the end of this post for the last list I had):
  a. Known bugs in the current sources?
  b. Observations of aberrant behavior in the field?
  c. Is everyone running the latest stuff? If not, why not.
  d. Are the bugs we know about just typos, logic errors, incomplete or 
incorrect algorithms, or do basic design assumptions need to be changed?
  e. How will we fix & test them?

3. New features needed:
  a. Synchronized motion:
    i. Jog wheel?
    ii. Single point threading?
    iii. Rigid tapping?
  b. User customizable PLC?
  c. Interpreter enhancements:
    i. Lathe mode?
    ii. Macros?
    iii. Subroutines?
    iv. User definable codes?
  d. User configurable GUI?

4. Code organization & build system:
  a. Make Will's new autoconf/automake build system the default?
  b. What sources go to make what binaries?
  c. Is more modularity or abstraction needed/wanted/possible?
  d. Can the .ini file support more "mix&match" of axis types and machine 
features?
  e. What PLATS are really needed?
  f. Less #ifdefs possible?

5. Organization:
  a. Do we need a formal organization like Debian and the BSDs have?
  b. Corporate sponsorship; good or bad? If good, how to get it.
  c. Dues, contributions and grants?
  d. If we had money, would it hurt or help? What would it buy?
  e. Should the mailing list stay on NIST's server?
  f. How to get your code included in the official tree.
  g. Automatic nightly builds to check for broken compiles?
  h. Should there be "stable" and "testing" branches?

Well, I'm tired and need to go to sleep, so feel free to add more stuff to
the 
list!

Thanks,
Matt

*****
Here's that list of bugs from an older post. Don't be shy, add some more!
*****

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 platform (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 re-home 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.