Advice on OPC

[dterry]

Hello all,

I recently was presented with the task of integrating a Mitsubishi PLC into our systems. After a good deal of googling, I think the best (maybe only) way to get the data out is going to be via OPC, thanks to their proprietary Melsoft protocol. If anyone else knows a better way, feel free to stop me here.

Now, we are currently expanding our data generating capabilities (hence the PLC), and I have been thinking about rearchitecting the way we collect data from all over our facility to be more flexible.  Since I may be required to use OPC anyways, I was considering using an OPC server to aggregate all of the facility data, and then redistribute to control rooms, historical logging, etc.  To do this, we would need to integrate our cRIOs and operator PCs into the OPC environment as well.

I don’t see OPC mentioned very often (in fact it returns 0 results on LAVAG), and a lot of the stuff I see these days seems to be more “roll your own” or lower level (raw TCP/UDP, 0MQ, Network Streams, Transport.lvlib etc.) rather than a monolithic abstracting bridge like OPC. Unfortunately, I won’t have time to roll my own in the near future, but LVRT supports supports OPC UA, so I could potentially integrate the cRIOs fairly easily.  Unfortunately, I think I would have to use LabVIEW DSC (or datasockets...) to integrate the PCs.

I would be very grateful if anyone has the experience to comment on the following or anything else related to using OPC.

• What are viable update rates for OPC tags?  I will need at the very (very) least 250 ms update rates. 
• Is OPC typically low latency (time from data generated to to client received)?
• Does anyone have a recommendation for a product (NI OPC, Kepware, etc.)?
• Is OPC still popular, or are there other options for data aggregation that would be better suited to a new application?
• What are the options for logging and alarming with OPC?
• What are the options for talking to OPC from LabVIEW?
• How robust are the OPC connections in regards to reconnecting if a wireless connection is temporarily lost?

Thanks in advance!

[Tim_S]

I believe Mitsubishi PLCs also talk Modbus.

There is a big difference between OPC and OPC UA (this was pointed out to be on these forms, so I know there is at least one entry). I've yet to look up the difference. I am familiar with OPC, so my comments relate to that save where noted.

There is a shipping example with LabVIEW on OPC using datasocket.

I recommend sending a data block instead of individual tags, particularly if you have a lot data. There is overhead with each tag that can be problematic. Down side to a data block is having to parse out the information you're interested in.

Meeting your update rate could be problematic. OPC is meant for process control (the acronym is "OLE for Process Control"). OPC goes through OLE which has the lowest priority Windows can assign. Anything with normal or high priority can block the OPC communication for 10s of seconds. OPC UA does not do this, so doesn't have the issue.

I've used KepWare before and have had nothing but good experience with it. I did have to break up a data block into multiple once it reached somewhere around 128 bytes as communication stopped above that limit. I expect that's an OPC spec rather than a KepWare limitation. Don't know if KepWare can do OPC UA.

I expect OPC isn't as mentioned as PROFINET and Ethernet/IP have become more dominant. It still has its applications.

For logging and alarming, I believe LabVIEW DSC has that built in otherwise you have to make your own. I believe DSC can do OPC UA.

I've never tried wireless, so can't fully answer about that one. I have had ethernet cables unplugged and PLCs taken out of run mode, and always had good recovery with that.

 

[dterry]

Well, looks like Google is better at this search thing than whatever platform LAVA runs on haha.

6 minutes ago, Tim_S said:

I believe Mitsubishi PLCs also talk Modbus.

Good to know on this, I already have a Modbus abstraction that works well, so this could save me a lot of time!  I'll look into it further.

7 minutes ago, Tim_S said:

Meeting your update rate could be problematic. OPC is meant for process control (the acronym is "OLE for Process Control"). OPC goes through OLE which has the lowest priority Windows can assign. Anything with normal or high priority can block the OPC communication for 10s of seconds. OPC UA does not do this, so doesn't have the issue.

