OPC UA

I'm currently developing an OPC UA client. It will work on the following principle. There will be a YAML file in which you'll need to specify the connection parameters to the OPC UA server you want to connect to. There will be an option to create separate threads in case you don't want to use the servo base traj threads. This is necessary to set the update interval you want. You will need to write a list with the name of the variable, its type, and nodeId. And accordingly, in the HAL environment, you will have a variable that retrieves values from the OPC UA server. If everything works as I plan, then by the same principle, a Modbus client can be made. It seems someone has done something similar, but I think I can do it better

In general, I've succeeded. Now it's possible to connect to any OPC UA server through HAL. Unfortunately, I can't get it to go faster than 50 milliseconds. That's a feature of regular OPC UA. (Or maybe it's blocked by the library). It can be faster if it's connected to OPC UA TSN. For now, I'll post a video for demonstration. Later, I'll make it publicly available after tidying up the code. So, what's happening in the video: I start linuxcnc, launch my OPC UA server, then add the OpcUaClient component. I attach the value of the stream. The speed is set to 50 milliseconds. It doesn't work any faster. The same principle can be applied to Modbus. Is there anything similar? But quite possibly mine will work better)) Just in case, I'll also post another video for those who don't understand what OPC UA is.





 

qtopcuaserver.h is on qtopcua/test folder .... is an example...

So, I'm releasing a more or less working version. The hardest part I had to deal with was making the logs and reconnect work. There is one drawback that I don't know how to deal with. When the connection is lost, a latency error occurs. After the connection is restored, everything returns to normal. Since everything operates in a separate thread, it seems to have no effect on all other functionalities.
github.com/TheRoslyak/OpcUaHalClient

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