Remote X display for linuxcnc?

Is anyone out there running a remote X display for Linuxcnc?

Knowing some basics about both real time systems and the rather *ahem* legacy X protocol as well as the complexities introduced by hardware video acceleration I know that the two functions of a CNC system tend to need conflicting resource and system settings. I would think that an ideal machine control system would be one "real time" controller PC running the linuxcnc threads and one "interface" PC with a nice big display, sound, and would be set up for interactivity and usability. Basically, separate out the real time functions from the user interface functions and put them in separate PCs.

This is especially obvious since we're working on turning off features of many PC motherboards and chips to get the best latency - isolcpus=1, IRQ remapping, and similar. These tweaks are great for latency, but not so good for providing resources to hungry user space programs. It's possible with the right config to do other things on the PC while running an ngc program, but most people don't try it for good reason. With up and coming "mini" platforms like the RPi and the Beaglebone, it would seem like there are obvious benefits to just having the mini hardware run the real time stuff and using a laptop or full size desktop for the graphical interface.

I know this can be done currently using the remote capabilities of the X protocol, including GLX acceleration, but is anyone actually doing it? How well does it work?

Erik

At home I have a linux machine without monitor and keyboard that I access to it using the remote desktop.
It works fine for me, although that machine does not use linuxcnc, it is used as a server (mostly because zoneminder).
I think that is also only possible to access inside your LAN. Not sure though.

Actually, the X windowing system was created to work over a network, even a "slow" one like a 1 megabit connection... it's a very old windowing system that's undergone a lot of updates, but the basic protocol hasn't changed greatly. It's even the basis for some of the modern remote desktop protocols. So you can run it with some limitations over almost any network.

What I'm wondering specifically is how would moving the desktop interface part of linuxcnc remote would affect machine performance and latency on the real time side. It sounds like it does work from the above, so it's probably something to experiment with.

Most likely if this sort of split architecture were to be used it would make sense to do at a different layer of Linuxcnc. X as a protocol is client-server... even with the windows displayed in a different place than the real time PC, the real time PC would still have to do the work of creating mapped memory for graphics windows, using drawing libraries to draw in the windows etc. and sending them to the remote PC for display. X makes this possible but it's still going to be more efficient to transmit instead just the information that needs to be displayed or used for calculations or control (controller->PC) and sending back just commands and program data.

I'm not requesting any features or arguing for a different architecture for LinuxCNC here, just thinking out loud. It sounds like maybe some of the people working on the embedded type linux boards are already headed toward this anyway.

I think that's probably a good thing... it's really nifty that a desktop PC can be made to perform in real time the way LinuxCNC does. It's a fine technical achievement. However, compared to a basic hard real time embedded board it's pretty limited.

For example, the Galil controllers you see on ebay use a 68000 family embedded chip, which is much less capable than the Pentium family chips most of us have. But, because it's built into a board designed for real time it can accept encoder feedback at Mhz rates(20 million+ counts/second), something you need a Mesa board to handle on a PC. It can also update its servo loop at over 30 khz... the manufacturer claims a 32usec update time for the loop, and that's probably with less than 1u jitter. They can generate steps for stepper motors at over 6 million/second.

As I understand the LinuxCNC project's goals and aim, it's not headed toward producing a dedicated hardware CNC controller, but rather providing an open source freely available solution for controlling CNC systems using commodity hardware. That's great.

However, it's starting to look like "commodity hardware" is soon going to include some very nice open source/open hardware solutions for real time systems. The people who are big fans of these little boards (Arduino, Raspberry Pi, Beaglebone) like to use them for everything all at once... if you have a very fine hammer, you want to use it to hit things, even if you should be using a wrench.

I'm thinking that the functions that should be left to the small boards are the real time ones, with the user interface and design work left to the desktop form factor PCs... use the right tool for the job.

I think eventually it'll make sense for people to buy a little board like a beagle to use instead of a smoothstepper or using software stepping. They'll be cheap and offer high performance. Unless someone builds stepper or servo drivers into them they won't replace the high power parts of the system of course.

Anyway, enough rambling. That's why I was asking if anyone's running the graphical interface separate from the real time.

Erik

