Other ways to interface with LinuxCNC

Hi there!

As per wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Supported_Hardware, LinuxCNC does support a number of Hardwares, but all of them are kind of proprietary. I am asking if there is a more general way to interface with LinuxCNC. Let me explain.

In many of my projects, having a fully featured CNC controller core like LinuxCNC (with trajectory planning, PID tuning, homing cycles, etc...) would be very useful and I am not aware of LinuxCNC alternatives that are this advanced. The issue is that all of the listed Hardwares do not really allow to extend the system, they are just a bridge for a few motors and that's it. What I am thinking of is a solution that forwards the LinuxCNC outputs into a program of mine, where I can then control any hardware i like.

Think of it like a ROS node. Ideally there would be a way to connect LinuxCNC to a ROS node instead of a MESA card, and the ROS node would receive motor PWM values in realtime, and return encoder values in realtime, as needed by LinuxCNC. Once this bridge is created, any hardware can be controlled using the ROS node. Another option would be to have a non-ROS process running on the LinuxCNC computer that does what I just described, that simply sends this motor data to an Arduino. You see, as soon as I have a C++ program receiving the data from LinuxCNC I would be able to control ANY hardware with LinuxCNC (that is, small Arduino steppers, large BLDC servo motors, virtual CNC simulations, multi-axis robots, you name it).

See answers.ros.org/question/328506/creating...ontrolled-robot-arm/. Apparently there has already been interest in connecting LinuxCNC with ROS. I think what differentiates me from this post is that they want to receive just positions, and I am fine with dealing with PWM values and implementing PID controllers myself, if that's more realistic. Anything that works. I just want to outsource all the heavy kinematic calculations. I would be fine with a ROS solution, although I would prefer a non-ROS solution.

Now, are there already official solutions similar to ROS?
If not, what would be the easiest way to do it? Would it be easier to write a custom HAL driver that forwards the outputs via Ethernet, or to choose one of the already supported hardwares and reverse engineer its protocol to fake a real device?

All the Mesa FPGA source code is open source. I've playing around with running the firmware on 2 different Spartan 6 Dev boards.
There's a number of open source projects that have been using boards supported by the Litex project. Litexcnc is one, Litehm2 another and Linuxcnc-RIO supports lattice ICE40 boards and Tang boards as well.
Cyclone IV Dev boards should also work.
But the thing is dollar for dollar the Mesa cards are great value compared to "rolling your own".

Now none of this is meant to distract you, just pointing out realities.

Since linuxcnc is modular anything is possible and you will get support.

Good luck and keep us all updated.
The Remora project has quite a bit of hardware that it will run on.

Household appliance should have a simple knob.

The bloody stove\hotplate combo at home has some weird setup that I can't get my head around.
All I want is 6 knobs that go lo-hi for the hot plates oven & grill and a mechanical timer.
Maybe I'm a Luddite hahaha

Thank you for the reply!
I did not mean proprietary in that sense, what I meant is that all available systems do kind of their own thing, you either buy hardware A and run software A, or buy hardware B and run software B, etc.

My goal would be to have a piece of software running on the LinuxCNC PC, that has all the data, *without* any external hardware whatsoever.

Yesterday I finally got a huge leap forward by finding HAL2Arduino. It does about what I want, it is a HAL driver that forwards the data to a custom Arduino firmware, and then the Arduino can do its own thing. What I am imagining is just the HAL driver itself, but written in C++ and with a modern, well-documented API.

I did look at ROS and found out that it is not good at all for realtime control or synchronized motion. I just mentioned it because I think it demonstrated the idea of an extensible interface. I do not have or want Mesa cards, that is the entire point of my project. Ideally the only hardware I need is an Arduino, that receives motor data via Ethernet in realtime.

As said, HAL2Arduino looks very promising, from my understanding it is a python program that is loaded as a HAL component, and this python program gets the data from LinuxCNC and passes it to an Arduino with a HAL2Arduino Firmware. This is exactly what I want, but JUST the part that talks to LinuxCNC, minus the Arduino Serial interface.

Talking about HAL: In the HAL2Arduino source code it states that this HAL solution is only for testing and has a lot more lag than a proper parallel port, and should never be used on a production machine. Now, is this always the case for HAL, or would it be as fast if i write the HAL component in C++ and load it as an RT component?

Now, is this always the case for HAL, or would it be as fast if i write the HAL component in C++ and load it as an RT component?

The problem is that python is an interpreted language and as such not suited for real time applications so, yes, you would want to use a compiled language like C++, compile it and load that as an rt component.
Also I believe that ROS 3 is real time capable and 'machinekit' (a now largely abandoned fork of linuxcnc) had an interface for ROS, although I'm not sure whether that was for ros2 or ros3.

I don't believe you can use your arduino for step generation becauuse the USB connection to the PC is not going to be real time (due to USB architecture limitations)

Yes, the hardware interface would have to be real time capable as well, which USB is not.