Sebastian, Dave, et al:
In the EMC implementation for control of a CNC machine, we do what
Sebastian considered here when using stepper motors:
> Actually, my first approach was to have a periodic realtime task doing
> some kind of integer arithmetic to calculate whether or not to step a
> given axis in a given period. However, the period needs to be VERY small
> to create nice signals for all axis. Therefore I decided to abandon that
> idea.
I run two RT tasks: the first is the motion controller, which looks at a
queue of moves (linear, circular), plans accel-slew-decel trajectories
with blending between adjacent segments, and pops points off at about 5
milliseconds. These points are run through inverse kinematics, typically
trivial for a 3-axis machine tool. The output motor positions are
interpolated and used as setpoints to a PID controller at about 500
microseconds, or, in the case of steppers, to feed the (second) stepper
task.
This second task runs at 100 microseconds, and decides for each motor
whether it needs to issue a pulse or not. If not, an "error" builds up
between the commanded output position and what the stepper tasks knows
it sent out. When the error is such that outputting a pulse would reduce
the error to less than it would be otherwise, a pulse is sent out.
The advantage is that the timing of the pulse task is constant. The
disadvantage is that for slow moves the task still runs at 100
microseconds while rarely doing anything. Also, the pulses are rarely
evenly spaced in time. At maximum speed, they look like 11111111....; at
half-maximum speed, they look like 1010101010101...; for other speeds
they look something like 11101110111011101110...
The alternative, changing the timing of the pulse task(s), means that
during accel and decel the pulse task will effectively be one-shot
triggered and thus slower (see thread on this in RT mail list, entitled
"[rtl] RTLinux V1 -vs- RTAI benchmark").
Running this on a 3-axis motor test stand shows that it does what it's
supposed to, with an effective pulse period of 5 kilohertz (100
microseconds for positive edge, 100 microseconds until the negative
edge, is 200 microseconds period). I'd like to try alternatives and see
how performance varies.
> My next step will be to process even higher/level kinematics, taking
> into account maximum velocity and acceleration for straight, circular
> (or rather, helix) and maybe even B-splinish movements.
>
> I also have some thoughts on trajectory blending so that soft
> linear/circular transitions can be run at full speed, and edges are
> approximated by tiny circular movements with a specified maximum error
> distance between the radius and the edge point, which are then run at
> the highest speed not violating the maximum acceleration parameter
> (remember acceleration in a circle?).
The current EMC motion planner runs as an RT task, and does an OK job of
linear and circular move blending. The algorithm starts accelerating
into one segment (line or arc) when the previous segment begins "truly"
decelerating (not counting feed overrides). This works when the motion
segments take more than one trajectory planning cycle (e.g., 5
milliseconds) to run, but if they are shorter then more than two need to
blend together and the algorithm breaks down. We saw problems when
running the classic "race car" mold part. We have a much better motion
planner that we are testing now. This algorithm takes into account both
tangential and normal acceleration. Our problem is currently getting
points down to the motion system fast enough. We are using shared memory
for both commands to the motion system and status back from it, but are
seeing starvation of the motion task that we didn't see when we ran from
a FIFO during testing. We may switch to a FIFO for commands.
> I was planning to interface with the EMC G-code software package from
> NIST, adding a Tcl/Tk graphical display of what's going on on top of it.
> If you have already some G-code interpretation in Tcl/Tk, cool.
We have a variety of GUIs, none of which I am happy with. Currently most
EMC users are running an X Toolkit-based GUI that is OK but lacks
standard widgets for file browsing, etc.
I toyed with a Tcl-based interpreter recently but haven't gotten very
far. I got as far as building a wish replacement that does some custom
initialization for the communication channels, and adds commands for
estop, mode control (manual, auto), spindle, coolant, etc. and runs
TclX_Main() so I can run Tcl scripts. The scripts could do Tk stuff but
I haven't gotten that far.
The user requirements for a GUI are such that everything has to be
accessible via keystrokes. There can be no requirements for mousing
around. Tabbing between fields is a must, as is using keys for jogging
the axes. I spent a bunch of time figuring out how to make arrow key
downs start a jog, arrow key ups stop the jog, in spite of key repeats.
What a pain. I would *greatly* welcome a Tk-based GUI at this point, and
all the controller integration has already been done.
If you are interested, see:
http://www.isd.cme.nist.gov/projects/emc
Although it's really an R&D project suitable for hobbyists, two EMCs
have been put together by a non-NIST person, were sold, and are in
production.
--Fred
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
