Hi Dave,
actually it seems we're working on a quite similar "project". I'm
currently I'm planning to keep the power part of my milling machine as
well, and it requires step/direction signals as yours.
To protect my parallel port I've plugged a 7407 in between.
My realtime task gets its commands via FIFO. It has a very simple
command structure: Two bytes to put onto the parallel port (with some
inp()'s in between to give sufficient time to the logic to grasp it),
and an RTIME to wait afterwards.
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.
My user process currently is still rudimentary: It maintains position
and velocity of every axis and processes directives to move, in a given
time period, every axis to a given new position. Thus,
Period X Y Z
[RTIME] [Steps] [Steps] [Steps]
80000 40.0 40.0 30.0
1920000 1960.0 1960.0 1470.0
80000 2000.0 2000.0 1500.0
80000 1960.0 1960.0 1470.0
1920000 40.0 40.0 30.0
80000 0.0 0.0 0.0
constantly accelerates axis X and Y to a final speed of 1/1000
Steps/RTIME (axis Z to 1/1333 Steps/RTIME), then move all three axis at
that constant speed to their given new positions, then decelerate them
to reach their final position, and back.
The simple task of calculating the exact times at which to step the
motors already required quite some mathematics, and I'm still fighting
with special cases (e.g., to handle the case that motion to exactly
position xxx.5 is requested, because it is at the xxx.5 coordinates
where I trigger the stepping, to handle the case that the required
position is opposite of the current movement, and whatever might still
turn up to be tackled during further tests).
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?).
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.
I'll happily share code, of course. Currently I'm at work; I'll send you
what I have so far this afternoon.
rt_task_waitfor() requires you to modify rtl_sched.c. My software
requires also the other two patches mentioned in my mail, so I'll
publish all the changes I made to RTL0.9J as well.
I don't have any special reason to move to Linux 2.2, by the way. I just
wanted to install the most up-to-date stuff. For the moment I'm happy
with 2.0.36 as well.
I hope you don't mind me CC'ing the mailing list. Maybe some other folks
are interested in what we are doing?
Best regards,
Sebastian
--
Dipl.-Inform. Sebastian <dot> Wangnick <at eurocontrol in be>
Office: Eurocontrol Maastricht UAC, Horsterweg 11, NL-6191RX Beek,
Tel: +31-433661370, Fax: ~300
Spam email is reported (charge $100) to providers and [EMAIL PROTECTED]
--- [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/
