[Home]HardwareDesign

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Difference (from prior major revision) (no other diffs)

Changed: 50c50
Several people have had positive experience with "uspace" realtime and UDP ethernet communication. However. realtime ethernet performance depends on the Linux network driver itself having good realtime performance.
Several people have had positive experience with "uspace" realtime and UDP ethernet communication. However, realtime ethernet performance depends on the Linux network driver itself having good realtime performance.

Changed: 62c62
Many PCs have a common, easy-to-program chip for RS232 serial interfaces, the 16550 FIFO. However, the top speed is 115200baud. In 200us, only 16 usable bits can be transmitted in each direction (10 bit times per character, 2 characters = 173uS), which is not enough to send DAC commands and retrieve position feedback for multiple axes.
Many PCs have a common, easy-to-program chip for RS232 serial interfaces, the 16550 FIFO. However, the top speed is 115200 baud. In 200us, only 16 usable bits can be transmitted in each direction (10 bit times per character, 2 characters = 173uS), which is not enough to send DAC commands and retrieve position feedback for multiple axes.

Changed: 68c68
because it breaks the idea of the project - Linuxcnc as a machine controller.
because it breaks the idea of the project - LinuxCNC as a machine controller.

Changed: 72,75c72,75
If you wished to do rigid tapping with your usb based controller - you would have to add the tapping code to your microcontroller.

USB wil not allow reliable communication between the motion controller (linuxcnc) and the motor controller (your micro)

multiply that by other options and now you have basically made your micro controller into a motion controller.

This has been done in a fork of linuxcnc - usb to a mesa 7i43 card. araisrobo project (now uses machinekit IFAIK)

If you wished to do rigid tapping with your USB-based controller - you would have to add the tapping code to your microcontroller.

USB will not allow reliable communication between the motion controller (LinuxCNC) and the motor controller (your micro).

Multiply that by other options and now you have basically made your micro controller into a motion controller.

This has been done in a fork of LinuxCNC - USB to a mesa 7i43 card in the araisrobo project (now uses machinekit AFAIK).


Changed: 77,78c77,78
Now if someone added some cool option to linuxcnc's motion controller you won't able to use it until you added it to your motion controller.

It also doesn't allow linuxcnc's builtin scope and meters access to the micro controller's internal test points.
Now if someone added some cool option to LinuxCNC's motion controller you wouldn't be able to use it until you added it to your motion controller.

It also doesn't allow LinuxCNC's built-in scope and meters access to the micro controller's internal test points.

Changed: 80,81c80,81
By using relatively 'dumb' hardware, we avoid that scenario - what ever linuxcnc can do it can do with all hardware that supports the basic requirements.

You can even run an analog servo using the parallel port - just the performance would be low.
By using relatively 'dumb' hardware, we avoid that scenario - whatever LinuxCNC can do it can do with all hardware that supports the basic requirements.

You can even run an analog servo using the parallel port - just the performance would be low.


Changed: 83c83
So is it a waste of time for simple I/O stuff? yes I guess you could say that - but when you look at the bigger picture it makes sense - linuxcnc does a lot more then just simple step driven mills.
So is it a waste of time for simple I/O stuff? Yes, I guess you could say that - but when you look at the bigger picture it makes sense - LinuxCNC does a lot more than just simple step driven mills.

Changed: 85c85
We prefer that the motion controller is in one place - linuxcnc.
We prefer that the motion controller is in one place - LinuxCNC.

The purpose of this page is to describe the kinds of motion control hardware interfaces that are well-suited to LinuxCNC's hal. Some specific cases of non-compatible interfaces are also discussed.

1. Physical Interface
2. HAL's timing model
2.1. Realtime API
2.2. No buffering
2.3. No externally-initiated reads or writes
2.4. "fairly fast"
3. Why isn't there support for <interface>
3.1. Ethernet
3.2. USB
3.3. RS232 Serial
4. Why not use a micro controller over USB as a step generator

1. Physical Interface

At present, there are four major physical interfaces used by LinuxCNC-supported hardware:

2. HAL's timing model

In HAL, all I/O is initiated by hal functions which run with an order and timing specified in the HAL configuration. Typically, the "servo thread" runs every 1ms and can be broadly divided into three separate steps:

