M
VB 6.0, RSLinx, Remote OPC
Numerous people have been asking about VB 6.0 and RSLinx and Remote OPC. (Including me!)
We've plowed through a lot of this lately, so here's what we learned. If anyone has more to add please feel free and edit till your heart's content, then repost this or email it back to
me at "[email protected]", mailto:[email protected] and I'll start building it up into a coherent document.
- Synopsis
RSLinx remote OPC to a VB client is mysterious to set up for most people. The major impediment is usually trying to understanding why a local connection works easily, but a remote connection
either fails totally or fails when the .IsSubscribed method is applied. Both failures relate to DCOM permissions setting in the
server or client machine. In short, if your client cannot connect at all, then the server's permissions are not correct. If the
client can connect but .IsSubscribed fails then the client's permissions are the culprit. (For a subscribed item the "server" makes a call back to the "client" which effectively makes both
machines "servers.") If you've been pulling you hair out over this for several days you probably know enough to stop here and go fix your problem. If not, read on.
- Requirements
The network between the two machines must be up and working. If you can't see the other machine in the network neighborhood, or ping the other machine by name, then get that working first. I
don't know if the DCOM connection will work correctly without TCP/IP installed. (OK, I know that should be obvious, but I've screwed it up before.)
The RSLinx server machine *MUST* be running RSLinx Gateway. RSLinx Pro *WILL NOT ANSWER* a Remote OPC call. Neither will RSLinx Lite nor the single node edition. (Sure it's all the same
software, and the only difference is the license bits in the evrsi.sys file. But this is how it works, and I'm sure Rockwell will have a lawyer call you if you hack the binary to defeat it.)
RSLinx Pro will work correctly for a local OPC connection, however you'll not make it work remotely.
The intended client machine should have RSLinx lite installed. This isn't absolutely necessary, but it will save you hours/days of frustration trying to get all the required registry settings
correct by hand. We're working on it, and I'll post as soon as we have something which will "just work" out of the box. The RSLinx
install routines will just magically set everything up for you. All you have to do is install RSLinx from the CD and just quit when it prompts for the key disk. You should also install the RsiOPCAuto.dll (RSLinxOPCAuto.dll for older versions).
- Background
OPC is built on Microsoft's COM/DCOM architecture. It's somewhat convoluted to understand, but much of the time it just "works"
well enough to not bother with it. Fortunately (or unfortunately depending on your frustration level), the RSLinx OPC server doesn't defeat Microsoft's default network security settings.
This leads to trouble in the RemoteOPC client when you try to use the .IsSubscribed method. Go to Google and search on DCOM for more information than you can stand about using dcomcnfg.exe to
configure DCOM.
Additionally, RSLinx OPC server requires (?) the Rockwell supplied RsiOPCAuto.dll OPC Wrapper rather than the standard OPC Foundation's wrapper dll available from a few places around the web. This may not be totally correct, but it's been our experience the past few weeks that the Rockwell dll works, and the others don't.
Intellution provides sample code for a complete OPC server and client at "http://www.intellution.com/opchub/opcsample.asp":http://www.intellution.com/opchub/opcsample.asp but it's neither GPL nor BSD style licensed. It does appear to be freely distributable, but I'm no lawyer. It's also way beyond the scope of this document.
The best place to start for a RSLinx client is with the Rockwell demo package PartialDemo.zip. We got it somewhere from the Rockwell Software site, but I can't find it there now. If anyone
has a link to it please let me know. We'll also try to pull together a sample application in the next few weeks.
- How to do it
First install RSLinx Gateway on the machine which will actually connect to the PLC/SLC what-have-you. Get it connected so that you can browse the device with RSWho.
Next, Select the DDE/OPC menu on RSLinx and configure a topic definition for your device. The details will depend on what you are polling. Just set it up for some reasonable values.
Now you need to set the DCOM permissions. Launch dcomcnfg.exe and make a few educated guess about how you want things configured. We just set everything wide open and are cranking back on
permissions little by little until we break it. This may not be a good idea if you don't have a secure network. Use your own best judgment here. It's your plant, and you've got to live with it.
There is a lot of information about DCOM permissions on the Microsoft and other web sites.
Get an OPC connection working locally first! This verifies that you actually have everything correct in RSLinx. And there's not much chance of the permissions problems getting in your way.
(Again, anyone know where the PartialDemo.zip file hides on the Rockwell web site?)
Once you have a local OPC connection working, install RSLinx on the client machine. You don't need an activation key on the client, so just put the CD in and when it prompts for the master disk bail out. Once you start RSLinx it will come up and identify itself as RSLinx Lite. Get everything set up in RSLinx Lite so that you can see the PLC/SLC on the RSLinx Gateway machine.
Again, you don't actually have to install and get RSLinx Lite working from what I can gather, but we've been unsuccessful figuring out all the various registry settings required, the parts necessary to put into a VB setup package, etc., but installing RSLinx Lite just makes it all work.
Now launch dcomcnfg.exe on the client and open up the permissions to allow the user running RSLinx on the server permission to connect so that the call back functions work in the .IsSubscribed
method. (IF you don't want to get notification and just pool periodically, then you don't have to do this.)
Finally you can start working on your "client" application. If nothing works, i.e. you cannot create a group or add items on the remote OPC server, then you're getting stopped by permissions on the server machine. If everything works except the .IsSubscribed method then you're permissions are wrong on the client machine.
Monkey around with these until you get it to work. Contrary to my earlier thoughts, and a few posts as well, the Rockwell wrapper dll actually does work pretty well once you get the DCOM setting right. (My apologies to Rockwell for all the things I said late at night!)
- Bummers, possibilities
RSLinx does not use the OPC Foundation's wrapper dll. While this isn't really "bad" I thought that the idea was "interoperability everywhere" in the OPC world. A thought which comes to mind is to
take the OPC server code from the Intellution site and develop a more "vanilla" OPC server to act as a reflector to RSLinx. It could run locally on the machine with RSLinx acting as a client to RSLinx and a remote server to clients on other nodes. But that's way too much work for now, and I'm not sure how hard it would be to get the Intellution examples up to snuff for the
latest version of OPC.
It also occurs to me that the same technique could be used to create OPC servers for other programs which lack an OPC server. (Most notably Wonderware.)
Numerous people have been asking about VB 6.0 and RSLinx and Remote OPC. (Including me!)
We've plowed through a lot of this lately, so here's what we learned. If anyone has more to add please feel free and edit till your heart's content, then repost this or email it back to
me at "[email protected]", mailto:[email protected] and I'll start building it up into a coherent document.
- Synopsis
RSLinx remote OPC to a VB client is mysterious to set up for most people. The major impediment is usually trying to understanding why a local connection works easily, but a remote connection
either fails totally or fails when the .IsSubscribed method is applied. Both failures relate to DCOM permissions setting in the
server or client machine. In short, if your client cannot connect at all, then the server's permissions are not correct. If the
client can connect but .IsSubscribed fails then the client's permissions are the culprit. (For a subscribed item the "server" makes a call back to the "client" which effectively makes both
machines "servers.") If you've been pulling you hair out over this for several days you probably know enough to stop here and go fix your problem. If not, read on.
- Requirements
The network between the two machines must be up and working. If you can't see the other machine in the network neighborhood, or ping the other machine by name, then get that working first. I
don't know if the DCOM connection will work correctly without TCP/IP installed. (OK, I know that should be obvious, but I've screwed it up before.)
The RSLinx server machine *MUST* be running RSLinx Gateway. RSLinx Pro *WILL NOT ANSWER* a Remote OPC call. Neither will RSLinx Lite nor the single node edition. (Sure it's all the same
software, and the only difference is the license bits in the evrsi.sys file. But this is how it works, and I'm sure Rockwell will have a lawyer call you if you hack the binary to defeat it.)
RSLinx Pro will work correctly for a local OPC connection, however you'll not make it work remotely.
The intended client machine should have RSLinx lite installed. This isn't absolutely necessary, but it will save you hours/days of frustration trying to get all the required registry settings
correct by hand. We're working on it, and I'll post as soon as we have something which will "just work" out of the box. The RSLinx
install routines will just magically set everything up for you. All you have to do is install RSLinx from the CD and just quit when it prompts for the key disk. You should also install the RsiOPCAuto.dll (RSLinxOPCAuto.dll for older versions).
- Background
OPC is built on Microsoft's COM/DCOM architecture. It's somewhat convoluted to understand, but much of the time it just "works"
well enough to not bother with it. Fortunately (or unfortunately depending on your frustration level), the RSLinx OPC server doesn't defeat Microsoft's default network security settings.
This leads to trouble in the RemoteOPC client when you try to use the .IsSubscribed method. Go to Google and search on DCOM for more information than you can stand about using dcomcnfg.exe to
configure DCOM.
Additionally, RSLinx OPC server requires (?) the Rockwell supplied RsiOPCAuto.dll OPC Wrapper rather than the standard OPC Foundation's wrapper dll available from a few places around the web. This may not be totally correct, but it's been our experience the past few weeks that the Rockwell dll works, and the others don't.
Intellution provides sample code for a complete OPC server and client at "http://www.intellution.com/opchub/opcsample.asp":http://www.intellution.com/opchub/opcsample.asp but it's neither GPL nor BSD style licensed. It does appear to be freely distributable, but I'm no lawyer. It's also way beyond the scope of this document.
The best place to start for a RSLinx client is with the Rockwell demo package PartialDemo.zip. We got it somewhere from the Rockwell Software site, but I can't find it there now. If anyone
has a link to it please let me know. We'll also try to pull together a sample application in the next few weeks.
- How to do it
First install RSLinx Gateway on the machine which will actually connect to the PLC/SLC what-have-you. Get it connected so that you can browse the device with RSWho.
Next, Select the DDE/OPC menu on RSLinx and configure a topic definition for your device. The details will depend on what you are polling. Just set it up for some reasonable values.
Now you need to set the DCOM permissions. Launch dcomcnfg.exe and make a few educated guess about how you want things configured. We just set everything wide open and are cranking back on
permissions little by little until we break it. This may not be a good idea if you don't have a secure network. Use your own best judgment here. It's your plant, and you've got to live with it.
There is a lot of information about DCOM permissions on the Microsoft and other web sites.
Get an OPC connection working locally first! This verifies that you actually have everything correct in RSLinx. And there's not much chance of the permissions problems getting in your way.
(Again, anyone know where the PartialDemo.zip file hides on the Rockwell web site?)
Once you have a local OPC connection working, install RSLinx on the client machine. You don't need an activation key on the client, so just put the CD in and when it prompts for the master disk bail out. Once you start RSLinx it will come up and identify itself as RSLinx Lite. Get everything set up in RSLinx Lite so that you can see the PLC/SLC on the RSLinx Gateway machine.
Again, you don't actually have to install and get RSLinx Lite working from what I can gather, but we've been unsuccessful figuring out all the various registry settings required, the parts necessary to put into a VB setup package, etc., but installing RSLinx Lite just makes it all work.
Now launch dcomcnfg.exe on the client and open up the permissions to allow the user running RSLinx on the server permission to connect so that the call back functions work in the .IsSubscribed
method. (IF you don't want to get notification and just pool periodically, then you don't have to do this.)
Finally you can start working on your "client" application. If nothing works, i.e. you cannot create a group or add items on the remote OPC server, then you're getting stopped by permissions on the server machine. If everything works except the .IsSubscribed method then you're permissions are wrong on the client machine.
Monkey around with these until you get it to work. Contrary to my earlier thoughts, and a few posts as well, the Rockwell wrapper dll actually does work pretty well once you get the DCOM setting right. (My apologies to Rockwell for all the things I said late at night!)
- Bummers, possibilities
RSLinx does not use the OPC Foundation's wrapper dll. While this isn't really "bad" I thought that the idea was "interoperability everywhere" in the OPC world. A thought which comes to mind is to
take the OPC server code from the Intellution site and develop a more "vanilla" OPC server to act as a reflector to RSLinx. It could run locally on the machine with RSLinx acting as a client to RSLinx and a remote server to clients on other nodes. But that's way too much work for now, and I'm not sure how hard it would be to get the Intellution examples up to snuff for the
latest version of OPC.
It also occurs to me that the same technique could be used to create OPC servers for other programs which lack an OPC server. (Most notably Wonderware.)