This is enlightening.  I haven't been able to try the connection with the PLC yet, but did try with OPC UA on cRIO, so that probably explains why I saw no issues with updates.  That will be difficult to work around, since the PLC is governing a high speed motor that I will need to programmatically monitor and control 

10 minutes ago, Tim_S said:

For logging and alarming, I believe LabVIEW DSC has that built in otherwise you have to make your own. I believe DSC can do OPC UA.

Yea, it does have logging and alarming built in, as well as OPC UA (same API as LVRT), I just had bad experiences with it in the past and was hoping there was something better (or that it has gotten better in the past 5 years).

Thanks for all of your input, definitely helps me get started!

[smithd]

22 hours ago, dterry said:

• What are viable update rates for OPC tags?  I will need at the very (very) least 250 ms update rates. 
• Is OPC typically low latency (time from data generated to to client received)?
• Does anyone have a recommendation for a product (NI OPC, Kepware, etc.)?
• What are the options for talking to OPC from LabVIEW?
• How robust are the OPC connections in regards to reconnecting if a wireless connection is temporarily lost?

Its worth pointing out that an OPC server is just a plugin architecture with a bunch of drivers so i don't think you can reasonably quote performance numbers. First off each driver works differently, so for example a modbus driver would poll at a configured rate while the Mitsubishi driver might be able to use events of some kind. Kepserver at least has a threading model such that, for example, several modbus items in the same group will poll in series. I believe the client-side updates work similarly. So the answer is I think closest to "some stuff will go fast, some stuff will not". This also answers your wireless network question -- it depends on the driver.

I believe the shared variable engine always acts as an OPC device, regardless of if you have DSC installed or not. You'd need kepserver to link to it but its there. (http://digital.ni.com/public.nsf/allkb/CC9CDD577F041786862572120061EB5A)

Other options I've noticed lately:

• UA now has a .net driver if you want to avoid the scary DSC one: http://opcfoundation.github.io/UA-.NET/
• Eclipse foundation has been slowly funding a scada system which is getting slowly better and has decent support now: http://wiki.eclipse.org/EclipseSCADA/Documentation/SupportedProtocols (not a server itself)
• I've sort of been watching these guys for a few years, they are more of a full solution (alarming, logging, everything) but it seems like they're doing good work towards modernizing some of this stuff, and they also work with standard OPC client stuff: https://inductiveautomation.com/scada-software/scada-modules (not a server itself)

Quote

There is a shipping example with LabVIEW on OPC using datasocket.

Datasocket is never a good idea. Just say no

Edited February 16, 2017 by smithd

[JKSH]

10 minutes ago, smithd said:

Datasocket is never a good idea. Just say no

May I ask why?

Off topic: One reason I still use DataSocket in LabVIEW is because that's the only way (that I know of) to programmatically read/write Modbus I/O server data without having to create bound variables: http://forums.ni.com/t5/LabVIEW/Can-I-write-to-Modbus-I-O-Server-addresses-without-creating/td-p/2848048 I'd love to know if there are any alternatives.

[smithd]

9 minutes ago, JKSH said:

May I ask why?

Off topic: One reason I still use DataSocket in LabVIEW is because that's the only way (that I know of) to programmatically read/write Modbus I/O server data without having to create bound variables: http://forums.ni.com/t5/LabVIEW/Can-I-write-to-Modbus-I-O-Server-addresses-without-creating/td-p/2848048 I'd love to know if there are any alternatives.

Well, I wrote a whole library so I would never have to use modbus I/O servers ever again, so I'm not the person to ask on the second part

As for datasockets themselves, they run in the UI thread and block. So for example someone resizing their window or opening the file menu and looking around will cause datasockets to block. You also can't run code which requires either the UI thread or root loop (I cant remember which) per this idea exchange request: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-it-possible-to-dispatch-VIs-dynamically-when-the-UI-thread/idi-p/1579534

Unfortunately, I can no longer find my kb on the subject, maybe it got lost during some of the web upgrades.

Edited February 16, 2017 by smithd

[dterry]

