EMC bugs and new features; call for developers

[Fred Proctor <frederick.proctor-at-nist.gov>]

EMC folks,

We moved the EMC software up to SourceForge (www.sourceforge.net) to
make it easier for everyone to work on the software. So far only Will
and I have accounts, so it hasn't really bought us anything yet. We
tried some co-development between us a couple of weeks ago and it worked
fine.

SourceForce uses CVS, the Concurrent Versioning System, to merge changes
made among people working on the same software project. Will posted
instructions on how to set up a SourceForge account and he knows all the
details.

The way it works is you get an account on SourceForge, then update the
EMC project software onto your local machine across the net, then fix
all our bugs for us, and then commit the changes back across the net,
and everyone sees the new code. Working snapshots can be released to the
non-developers, or packaged by developers into CDs or whatever and given
out or sold.

There are many big development areas that need work. Here are a few:

1. The motion controller needs better blending/lookahead and full 6-axis
support. Blending is done by beginning the acceleration phase of the
next move when the deceleration phase of the current move begins.
Blending between more than 2 segments causes problems, so contouring
programs don't run well. Currently it only supports XYZ motion planning,
although robot or hexapod kinematics can drive 6 or more axes to do the
XYZ motion. Roll/pitch/yaw or whatever your preferred orientation format
is doesn't change.

2. A related issue is that the motion controller confuses joint
coordinates with world coordinates. The two are effectively the same for
a typical slideway machine, but with a robot or hexapod they're not.
Fixing this would allow per-axis max accel, velocity limits to work more
uniformly than they do now. We've worked around this somewhat but it's
becoming more of a problem with the hexapod. This would be incorporated
into (1).

3. PID controller fixes. Us linear system pedants are loathe to change
this, but we're coming around. Our problem is that we don't have a
description of the end-all, be-all PID algorithm that works with the
non-linear systems we're all using. When do you dump the cumulative
error for the I gain? Will anti-windup fix this? How should the
derivative error be filtered to fix the quantization problems? Jon Elson
suggested fixes that Will posted but I don't know if these work.

4. The I/O controller for spindle, tool changer, coolant, etc. is
written in C++ now, with a Tcl/Tk controller that no one has tried yet.
Are there any commercial PLC programming tools for Linux? What about
this Puffin PLC free thing? It would be great if we could incorporate a
free PLC programming tool into the EMC.

5. Better GUIs. Perl/Tk, Python/Tk are all straightforward to do, just
like we did with the Tcl/Tk GUI.

6. Handwheels.

7. Pendants. Does anyone know of a good one? I tried a PC joystick but
these are pretty limited. Anything with a display or even status LEDs is
expensive.

8. Variable-speed automatic spindle control. I got this to work on the
minimill using the 4th DAC on an STG card, but the code has rusted since
I last did this, I'm sure.

9. Bug fixes. Here's one: motion since the 20-December-1999 version has
a resonance problem, as reported by Jon Elson and John Marciano. We
don't see this here at NIST but our servo amps may be tuned differently
and not show the problem. I suspect this is due to the quantization of
the computed position to the input (encoder) resolution, since I added
this shortly after 20 December 1999, but I don't know. Will posted a
note on how to comment this out; has anyone tried this?

First N developers to get an account with SourceForge and upload at
least a code comment testifying to their developer status get a NIST
coffee mug. N is large.

We could use a live list of EMC bugs and feature requests on the
LinuxCNC.org site. Does someone want to set this up?

--Fred