Visual Basic for RS Linx

[rdowning 0]

First off I am new at Visual Basic. My question is how do i get visual basic to communicate through rslinx to reach my PLC network. Any help would be appreciated greatly thankyou

[Bob O 8]

Not exactly what you asked for but have a look at this on another forum. It may or may not help with what you want. http://www.plctalk.n...ead.php?t=51758 Edited 2 Aug 2010 by Bob O

[Chris Elston 79]

I would assume that you would need to use DF1. I don't think there are any other API's unless you purchase a third party ACTIVE-X control. Here is the DF1 manual

[paulengr 44]

You didn't specify "which one". RS-Linx Classic is "real" RS-Linx. RS-Linx "Enterprise" is actually a private labelled version of someone else's. I'm told it's actually Kepware. If you are trying to go "through" RS-Linx, be aware that you can't use the unlicensed ("Lite") version. You MUST have either the OEM or gateway (or professional or whatever they call it these days) version. If not, then you've got to either learn how to use Ethernet/IP (for newer processors) or PCCC (an Ethernet variant of PCCC), or DF-1 and write your own interfaces. It's not hard but it takes a lot of time and research, and apparently selling interface code is a money maker so nobody makes it easy. If you have the license, then you can interface through one of several interfaces: OPC. There are client DLL's for this on the Linx CD. The usual DLL that you are supplied with for a client is the reference one that the OPC Foundation publishes. This is the recommended one. Linx Enterprise is only available with this interface. The "C" interface. This is deprecated and I'm not even sure current versions support it. AB was stingy about selling the API/DLL when it was available. DDE. Cheap, easy, and it "works", well, sort of, most of the time. It's OK for noncritical things like Excel spreadsheets but don't rely on it. Just follow the Excel documentation that comes with RS-Linx, and then translate over into VB land. FTA. Allen Bradley has always had their own super secret "don't need licenses" backdoor driver. They of course publish nothing about it. Most suspicions are that it is a variation on the "C" interface. RS-View 32. OK, this isn't an "interface" as such. RS-View 32's internal programming language is VBA, just like Microsoft Office. You can link to Active-X objects (using View 32 as the container), and RS-View 32 can communicate using all the various Active-X method type techniques. The same technique works pretty much with ANY HMI or Historian out there...just use them as "containers" or "interfaces". This is the way I usually do it. If you do go the OPC route and you haven't already paid for a license, I suggest not bothering with RS-Linx for two reasons. Licenses for the major competitors (Kepware and Matrikon) are less expensive than RS-Linx, and their OPC servers have much better scalability (can process many more points and downstream clients than RS-Linx). OPC is "commodity" software...it's just a "driver". Any OPC server that can communicate with the PLC of your choice meets the criteria. Some just have better pricing, scalability, support or features. Kepware and Matrikon already support the new OPC-UA standard which escapes "COM/DCOM" hell (if you are using dotNET), while RS-Linx doesn't support it yet. The one reason I can see using RS-Linx other than minimizing the number of drivers on a particular PC is that it supports the special "alarm" instructions built into ControlLogix, although they are memory pigs. The documentation with RS-Linx for OPC by the way is very obtuse. If you can support the "WS Security" model and use SOAP, then you can auto-generate the HTTP-based interfaces to an OPC-UA server (which is one reason it is easier to work with). If you are using the older OPC-DA, here is some help: http://www.gefanucautomation.com/opchub/opc_ocx.asp GE Fanuc gave away their ActiveX interface after buying up Intellution. It's fairly easy to work with and follows the traditional "C" OPC Foundation reference DLL. http://www.centurytechs.com/ OPCSI. This one includes full source code and basically replaces the OPC API with one of it's own, for better or worse. You can of course simply strip out the part you want from the source if you were so inclined and get rid of the new "front end". Be aware that OPC has two different "access modes". The first mode is used for both reading and writing data (although most commonly just for writing). Each call reads/writes exactly one tag. It is very simple but also has lots of overhead since you start up/tear down on EVERY call. The more efficient interface has you set up a set of tags (actually, groups of tags) with a set of parameters (how often to read, whether to update periodically or only when data changes). Then the OPC Server will automatically call your program whenever new data arrives. This is very much in line with the standard "reactor" style programming that most user-interface based code uses these days but you do have to put in some sort of "watchdog" timer just in case the server crashes and leaves your application hanging. If the OPC server itself is written very efficiently, it can even use a similar interface in Ethernet/IP so that even the PLC isn't bogged down with communication. Edited 3 Aug 2010 by paulengr

[rdowning 0]

Thankyou for the information Gentleman