8 hours ago, smithd said:

Its worth pointing out that an OPC server is just a plugin architecture with a bunch of drivers so i don't think you can reasonably quote performance numbers. First off each driver works differently, so for example a modbus driver would poll at a configured rate while the Mitsubishi driver might be able to use events of some kind. Kepserver at least has a threading model such that, for example, several modbus items in the same group will poll in series. I believe the client-side updates work similarly. So the answer is I think closest to "some stuff will go fast, some stuff will not". This also answers your wireless network question -- it depends on the driver.

Good point!  I suppose the benchmarks would then be more along the lines of "how fast can the server turn it around".  I like the idea of event/change based updates as opposed to polling, but you are right that it will be very driver dependent.  Honestly, I wish I could just get the data directly in LV.  That way I can use the data as I need it now, and build my own data server when I have time!

Any reason to go with the NI OPC Server over the Kepserver?

8 hours ago, smithd said:

I believe the shared variable engine always acts as an OPC device, regardless of if you have DSC installed or not. You'd need kepserver to link to it but its there. (http://digital.ni.com/public.nsf/allkb/CC9CDD577F041786862572120061EB5A)

Don't think I knew that ... wonder if it is true of RT as well.  Not that I'm looking to dive into the SVE right now, but good knowledge to have anyways.

8 hours ago, smithd said:

Other options I've noticed lately:

• UA now has a .net driver if you want to avoid the scary DSC one: http://opcfoundation.github.io/UA-.NET/
• Eclipse foundation has been slowly funding a scada system which is getting slowly better and has decent support now: http://wiki.eclipse.org/EclipseSCADA/Documentation/SupportedProtocols (not a server itself)
• I've sort of been watching these guys for a few years, they are more of a full solution (alarming, logging, everything) but it seems like they're doing good work towards modernizing some of this stuff, and they also work with standard OPC client stuff stuff: https://inductiveautomation.com/scada-software/scada-modules (not a server itself)

Datasocket is never a good idea. Just say no

Cool on the .net driver, if I go this route, I'll have to check it out.  I'm assuming Linux RT == no .NET unless NI has worked out something fancy.  Thanks for the other links, I'll check them out!

 

[Tim_S]

41 minutes ago, dterry said:

Any reason to go with the NI OPC Server over the Kepserver?

My impression is NI partnered up with Kepware some years ago (based on some long-ago, mostly-forgotten announcement, so take this for what you will). I expect the two are the same under the hood.

[Tim_S]

9 hours ago, smithd said:

UA now has a .net driver if you want to avoid the scary DSC

Went to go look at this. .NET has been, well, let's say less than pleasant to work with. My recent torture experience with this has been one that was customer supplied. Not sure if I want to delve into .NET too often.

[smithd]

3 hours ago, dterry said:

Any reason to go with the NI OPC Server over the Kepserver?

 

Cool on the .net driver, if I go this route, I'll have to check it out.  I'm assuming Linux RT == no .NET unless NI has worked out something fancy.  Thanks for the other links, I'll check them out!

 

NI OPC==kepserver

Yeah you can always build .net applications on linux using mono or dotnetcore or whatever we're calling it these days, but I don't think labview rt has integration yet so you'd be calling command line stuff.

[Neil Pate]

Don't forget .NET calls in LabVIEW are extremely slow compared to DLL calls, something to do with the managed memory aspect. I seem to remember even simple calls taking several ms to return. 

[jacobson]

On 2/16/2017 at 7:51 AM, dterry said:

Any reason to go with the NI OPC Server over the Kepserver?

Going in the opposite direction, if you are going to use an NI OPC Server, that will force you to use an NI Client, the Server will reject a connection from a non-NI client (UA or DA).

On 2/16/2017 at 7:51 AM, dterry said:

Don't think I knew that ... wonder if it is true of RT as well.  Not that I'm looking to dive into the SVE right now, but good knowledge to have anyways.

