Jon,
Thank you for your feedback.
I do beleive I have a method that would allow a USB port to be used with
external hardware
as well as I have a ep9302 arm9 board with ethernet that I have ported a
version of 2.4.21 with jffs2
that I use for realtime audio intercom systems. This hardware could be used as
a base for a new board.
The EMC2 software should run on my linux if it were recompiled for my arm9
linux image. The idea is that we
offload the realtime sections to hardware that is designed more for real time.
We allow the pc to que up the motion
updates in 1 ms pieces. If we structure the software correctly we would allow
simple machines to load the rtos under linux
like you do now and were needed the interface can be offloaded to an external
cpu by ethernet or usb or even serial maintaining
the step and servo loops out side the pc. If we allow for a hartbeat between
external boards ( your servo time 1 ms ) we can
expand the system to any size and mix servos,steppers and other types of
hardware. If we allow motion commands to be qued
in advance by the pc EMC can operate in user space only. We could move the
stepping funtions into
loadable drivers. All trig funtions as well as kenetics would be handled in
user space with simple intiger math used in the kernal
space. I have found that many floating point libarys are not completely
reenterant and should never be used in interrupts.
Also depending on the hardware platform the floating point libs contain
differnet transidental funtions as well as some intel
processors require software patches to work around bugs in the floating point
processor. All these issues make realtime
floating point unrealiable or at least difficult to work with. I would like to
help devlope a system that is hardware independent.
It could run on a MAC, ARM9, or other linux hardware. In the near future there
will not be printer ports on PCs. It is hard to
spend time on new software that can not be run on new PCs or notebooks. I have
a toughbook that can handle a coolant spill.
It would be good to be able to run the code on that PC as well as a desktop.
Daniel
Daniel Lee wrote:
>
> I find that using a PC for stepping is fine for low speed stepping. I
> need a device that can handle smooth stepping as well as servo upgrades.
> The current EMC2 can not handle my needs of speed, smooth stepping,
> expantion, as well as program loading and editing while the
> machine is in operation.
With a little hardware assist on the outside, the current EMC2 certainly
can handle all these things at once.
> Harddrive, usb RS232 port operation and video updates while running
> cause irregular stepping at high stepping speeds
> with the current design.
>
Some motherboards are hopeless for real-time. Some software components
compromise the rwal-time envoronment. It has been shown that if you get
the latency test to run with acceptable results, EMC2 gives good
real-time performance. Have you run the latency test program? If so,
you should have gotten bad results, and solved that before ever moving
on to moving a machine with EMC. If you are using a laptop, then try a
desktop. We have found few if any recent laptops that work for real-time.
I have always believed that forcing a PC to deliver very high step rates
via software alone is just wrong, and there is some grey area above
which a hardware assist is required. There are several boards available
at modest cost (I make one of them, so there's your full disclosure)
that move the difficult step generation task out of the CPU, and solve
this problem. I also make some boards for servo motor control.
USB has problems, however, in getting high rates of bidirectional
transfers synchronized with an arbitrary real-time interrupt.
I have done some experiments that show it can move a HELL of a lot of
data, and so it seems, in theory, that open-loop stepping could be done
by just sending a stream of bytes to a USB target that feeds them out on
a parallel port. I've used the Cypress "EZ USB" FX chips to do this. A
little board with the FX, crystal osc and maybe just using their
programmable port timing logic would do everything.
EMC2 currently has no way to interface to the USB host hardware from the
real-time environment. And, if you want to use a USB mouse and
keyboard, you have a real conflict between RT and Linux use of the ports.
> If this sounds like a project to start and to define the next
> generation of EMC I would like to help.
>
We have also been looking at the possibility of using a dedicated
ethernet port for this purpose. There are a couple of advantages.
1. Ethernet is electrically isolated, so it should be more immune to
electrical noise from the CNC motor drives.
2. Modern ethernet is full-duplex, so the PC => controller and PC <=
controller messages won't have to share bandwidth (although in the
simple case it doesn't matter).
3. Nobody will ever try to plug a mouse or keyboard into the ethernet.
4. rtnet has already been developed, it looks like a good base to
interface to our our HAL environement.
I have been thinking it would be quite easy to use one of the ARM7 (or
ARM9) CPUs with built-in 10/100 ethernet to make an adaptor to my
already existing motion-control boards, which now use the parallel
port. The protocol is like this: The PC asks for position and digital
input data, computes new velocities and then sends new velocity and
digital output data to the board. So, every servo cycle (typically 1
ms) is sends a request, gets back a response, and then sends a command
packet.
What I envision in detail is that each packet sent by the PC would have
a map of the registers to be read and/or written. After the map would
be the bytes to be written, in order corresponding to the map. A packet
of read values would be returned if there were any registers to be read.
This should be a VERY short and simple code in the ARM CPU, and should
execute very quickly, probably working faster than the current version
does on the oh-so-slow parallel port directly.
If you have any interest in working on the integration of rtnet or other
real-time ethernet library to EMC/HAL, I'd be VERY interested in this.
On the other hand, if you can actually figure out how to make USB work
in real-time, I would ALSO be very interested in that. If you could
come up with a scheme that could perform roughly the same kind of
protocol as I described above, but with USB, it would also be of great
interest. (Just to flesh that out, I BELIEVE, after some calculations,
that it is theoretically possible to run my boards with a 10 KHz servo
update rate using 100 mbit ethernet. This would require 3 small packets
per servo cycle, or 30,000 per second at the 10 KHz rate. I don't have
any idea of the delays involved in the rtnet protocol stack, so this may
be completely impossible. There are some delays and limits inherent in
the USB protocol, which puts a lot of limits (IN the HARDWARE) on what
you can and can't do that may prevent this kind of rapid-fire back and
forth communication.)
Jon
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