(On machines with software step generation, software PWM, or software encoder counting, there's also a "fast thread" which does low-level I/O at rates of up to 50kHz or so. In that case, "read inputs from external hardware" consists of latching counters maintained by the fast thread, and "write outputs" consists of updating registers such as step frequency registers which are then used staring in the next invocation of the fast thread)

2.1. Realtime API

In a HAL realtime function, only a very restricted set of APIs be called. Basically, these consist of: APIs that cannot be used include: For instance, the HAL parport driver cannot call the Linux kernel function "parport_write_data()" to communicate with the parport hardware. Instead, it uses outb() directly. This is one reason that hardware support tends towards simple, bit-bangable hardware like parport and pci-bus and away from complex hardware like USB and Ethernet.

In some RTOSes, a greater range of APIs may be called. For example, in LinuxCNC 2.7 with "uspace" realtime, practical experience shows that it is feasible to use `send()` and `recv()` POSIX API calls in realtime threads to send and receive UDP packets on a dedicated network interface.

2.2. No buffering

In other products, external buffers are used to compensate for lack of true realtime in the PC. Any external device which buffers up motion is a bad fit for LinuxCNC. While various ways to allow external buffering have been proposed, working code has never been submitted. With external buffering, some features will simply not work. This includes closing the PID loop in the PC, spindle synchronized moves, homing, and other items.

2.3. No externally-initiated reads or writes

Externally initiated reads and writes are similar to buffering. They introduce undesirable phase shift. Imagine that LinuxCNC's servo loop runs at a nominal 1kHz, and so does an externally initiated read of feedback position. However, the actual periods are 990Hz and 1000Hz. The two frequencies will beat at 10Hz. At its worst, the new feedback value will come just after a new command value, causing the motor to seem to move as little as 1% as far as PID commanded it to. This variable phase shift might produce a completely untunable system; at best it will provide a difficult to tune system.

Some external hardware has started incorporating a DPLL to provide most of the benefit of an externally-initiated read while conforming to the HAL timing model. The DPLL tracks the actual read time (with a relatively low gain to smooth out latency) and latches encoder counts a fixed time before the DPLL predicts LinuxCNC will request the information.

2.4. "fairly fast"

The total time to read and write the external hardware (including all overhead for initiating reads and writes) should be fairly small compared to 1ms--ballpark figure, 200us. For example, using a bandwidth of 2megabit/second for EPP, 50 bytes can be transferred in 200us.

If the read and write is not "fairly fast", two problems occur. First, there is less time left over for linux userspace programs such as the user interface. Second, the time from read to write represents a phase shift which (even though it is roughly constant) can still hurt the tunability of the system.

3. Why isn't there support for <interface>

LinuxCNC supports two different styles of realtime, kernel-space realtime with RTAI and user-space realtime with PREEMPT-RT (called "uspace"). In RTAI, Linux hardware drivers cannot be used from the realtime context, so it is not possible to reuse them. "uspace" is new in LinuxCNC 2.7. For this reason, almost all hal hardware drivers have been written in the lowest possible terms: inb(), outb() and the like.

3.1. Ethernet

Several people have had positive experience with "uspace" realtime and UDP ethernet communication. However, realtime ethernet performance depends on the Linux network driver itself having good realtime performance.

In principle, the RTAI realtime kernel has a network interface, RTnet. However, no one has ever submitted a driver that uses RTnet. It is not clear whether RTnet as written will work with HAL's timing model.

(Note: A working ethernet HAL driver using RTNet is currently being developed, see rt-8p8c.)

3.2. USB

In principle, there is an RTAI project to add USB support, rt-usb. However, no one has ever submitted a driver that uses rt-usb. It is not clear whether USB can meet HAL's timing model.

With "uspace" realtime and the hm2_7i90 driver, USB ethernet dongles fail to work reliably at a 1ms servo cycle time.

3.3. RS232 Serial

Many PCs have a common, easy-to-program chip for RS232 serial interfaces, the 16550 FIFO. However, the top speed is 115200 baud. In 200us, only 16 usable bits can be transmitted in each direction (10 bit times per character, 2 characters = 173uS), which is not enough to send DAC commands and retrieve position feedback for multiple axes.

4. Why not use a micro controller over USB as a step generator

Short answer:

because it breaks the idea of the project - LinuxCNC as a machine controller.

Long answer:

If you wished to do rigid tapping with your USB-based controller - you would have to add the tapping code to your microcontroller.
USB will not allow reliable communication between the motion controller (LinuxCNC) and the motor controller (your micro).
Multiply that by other options and now you have basically made your micro controller into a motion controller.
This has been done in a fork of LinuxCNC - USB to a mesa 7i43 card in the araisrobo project (now uses machinekit AFAIK).

Now if someone added some cool option to LinuxCNC's motion controller you wouldn't be able to use it until you added it to your motion controller.
It also doesn't allow LinuxCNC's built-in scope and meters access to the micro controller's internal test points.

By using relatively 'dumb' hardware, we avoid that scenario - whatever LinuxCNC can do it can do with all hardware that supports the basic requirements.
You can even run an analog servo using the parallel port - just the performance would be low.

So is it a waste of time for simple I/O stuff? Yes, I guess you could say that - but when you look at the bigger picture it makes sense - LinuxCNC does a lot more than just simple step driven mills.

We prefer that the motion controller is in one place - LinuxCNC.

Now if you could figure out how to get USB3 to be low latency relatime...now you are talking!


LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions
Last edited November 29, 2016 3:33 pm by KimK (diff)
Search:
Published under a Creative Commons License