Run back-end and front-end on different machines.

Thanks, I'll look into it. But after the answers I received to my questions, I've changed my mind. Now I think, an educated an detailed setting of the machine both in BIOS and software are the solution to my problem. But thanks anyway It'd be useful to know how thinks work separated.

Hi,
It should be possible to run the graphics frontend on different machine and not having the Xwindows on rtai machine. This would help a lot when the PC works well in low latency setup but the graphics is bad, which is the case for a lot of older AGP cards - there was a "X regression" event, which dropped DRI support in drivers for most cards other than nvidia and ati. This means pentium 2 is quite enough for controlling the hardware, but it bogs down on axis display. The machine with X server can be any linux box with any kernel, but keep in mind that with this situation the backend machine still needs to generate and process the interface stuff.
More information can be found when searching for "remote X desktop", that can work on short distance LAN or with ssh over internet (but I'm not sure how bad it will be). The simpliest way:
on backend:on frontend:but THAT is certainly NOT suitable for any production as it is too insecure, there are better ways to securely connect X workstations. This is just typed from my head I did not try that now... It should work as a proof of concept if anyone wants to see if it helps in machine load or timing. There can be some iptables rules making it not work on some distributions.

Thanks jmr, that's very useful to know.
Now your solution uses purely the ability of the X windowing system to run server and client on different machines connected via network.

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?

This X windows solution will get you to just one display, at least in the standard environment.
For the split machine/controll, the best I can now imagine would be just the low level stuff and trajectory planner on the backend, and other things with GUI on the other-end. This could end up as a device that just accepts the stream of g-codes, but there is more to it - like the ability to know where is the program/machine now, to pause the program or run it backwards, and this would require more bidirectional communication. Most likely there are ideological reasons it is kept together, on of them being the goal to run on "any*" pc, and the other the ease of modification/upgrade which is going to get impaired when you split the project.
I have not been deep enough in LinuxCNC code to know enough to talk any more about this. I just know it's possible to load hal with drivers and not the interface. I think the g-code processing was in the interface, there were interfaces that provided just the basic MDI control (one was running in ncurses, it is now dropped in 2.8 and I would like it ressurected). It should be hackable if you really want/need to.
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.

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.

As Andy alluded to, Machinekit has taken to this route, remote control for lack of a better description.

In My Totally Maligned Opinion Machinekit seems to be more for the "Hipster Maker Crowd" (I recognise the talent of the coders) and Linuxcnc seems to be more for those that actually wanna make stuff.

The BBB platform does work, the PRU is good (so far as I've seen) but on cost/performance an X86/64 setup is miles ahead. Tho I did have to fab my own breakout boards to get the BBB to do what I wanted. (There are that many MK images for the BBB it's a bit confusing now) I use an older one that still runs X.

The Linuxcnc community has better realtime support for any questions you have.

Thanks a lot Tower, that's a very complete and comprehensive answer.

I was kind of afraid that, such a task would turn out to be a major undertaking, that's why I though I'd ask people who know this stuff first.

So for now I'll stick to a standard LinuxCNC on a single x86/64 machine, modifying the suggested BIOS settings in order to remove any latency issues.

But if I ever decide to invest the time to try and do this separate machine setup, I'll be sure to use your comment here as a starting point.