OPC server implemented on a teensy 4.1

Fluxanode

Well-known member
Is it possible to implement an OPC server or server on a teensy 4.1? Has this been done? Really anything OPC UA?
 
Last edited:
I’m here for the audio stuff but my day job is Controls. I’ve learned that anything is possible but what is feasible? So what are you looking to achieve?
 
There is an open source UA server written in C99 that is intended for embedded. Try open62451 (or whatever thst standard is)
 
First - I am trying to send pressure values (1 to 4 sensors) and modbus values acquired from a coriolis meter to a OPC server that is also connected to a PLC using a teensy 4.1 to avoid purchasing more PLC modules (due to the cost and lack of slots, and the teensy box is already in place reading the sensors).
Second - I am working with open62451 now and moving slowly. But it seems to be the only practical option?
Actually speed is one issue as the stakeholder wants 20ms data xmission to the OPC server and I am already reading the sensors, serving up a webpage, sending 1 second WITS data via RS232 and RS422 ports and storing data on a SD card.
I am implementing OPC as a client as it seems to be a little lighter.

Thanks for any advice or comments...
 
Joe, I know, but no. They want to use ethernet to the OPC server. I'm kind of boxed in here. Of course if it can't be done with the OPC and I prove it can't be done...
 
SDK in the OPC world seem to be vehicles for consulting firms to milk corporate clients. I’ve never seen one usable without ”expert assistance“.
 
if you’re insisting on staying with the teensy then use modbus tcpip to transfer the data? Or why does it have to be any of that if you have the data on a web page you’re already passed what opc was used for. You ca get off the shelf solution to pass the data from a server assuming you host a webpage on one back to the plc.

20ms is not feasible in this scenario though.

There are plenty of off the shelf systems that can talk to a flow meter and pass it in to a control system.

Having design these systems we always ended up moving the critical timed logic to a pc and the communication paths always took too long to the plc.

give the meter type data required and what controls will be used within a 20ms scan rate is required and I can point you in a direction
 
Advantech sell Adam modules which are professional level solutions that can be supported easily going forward.

But if this ends up being a project you just have to go with then feel free to share and ask.

Opc ua has been going for a while and I’ve been along for the journey but only a few months ago it became workable. But I’m on a Siemens system with aveva for that so you can imagine they’ve been on it for a while.

Which method of data transfer are you using already to web page as once it’s in the pc you can get off the shelf data transfer.

Maybe a simple block sketch of data path required
 
bk40, like I said i have to pursue this course for now. The web page is a simple http on port 80. nothing special. the developer of the pc app wants to get the data from the OPC server he has implemented. I have told him 20ms isn't going to happen that i am going to send the data to OPC by exception with dither. So he gets best effort data really.
 
bk40, like I said i have to pursue this course for now. The web page is a simple http on port 80. nothing special. the developer of the pc app wants to get the data from the OPC server he has implemented. I have told him 20ms isn't going to happen that i am going to send the data to OPC by exception with dither. So he gets best effort data really.
Well in for a penny in for a pound.

What’s the plan 😉
 
Moving ahead one step at a time.
So far i have proved
  • TCP
  • framing
  • queueing
  • bridge/adapter/client flow
Proved it is feasible to do on a Teensy...

Still need message construction and the full implementation of the open62541.
 
Good luck with it. As I said I’ve been there before.

Previously we used many interfaces to the devices, all communication monitored and error controlled at the server then used an OPC central hub to link all the systems together. But that’s a commercial product that costs money so not something I can share. But was fun to develop.

Speed was a serious issue. We could poll and read the modbus tcpip data quick enough but passing and writing to the PLC was a bottleneck because the plc classes the opc writes as a low priority task unlike scanning its inputs. But the truth is you don’t need most of the information that quick so we had different poll loops. But this was a major amount of data from a flow computer not just the meter itself. So could be ok

Let us know how you get on
 
Moving ahead one step at a time.
So far i have proved
  • TCP
  • framing
  • queueing
  • bridge/adapter/client flow
Proved it is feasible to do on a Teensy...

Still need message construction and the full implementation of the open62541.
Would be interested to see a diagram of data flow. Very hard to understand from textual descriptions.
 
Proof of concept attached. tested with Siemens Step 7 PLC. had to jump through some hoops to get it to work but it is possible and fast enough.
 

Attachments

  • OPCUA_T41_Test_v0.50_2026-04-14.zip
    1.2 MB · Views: 8
I didn't look too closely at the code, but I did notice that you're specifying a MAC address. You don't need to do that with the QNEthernet library; it reads the internal one for you.
 
I didn't look too closely at the code, but I did notice that you're specifying a MAC address. You don't need to do that with the QNEthernet library; it reads the internal one for you.
shawn, will it make a difference? seems to work but i will change that if it is causing a problem?
 
When I build a project, I make an effort to "make it robust and correct" instead of "just get it to work". (I don't mean for this to sound like a criticism; it isn't.)

The disadvantage of using a self-selected MAC address (other than a "locally administered address") is that there's a small possibility of there being a collision if another device happens to use the MAC address. Manufacturers do the work of obtaining these addresses and keeping them unique so you don't have to.

Sure, your setup is likely to work, but if you put more than one of these devices on, now you're responsible for making everything unique yourself.

Even if you want to specify your own MAC address, may I suggest reading it from the Teensy's MAC address registers and using that instead? But if you're going to do that, why not use the code that's built into the library?

Hope those thoughts help.
 
When I build a project, I make an effort to "make it robust and correct" instead of "just get it to work". (I don't mean for this to sound like a criticism; it isn't.)

The disadvantage of using a self-selected MAC address (other than a "locally administered address") is that there's a small possibility of there being a collision if another device happens to use the MAC address. Manufacturers do the work of obtaining these addresses and keeping them unique so you don't have to.

Sure, your setup is likely to work, but if you put more than one of these devices on, now you're responsible for making everything unique yourself.

Even if you want to specify your own MAC address, may I suggest reading it from the Teensy's MAC address registers and using that instead? But if you're going to do that, why not use the code that's built into the library?

Hope those thoughts help.
Thanks I changed that! Let me know if you see anything else. I have integrated the OPC into a larger Data acquisition program and am getting good results so it looks like this can be done on a teensy!
 
Back
Top