C++ OPC Browser

General Discussion
1

Hi All,

I dabble a bit in C++ as a hobby, and I recently thought it would be a fun idea to make my own OPC client/server environment with a small SQLite historian and an SDL frontend. I figure there’s potential here to make a lightweight, useful troubleshooting tool. For example, a user could specify a list of tags, poll high frequency data for a short period of time, and filter the list by which tags changed (and how) within short timespans, without going through all the hassle of adding tags to their actual historian environment. They just plug in their laptop, establish a connection to the PLC, and start getting data. I’m aware of Softing and Unified Automation, but I don’t want to pay for their stuff. I want to use the free OPCUA library available here.

I’m experienced with the other tools mentioned above (SQLite and SDL), I understand common network protocols, and I’ve programmed small local messaging applications for networks before (for fun)… but I know very little about OPC UA, and I don’t know where to start, so I was hoping to fire off some really general questions to you guys at Ignition to help me get over this initial hurdle. Here’s what I want to know:

What defines a client-server relationship in OPC-UA (generally speaking. For example, I want to know if clients can read and write to servers, or read only. Are servers broadcasting their own existence, or their data, or do clients broadcast requests foravailable OPC servers. That kind of thing)?
What defines the OPC-UA client/server/PLC relationship (generally speaking again. For example, are the PLCs usually just volunteering information onto the network, or do OPC-UA servers query that information and then rehost it, or can clients also query the PLC)?

Do any PLCs act as OPC-UA servers?

Can I expect to just write an OPC-UA Client/Server and start reading data from PLCs, or do I really need to make specialized drivers for each type of PLC?

If I need to write specialized drivers, is there documentation out there on the protocols expected by Rockwell PLCs for tag queries by OPC clients/servers?

Answers to any or all of the above questions will be much appreciated.

ETA: Also links to whitepapers and informative websites are acceptable, but I would really be grateful if you guys also summarized useful information for me here…

2

For example, I want to know if clients can read and write to servers, or read only.

Depends on the server. One of the attributes on a Node is its AccessLevel. Generally read/write, though...

Are servers broadcasting their own existence, or their data, or do clients broadcast requests foravailable OPC servers.

They might... they might not. There might be a discovery server in the picture, there might not. The most straightforward situation is that each OPC UA server has an endpoint URL that clients use to connect directly to it. Less common is that servers are configured to register themselves with a discovery server, which clients query for a list of servers.

What defines the OPC-UA client/server/PLC relationship (generally speaking again. For example, are the PLCs usually just volunteering information onto the network, or do OPC-UA servers query that information and then rehost it, or can clients also query the PLC)?

Classically, OPC servers query the PLCs for data using the native protocol for that vendor and model. Newer PLCs are starting to have OPC UA built in so an OPC UA client can connect directly to the PLC without going through an intermediary server (like Ignition's built-in server, or Kepware).

Do any PLCs act as OPC-UA servers?

Some newer ones, see above.

Can I expect to just write an OPC-UA Client/Server and start reading data from PLCs, or do I really need to make specialized drivers for each type of PLC?

If you're going to be writing the server, then you also need to write specialized drivers.

If I need to write specialized drivers, is there documentation out there on the protocols expected by Rockwell PLCs for tag queries by OPC clients/servers?

Sometimes. Depends on the vendor, model, and protocol. Rockwell has decent enough documentation on accessing Logix tags, for example. On the other hand, Siemens has zero documentation and everything anybody knows about it is reverse engineered.

1 Like
3

Wow, thanks a bunch for the reply! Very helpful. I’ll be working on this in my spare time, so f I ever finish the project, I’ll let you guys know :slight_smile:

Also, all kinds of other information anyone thinks might be useful is welcome here.

4

In a generic sense, clients make requests and servers respond to requests. Requests can be reads, writes, subscribes, unsubscribes, method calls, et cetera and et cetera. In most cases, TCP/IP is used to create a connection for requests and responses, which the client initiates.

An OPC server, to be more than just a toy, generally has drivers that make it a client to other devices, like PLC and RTU products. This is true even if the OPC server is built into the PLC – the driver side just has direct access to the target information.

The OPC client to server connection uses a publicly-purchasable protocol specification which you will need for any significant development. Or you will need to piggy-back on a development kit’s documentation, to the extent that kit is documented at all…

For drivers for PLCs, you will need that PLC’s branded protocol specification. Some of these are publicly purchasable, like Ethernet/IP and friends, while others are free. In my experience, most PLCs do not advertise their presence on a network, though many will respond to pings from a suitable tool.

1 Like
5

Grumble. I should pay more attention to the bubble indicator on the forum… /-:

6

FWIW, the $0 membership level includes access to the specifications. Which you WILL need if you actually want to build anything, even if you do use an SDK.

2 Likes
7

Thanks for the info! I didn’t know that the protocol specification wasn’t free. And those links are really helpful :slight_smile:

8

Has this always been true? I haven't dug into OPC itself much, and not recently, but I didn't recall a free membership level.

9

It’s been true for a while now, but no, I don’t think it was always free.

10

Fair warning: this one specification, with its various pieces, is more than 2300 pages long. The free Logix Data Access manual is 84 pages, but is difficult to understand without the Ethernet/IP spec to flesh out some of its descriptions.

1 Like