RSLinx SDK

My IT dept. wants to collect information from our DH+ networks concerning production data. In my area, each machine is basically a cut to length operation. They want each PLC to set a bit when a cut is made and send a message to a central PC which will interface with the plant LAN. In my opinion, it's not the best strategy, but there's no convincing them. Anyway, they want to know if a custom application on the PC, which is connected to the LAN and to the 3 DH+ networks, can be programmed to do this through RSLinx. Do we need RSLinx SDK? Are there ways to do it without this $1900 software package? What do we actually need? The programmer we have assigned to this project is very, very good, and can write code in VB, C, C++, etc.

Thanks,
Paul C.

If he is VERY, VERY good, then maybe not. But the cost of his time should be weighed against the cost of the package. If I remember correctly, the C libraries are included with this so he would not have to reinvent the wheel so to speak. But he should be able to use OPC to accomplish what he wants.


David

We have had better luck using RSlinx Pro and then either a 'package' program to access the data, or write your own to access.

I'm thinking that you may get by using RSLinx OEM (cheaper).

We have tried using our own code to access SLC's and it just isn't as reliable as using linx.
We also go from the SLC's to ethernet rather than using DH+ or 485 networks.
A couple of programs we have used are XLReporter and DataPort WebDock. The latter puts the data directly into MS Access and has 'handshaking' capability.
LOL

We have RSLinx Gateway, but the IT dept. wants the data put into an antique database system accessible by what we call "Level 2". I believe it's UNIX based, and the terminals are everywhere already, so availability of the data is the issue. Getting the stuff through RSLinx into this older system will require some custom programming, my question is really do we need RSLinx SDK, or can we do without it? I am leaning toward buying it, but I hate to fork over cash to A/B any more than we already have to.

I do not believe that you need the SDK for this. Getting the data from Linx Gateway should be easy using DDE or OPC. Passing the data to your DB might be harder but it may be possible to use ODBC. I would use a small VB application or similar as an interface between the two.

I have a thought but not sure about the details. It is fairly simple to put data in an Excel file on a PC thru a network....could the programmer just extract the data from an Excel file for whatever use the IT dept wants?

Because there's a non-Windows target, and it's DH+, you're going to need the RSLinx SDK if you are going to use A-B DH+ cards.

If this was all Ethernet, or if it was all serial, or if there was a Windows or ODBC target, it would be a much easier, less-expensive proposition using ordinary RSLinx and OPC, or one of the available third party drivers like Kepware. It's not.

If you have the option to use SST or Data-Link DH+ cards, then your development kits come from them and you can have an all-custom setup with no Rockwell content. It's sometimes instructive to shell out your money to smaller companies.

I understand that RSI will be coming out with a Java-based platform-independent "RSLinx Services" product later this year. It probably won't be applicable to this particular product, but if you have a lot of non-Windows applications it will be good to know about.

Thanks for all the comments...I'll share what I've learned from you guys with the people in charge and let them decide what to do next...

I've setup many systems over the last 20 years using "concentrator" PLCs to collect production counts, time studies (blocked/starved), and equipment monitoring (faults, etc) from other PLCs on the production line. I then write a Windows application to collect the data out of the concentrator and flat file it or stuff it into a Relational DB using SQL. My favorite method of communicating with the concentrator is a ActiveX control from Ingear and then I can code it in the language of choice (VB, C/C++, Delphi, etc.) at the time.

This architecture works very well and is very common in the automotive plants that I've worked in.

I hope that helps.