star-traveler wrote:
(...)
1 - Is that a good idea at all? (Is there something like that already?)
2 - Does the architecture of LinuxCNC have a clear separation between the working thread that controls the motors and the GUI thread? I suppose there is, and the two communicate via command and data queues?! "The GUI thread sends commands to the worker thread and the worker thread sends back the current position of the tool."?!...
3 - In your opinion (as someone who's familiar with the code). Is the job of separating the two trivial, or would require writing/re-writing a lot of code?
4 - In your opinion, do you think there's going to be a lot of lag between back-end and front-end due to the LAN interface connecting them?
(...)
It's a major engineering overhaul on which good programmer's teeth were lost. That's the short answer.
I have been looking into this for some time (true, on the Machinekit side) so I think that I can give you a general idea.
1) Yes, it's a good idea. It's a brilliant idea. And theoretically, the NML layer is capable of TCP communication. (I don't know if it was not butcherized in LinuxCNC.) So you could connect to the motion component remotely.
2) Yes, it does. The cyclical HAL threads which control motors are run as deterministic real-time threads. Look up the motion component for a general idea, it bridges HAL access with NML commands.
3) I would consider it very hard. To work as you envision you would have to slice the motion (and other) component, create streamlined communication for distributed system and so on. For a typical work-in-the-evening open-source programmer it could be a year worth of work.
4) Depends on the communication type chosen. Wired ethernet will be fine, wireless much less so (higher packet loss). There will be a difference between TCP and UDP. The serialization/deserialization will have overhead also. But there can be a lag - even in multi-millisecond range.
If you are interested in using SBC, look at the mksocfpga project and Altera SoC or Xilinx ZYNQ based boards. (However, even with BBB you will be capable of fast step generation for step/dir signal.)
Now is a good time to ask, why dose LinuxCNC still ship on a 32-bit OS? I feel like it's a waste of hardware resources.
Because of the underlying real-time patch (RTAI) and the connected HAL library. (The bigger problem is EOLed Wheezy.) If nothing changed, LinuxCNC so far does not support multicore HAL execution (not sure on this), which goes hand in hand - multicore processors were introduced about the same time as general 64bit architecture.
If you want an easy way to run the hardware and GUI on different hardware then you should probably look at Machinekit, which seems to specialise in running the realtime on a Beaglebone with a remote GUI.
Machinekit doesn't specialize on Beaglebone, people just like to use it.
However, look at the mkwrapper python string in Machinekit's repository for idea about remote GUI. (Warning: it's a band-aid, temporary solution which became kind of long term.)
Do you think the same can be achieved through modifying the LinuxCNC's source code itself, so that front-end and back-end are internally separated and communicate through some sort of custom protocol?
Yes, again look at mkwrapper. (Or think up something yours.)
Maybe as Andypugh suggested, the machinekit may offer a more ready solution. I believe it forked from a common code and should be quite compatible a few revisions ago. I do not have any idea of how it works, but I imagine having hal communicating over lan would be a way to glue it to everything, with it's own drawbacks.
Generally speaking, if you want deterministic HAL communication (not loadusr) you are stuck with Ethernet based field bus like EtherCAT.
