OPC UA

Simple OPC UA (Pub/Sub) is not a fieldbus. It is positioned higher in the Maslow hierarchy (the automation pyramid of Industry 4.0). Naturally, this implementation of the protocol is slower. However, regarding OPC UA FX, it somewhat merges two levels of the pyramid. (Although in promotional images, it represents the entire pyramid)  .
Its speeds supposedly exceed Ethercat, at ~40 ns and less. Briefly, this is due to the efficient separation of traffic (a separate lecture would be needed for this ).I understand you might have made a slight error in naming it OPC UA over Ethercat - such a thing doesn't exist (at least for now). The names are constantly changing: sometimes it's OPC UA over TSN, OPC UA via TSN, and the latest active name is OPC UA FX. Personally, I would have stuck with the name OPC FX to avoid confusion with other versions. I even sketched a logo for them  
On Monday, I will finish the client and server. As I understand, they can be accelerated up to 10 milliseconds. I also came up with an idea for creating an OPC FX server. I will create a variable generator with a HAL input, and then in the posthal file, it will be necessary to link this input with the variable that needs to be made publicly accessible

rodw wrote:

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

 

My "aim" on the mqtt was to see if it would be "easy" to make a separation with the GUI and realtime stuff. I was hoping for something around 10ms update rates so that the GUI updates would look nice, its mostly the updating of position where you will notice the "lag". I would not be concerned if a "led" in the GUI turns ON/OFF 100ms later than it actually did.

But like stated before it was quite bad with mqtt, you would notice it immediately that the "refresh" rate on the position was far from nice.

I personally would not run anything real, like motion, over a non industrial protocol like ethercat. My "concept" was trying to run the real-time stuff on a some sort of a SOM etc. where it would only run a headless linuxcnc. Then you could use "anything" to run the GUI. This would of made "mass production" much easier as you don't have to worry about latency once you get the SOM dialed in the first time. The SOMs have much longer availability than "regular" pc's and cost sub 100$.

You can congratulate me. The library and OPC UA do not prohibit working at 1 ms. I did test it on localhost though. There is a lag of one sample, but everything works precisely. True, the CPU fan starts to buzz, but the temperatures are within working range, ~50-60 degrees. This is considering that my idle cooling is around 30-40 degrees.

TheRoslyak wrote:

You can congratulate me.

Congratulations.

LOL