Best way to do external controls for LinuxCNC

I would like to set up a prototyping/development environment that feeds from Rhino/Grasshopper into LinuxCNC. The goal is to do development inside Grasshopper and then move code over to LCNC. What is the best way for me to approach this? 

Grasshopper can generate and transmit GCode, but I'd also like to be able to interface LCNC's HAL directly (e.g. command a step & direct movement from Grasshopper and then feed that to the HAL). There are some servos that will be acting as rotary axes and I would like to interface them at a lower level (playing with absolute encoder feedback). 

Thanks,
FDP

What language are you targeting?

There's no way to directly interface with hal the way you envision it. You can look at the user interfaces for pointers how they interface with the core. Or you can try to make sense of the NML api, which is the underlying method to talk to the realtime core. The motion control pipeline also is not open do you need to feed it with gcode commands, either through gcode files or MDI commands.

If you work in python, I can give you some pointers.

Hi

Maybe hal-core is something to try out. github.com/grotius-cnc/hal-core
To create a interface for Grasshopper you can look here for idea's : github.com/grotius-cnc/hal_trajectory


 

I am working in Python!

Thanks. @Grotius There are some other threads where you seemed to be doing things with the UI and perhaps EtherCAT that I was looking at, now I need to try to sort out my bookmarked threads and figure out what they were!

I am considering this vs. just trying to directly interface EtherCAT (or one of the other ethernet step & direct appliances) from Grasshopper. My feeling is that LinuxCNC is probably the better, but more complicated way to go.

hal_trajectory looks super useful!

Ahh we catch a Python guru !

Maybe look at QtVcp. That's a cool environment for Python.
Then you could write a component to interact with grashopper.
After you know the above, you can connect to Ethercat (last stage of development)


 

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.