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. |
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. |
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. |
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). |
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. |
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. |
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. |
We prefer that the motion controller is in one place - linuxcnc. |
We prefer that the motion controller is in one place - LinuxCNC. |
(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)
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.
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.
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.
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.)
With "uspace" realtime and the hm2_7i90 driver, USB ethernet dongles fail to work reliably at a 1ms servo cycle time.
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!