I haven't tried to connect to a cRIO's SVE with a OPC DA client but I would not expect that to work. My understanding is that the SVE acts as a DA Server (at least in the windows context) and because OPC DA is based on DCOM it wouldn't be able to run on on a cRIO or any other non-Windows target.

[jacobson]

Another thing I forgot to mention.

You aren't going to be able to use the Datasocket API on a cRIO to read an OPC DA tag (from my testing). I tried this the other day and if you have any URL starting with opc:// you will receive an error that it isn't a supported communication protocol.

[ShaunR]

On 2/17/2017 at 11:44 PM, jacobson said:

Going in the opposite direction, if you are going to use an NI OPC Server, that will force you to use an NI Client, the Server will reject a connection from a non-NI client (UA or DA).

OK. So how does it differentiate between an NI or non-NI client?  

[Mads]

On 18.2.2017 at 0:44 AM, jacobson said:

Going in the opposite direction, if you are going to use an NI OPC Server, that will force you to use an NI Client, the Server will reject a connection from a non-NI client (UA or DA).

We use NI's OPC UA server-functionality (currently part of NI RT and DSC) and it works fine with other OPC clients. I would have been extremely surprised if it did not, after all much of the point of using industry standard protocols is to be able to exchange data between parties from different vendors....

Prior to the OPC UA API in LabVIEW we used Kepware when we needed to be an OPC DA server, and Datasocket when we could operate as a client. As people have mentioned here before using Datasocket has its weaknesses, but we avoid some of them by implementing it as a service (no GUI to interrupt the UI thread...). So the datasocket OPC-bit is in a service, which then has a  proprietary TCP/IP based server-protocol to be used by a client application (running in the system tray) that acts as its GUI.

[jacobson]

11 hours ago, Mads said:

We use NI's OPC UA server-functionality (currently part of NI RT and DSC) and it works fine with other OPC clients. I would have been extremely surprised if it did not, after all much of the point of using industry standard protocols is to be able to exchange data between parties from different vendors....

Sorry I wasn't too clear.

If you use the OPC UA Server API it should allow third party clients. Connecting to NI OPC Server from a third party UA client is not going to work and a Wireshark will show the server return Service Fault BadOutofMemory.

[Neil Pate]

13 hours ago, jacobson said:

 Connecting to NI OPC Server from a third party UA client is not going to work and a Wireshark will show the server return Service Fault BadOutofMemory.

Just so I am clear here you are making the distinction between OPC-UA and plain-old OPC?

As long as I can connect to OPC-UA server from an OPC-UA client this is good enough for me. 

 

Edited February 21, 2017 by Neil Pate

[jacobson]

NI OPC Servers (the standalone application) supports connections from NI clients using both OPC DA and OPC UA for data access. NI Clients being key here so if you try to use an Ignition client, for example, you would not be able to connect and would see the above service fault if you looked into the wireshark. This was a service request I handled and I confirmed with our R&D team that it is expected behavior.

Alternatively, you can set up an OPC UA Server using the API from the DSC or RT modules. I obviously can't test every setup but, as far as I know, you can use any client to connect to a server built this way.

[JKSH]

4 minutes ago, jacobson said:

NI Clients being key here so if you try to use an Ignition client, for example, you would not be able to connect and would see the above service fault if you looked into the wireshark. This was a service request I handled and I confirmed with our R&D team that it is expected behavior.

I'm curious: What's the rationale for supporting NI clients only?

 

4 minutes ago, jacobson said:

Alternatively, you can set up an OPC UA Server using the API from the DSC or RT modules. I obviously can't test every setup but, as far as I know, you can use any client to connect to a server built this way.

I can confirm that I've used the API to host an OPC UA server on a Linux RT CompactRIO, and this server is accessible to 3rd-party clients. My test client was UA Expert (by Unified Automation). I don't know the exact model of my customer's client, but I believe it was by Matrikon OPC.

[jacobson]

55 minutes ago, JKSH said:

I'm curious: What's the rationale for supporting NI clients only?

I could only guess the reason for it being this way so I'm not going to.