For example, the Galil controllers you see on ebay use a 68000 family embedded chip, which is much less capable than the Pentium family chips most of us have. But, because it's built into a board designed for real time it can accept encoder feedback at Mhz rates(20 million+ counts/second), something you need a Mesa board to handle on a PC. It can also update its servo loop at over 30 khz... the manufacturer claims a 32usec update time for the loop, and that's probably with less than 1u jitter. They can generate steps for stepper motors at over 6 million/second.

Galil uses dedicated hardware for the high speed I/O, no different than a PC...

It's actually very different from a PC. The critical differences are in the fact that the Galil (and many other embedded systems designed for a specific purpose) aren't generalized hardware... they're not meant to control a machine tool one day and be a word processor the next.

Small differences in architecture like dedicated IRQ lines and close coupling between the CPU, DAC hardware, and dedicated IO chips can give a huge difference in I/O performance. Even if a controller were built with identical chips to a given PC, the fact that it's designed as a limited purpose system rather than a general purpose computer gives it a big advantage for those specific tasks.

This is the same as the reason that boards from Mesa work so well... the FPGA Mesa uses is neither as complicated or as expensive as a PC's CPU chip, the circuits on the board are much simpler than a PC, and the software loaded into the FPGA is much, much simpler than an OS like Linux. Because the software/hardware combination is designed to excel at a limited set of tasks however the Mesa cards offer a big performance improvement over the PC alone for any work that can be fully offloaded to the card, like (simple example) step generation. Even better, the FPGA can be re-programmed, effectively "re wiring" the board for a different special set of tasks.

I'd agree with you if the Galil controllers were PC motherboards in another package, but generally they're not (at least the ones I've seen). They're special purpose computers designed for one job, and not the same except in general concepts.

Erik

Just saying that the 20 MHz encoder inputs and 6 MHZ step rates are made possible by special motion control hardware (not something the 68000 does). This is the exact same situation as a PC.

The PC limitations on servo loop rate are mainly due to running a full multitasking OS
on the PC. I have no problem running >200 KHz loop rates on a dedicated PC

Really? That's very interesting. It's been my belief that the "extra" circuitry needed to be general purpose in a modern PC was more of a component of the speed than that.

By a dedicated PC, you mean one that runs only a CNC control program on the bare hardware, or do you mean something like TurboCNC running on an "OS" like DOS? More details if you can share them, please

I'd expect that a PC without OS would be difficult to connect to IO boards to generate analog command signals for either +/-10V or sinusoidal commutation.. did you do anything like that?

I'm now curious to know if a PC (eg. an old 1 Ghz PIII) could be booted from bare metal with a couple ISA based I/O cards in it and be given a simple kernel to function as a dedicated controller, with the rest of the control functions happening on LinuxCNC on another PC.

Once upon a time I wrote an OS for 386 protected mode in assembly language... little bitty program, it might be fun to try that again

By dedicated I mean the PC was doing nothing but running a high
speed predefined trajectory and PID loop.

I did not do analog I/O or commutation (PWM and encoder counting only) but I dont think it would be any obstacle with proper interface hardware.

The trouble (even in embedded systems) comes when you start asynchronous multitasking. Also on PCs for higher I/O rates you need to use bus mastering (DMA)

If you use a bare PC you can make a decent high speed controller but you lose a lot over a system with an OS with file system and network support like linux. For example : communications: how do you do Ethernet communication on bare metal? Its possible but a fair amount of hardware specific work. If you are going to hardware specific optimizations its probably better done on an embedded device that wont change next week...

I suspect the the best architecture for high performance LinuxCNC system that retained linuxCNCs HAL flexibility would have a dedicated motion processor (no interrupts other than motion related timers) that runs HAL and does synchronous communication with a independent communications processor in contact with a (possibly remote) GUI.

M. Haberlers Machine-Kit work should facilitate making this kind of architecture possible

In the mean time if you do nothing more than run LinuxCNC on a headless PC
with a remote GUI you can usually improve latency considerably.

I would be temped to disable all hardware except motion I/O and Ethernet (no disk, (NFS mount a remote drive) no KB, no mouse, no video, no sound)

Hmm do Ethernet cards still have boot ROMs?