Best way to do external controls for LinuxCNC

QtVcp looks great, although I've been trying to separate UI and control in LinuxCNC and push the UI side off of the realtime LinuxCNC system and onto either a remote web browser (via a server on LinuxCNC) and/or via UDP or another protocol into a prototyping environment like Grasshopper or Derivative TouchDesigner.

I still want a physical E-stop and maybe small direct physical interface on the LinuxCNC side (e.g. LCNC has a fancy pendant with a jog wheel and small display), but is otherwise running headless.

The UI doesn't run in the realtime thread. It runs in userspace and only talks through the APIs to the gcode command handler that runs in the realtime thread through NML.

You can make a machine with physical controls only by using hal and a little scripting. You don't even technically need to use the motion control functions and gui and just use hal and hal components to implement a control solution. Depending on complexity it works quite well.

I was thinking of making a gRPC server on top of the python api to expose some functionality but that's not a priority for me now. It shouldn't be a huge thing though, depending on what features you require.

I feel like we might have the same goals here. I need to familiarize myself much more with the LinuxCNC codebase, but I'm hoping to have several days next week to do so. I have been doing some work with Asyncio, it seems like having a true Async server, perhaps using gRPC AsyncIO, might be a good way to interface the realtime portions of LinuxCNC with external UIs.

You can't really interface python directly with the realtime space as python is not realtime code. Though grpc is in C so it's technically possible to write a realtime grpc server. Though that's a huge hurdle and way more effort than just using the existing python api.

Using the api to read and write hal pins works good enough. The only issue with the APIs is that the motion pipeline is not open so you cannot give it direct commands. It needs a one tiny change in the source from my understanding.

There are separate joint controller components so it's possible to do a bare multijoint controller on HAL only. But then all the trajectory planning motion coordination has to be done in the user application.

Thanks @Roiki. Do you know why Python 3 can't run as realtime code using PREEMPT_RT?

It's OK for me to lose the trajectory planner for this application as I am driving a linkage that is moved using a combination of rotary axes, so the standard trajectory planning is probably not useful in my case.

Because python is interpreted language and the python interpreter is not a realtime process.

Only kernel modules can run at realtime.