OPC UA

Kind of interesting after watching the first video. I've been working on sending pressure and flow data of an irrigation system from my back yard to Home Assistant. Its using a ESP32 device and JSON via MQTT to send the data to my HA server. Some plumbing fittings turned up today so its slowly proceeding.

Linuxcnc now has a MQTT interface in 2.9 and up.

I have not looked in detail but I wondered if the State Tags structure could be sent by MQTT as  a binary structure to complement the MQTT capability..
But of course the downside is none of these communication protocols support a real time environment. But there is no reason why a OPC-UA console couldn't be used to cotrol linuxcnc instead of the available GUI's

for rodw
MQTT is not exactly an industrial protocol. It's more for tasks like: you're sitting in the office and want to check how your kettle or microwave at home is working or control them. For this, you need to choose a broker server on the internet (paid or free).
OPC UA is an industrial solution. It's better suited for operating machines and other industrial equipment. As for them not being real-time protocols, it's not entirely true: My experience with standard OPC UA showed it's limited to a frequency of 50 ms. However, the OPC UA TSN protocol theoretically works faster than Ethercat. I wanted to create an OPC UA TSN server, but the problem is that the rtapi_mutex_get() function doesn't work in RTAPI. This doesn't allow scanning the HAL environment in real-time. For now, the solution I see is to create TSN variables in parallel with HAL variables. Accordingly, this requires going through all the Linuxcnc sources and adding the creation of TSN variables next to HAL variables.
Here is the best presentation on OPC UA TSN (FX) that I've been able to find so far.
2020.ieee-etfa.org/static/files/2020/tal...des.f5c2b5d40109.pdf  
The open62541 library allows everything to be done. The technical limitation is that you must have an Intel Ethernet controller (i210/211, i225/226) onboard

Don't malign MQTT to quickly. Its the underlying rechnology  in OPC UA's PubSub.
You have to remember that CNC is a very small subset of the fieldbus world so what we are looking for is not necessarilly what industrial automation engineers want.

Its not necessary to use public MQTT brokers, you can run up Mosquitto broker on Debian from the Debian repositories and host it in house on any linux box. I have done this. One industrial application I have explored is in warehousing where a packing station sends weights and dimensions from a ESP32 device to a MQTT broker and the ERP system can subscribe to that topic and receive detailed shpping data for audit purposes. I have started work on such a system that incorporates a low cost bluetooth tape measure. DHL lost a parcel on me recently and asked me if I had CCTV on my loading dock!

I don't see using Intel NIC's is  a limitation. there is a reason why Beckhof exclusively  uses Intel NIC's in their Ethercat techology.

In my home application, the MQTT broker is hosted on a Raspberry Pi that is also running Home Assistant. HA manages the GUI and controls all number of things around my home.

I'm not saying that MQTT doesn't have a right to exist. Everything you described falls into tasks like a smart microwave. And the very existence of a broker complicates the task. Each manufacturer has its proprietary solution for data transmission. And each one claimed, until today, that their solution was the best. But in reality, only those who worked with their equipment developed it. OPC UA became the case where all leading manufacturers agreed and said that they have chosen a universal solution. This ensures the integration of equipment from Beckhoff, ABB, or B&R without external modules.
Not all stationary motherboards have an Intel 210 series onboard. What I meant was that, for example, the 219 series is not suitable for TSN.

Maybe a year or 2 ago I did a quick and dirty test using mosquitto (Python) to read linuxcnc data and send it over to a ”server”.
I was using localhost just to test how fast I can do pub/sub and I was barely getting 10x/sec transfers and even that lost some data (qos 0).

Based on that test I stopped doing anything further as it was way too slow.

If you can get the OPC UA working faster that your initial test it would be very interesting. I have always wondering how much work it would be to run linuxcnc headless and have the UI running over websockets or something similar.

I would not expect amazing performance from OPC UA if it remains tied to the TCP stack.
Earlier this year I attended a seminar about Ethercat where Martin Rosten the head of the ETG in Germany presented.
He went into some detail about the underlying packet structure of ethercat, TCP and other Fieldbus competitors. The Ethercat protocol is vastly superior to others. UPC UA was not mentioned at that time.
Profibus 5-10ms
Ethernet/IP 8 ms
Ethercat 1000 I/O ports updated in 30 usec and 100 servo updates every 100 usec
I would be following Beckhoffs implementation of OPC UA over Ethercat very closely if you want Real TIme performance