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

Hi All
I hope I'm posing this in the right section.
This is a coding question, for those of you who are familiar with the source code of LinuxCNC. I did look at the source code but I realized that getting familiar with it is a daunting task, so I though I would ask people who already have experience with writing code for LinuxCNC, before I commit the time and effort to get to know the code.

I have this idea to separate the back-end and front-end of LinuxCNC to different executable modules and run them on different machines, having them communicate via LAN. The back-end, that actually drives the cnc-machine's motors would run on something like Raspberry Pi, using the GPIO as a parallel port (I'll probably have to write a kernel module to emulate the LPT). While the front-end, consisting of the GUI, settings, configuration and g-code loading, runs on a desktop PC. The back-end can also run on an old PC that does have LPT but would suffer a performance hit if it runs a conventional LinuxCNC version with GUI...

There are many advantages (I think) with this configuration:

1 - The main PC no longer needs to have a legacy parallel port;

2 - The main PC no longer needs a real-time kernel; (the ARM based single-board computer will)

3 - The main PC is no longer restricted to a specific version of linux, and can also be build for a 64 bit linux.

4 - I believe the ARM based single-board computers would have much lower latency, given (among other things) they won't have to deal with rendering graphics environments etc...

5 - Most importantly having the cnc-machine communicating via LAN means that I could run multiple front-ends on multiple machines on the network and be able to monitor and control the cnc-machine from multiple places. That would be crazy convenient for me.

So those are my specific questions:

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?

Currently I run a built-form-source LinuxCNC on an Ubuntu Mate 64-bit with RT-kernel installed. LinuxCNC thread(s) priority raised to maximum. Also I start the program with a script that dedicates an entire core to it, to avoid context switching.
I run it on a Core i3 4130 and despite the above measures I took, the latency and jitter are still border-line unacceptable. (it works but barely)

- Was I better off installing the original version with Debian wheezy 2.7?
- I think there's going to be a performance hit when installing 32-bit OS on a 64-bit PC, or I'm mistaken?

OK that's it, sorry for the long post and thanks in advance!

star-traveler wrote: 3 - The main PC is no longer restricted to a specific version of linux, and can also be build for a 64 bit linux.

4 - I believe the ARM based single-board computers would have much lower latency, given (among other things) they won't have to deal with rendering graphics environments etc...

Using SBC's for machine control has been discussed plenty, the main drawback is that they are made to use as little energy as possible, hence the inherent latency problems due to to many power saving options active that can not be disabled.
Linuxcnc CAN be used over the network using SSH or something else that i can not recall right now.
PC is not restricted to a specific version of Linux, there are plenty of Linux distros that Linuxcnc can work on although they do require reading a bit.
SBC will never have low latency due to reasons explained above, Graphic environments are just another burden on poor SBC.

Thanks a lot for your reply.
One last question: Did LinuxCNC ran poorly in my case because I didn't set it up properly, or I just need a more powerful computer? In my case, sometimes the monitor going to sleep was causing a critical delay error message. Although I never scraped a part because of it. Does LinuxCNC benefit from more powerful PC in general?

Thanks again.

In my experience, Latency doesn't directly depend on CPU horsepower, especially with RTAI (which has quite decent latency on Atom D525s which are about 1/5 the speed of your I3) , Preempt-RT seems more influenced by raw CPU speed, but you have a CPU with decent performance. Also in my experience restricting LinuxCNC to a single CPU may worsen Preempt-RT performance.

Have you gone through the usual suspects in BIOS setup options (disabling all power saving modes, fan speed control, Cstates >1 etc etc?)

Will RTAI (32 bit Wheezy) run on your PC? it will likely have lower latency than Preempt-RT, though Preempt-RT can have quite decent latency on the right hardware:



(servo thread only because its running hardware stepgens)

Hi PCW

I remember that before I restricted LinuxCNC to a single CPU the latency was a little bit better but there were nasty latency spikes. They were frequent and huge.

Also I have not touched "disabling all power saving modes, fan speed control, Cstates >1 etc etc".

32 bit Wheezy would most probably run. Now is a good time to ask, why dose LinuxCNC still ship on a 32-bit OS? And there is no stock 64-bit iso? I feel like it's a waste of hardware resources.

32 bit is not much of a disadvantage unless you have more the 4G of RAM

I think the main reason that there is not a standard 64 bit LinuxCNC dist is that
there has not been a stable 64 bit kernel RTAI created.

I would definitely disable all power saving options in the BIOS and re-test
perhaps trying with just 1 RT CPU and both cores RT, really long latencys are _very_ often power management related

There is a 64 bit version here
www.linuxcnc.org/testing-stretch-rtpreempt/
Most of us compile the kernel for whatever version of Linux we are using, mostly Linux Mint with Mate desktop environment.

PCW wrote: , really long latencys are _very_ often power management related

And failing hard drives and graphic cards with power saving options active.

Wow thanks!

"Most of us compile the kernel for whatever version of Linux we are using"
- Yep, that's what I did too. but I'd like to try something that has been packaged by the creators of LinuxCNC.

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.

But Machinekit has diverged quite a bit from LinuxCNC now, so this forum is likely to be less helpful.