Re: Agenda Ideas for Monday - v1.0

["alex" <telecomt-at-tht.net>]

I quite agree.
I think would be very nice to choose some kind of a standard hardware
interface setup for the EMC, which would make software effort and FPGA
effort done in a most efficient way.
Alex
----- Original Message -----
From: Craig Edwards <cedwards-at-ceinetworks.com>
To: Multiple recipients of list <emc-at-nist.gov>
Sent: Sunday, April 13, 2003 11:25 AM
Subject: RE: Agenda Ideas for Monday - v1.0


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