God help a man who's lost in the PLC world

[Steve Bailey]

How many people have to tell you that your backdoor approach is a lousy idea before you'll get the message that it's a lousy idea?

 

[Tark]

If you want someone to instruct you on how to reverse engineer AB’s communication protocol, forget it.

If you want to get process data to/from the PLC to a .NET application then what you do is purchase an OPC server for your PLC. Then you can use something like Local IO Client to enable your .NET application to talk to the OPC server.

OPC is OLE for Process Control.

One place you can purchase OPC servers is - http://www.softwaretoolbox.com

A place you can obtain Local IO Client is – http://industrialdotnet.com/

 

[jarbar1026]

Hey, Steve--what about my last two postings sound like I'm still intent on "backdooring" RSView?

==================================
I might start to dig into RSView with a little more optimism, then. You know, it's probably four parts fear (if my developer-boss is deathly afraid of bringing down the line too, then I--the new guy--should share that fear) and one part pride (I probably feel a little "too good" for VBA coding nowadays). Dumb, probably, I know.

If I could get the RSView runtime component (and probably an accompanying license file), which we should be licensed for, then perhaps I could code my own RSView-enabled listener app and leave the "real" RSView instance alone.
==================================

If RSView makes its COM libraries available to legitimately licensed users, what is the problem with my seeking to write an app that leverages them?

 

[Peter Nachtwey]

I think you guys are a little hard on jabar but I know you are just trying to help

Jabar, you should heed the warnings. The specifications can be found at odva.org. Also see search for Ron Gage's ABEL and CEL libraries. Also get Ethereal and Wincap. Then you will be armed and dangerous. It will still take a lot of time to re-invent the wheel so you should heed the warnings.

 

[PhilipW]

RSView32 is far more programmble than most people give it credit for. There are a number of levels at which it can be customised:

Level0: Normal graphical tools

Level1: Event Detector and Derived Tags to drive the native RSView32 Command Set

Level2: Use the built in VBA editor to introduce VB threads

Level3: Interact with other applications using the very comprehensive Object Model.

First up you need to get familiar with RSView32 and PLC's. They are the correct tools as everyone else has mentioned. We are rarely quite so unaminous on this forum...it is a sign.

Bookmark this page: Rockwell KnowledgeBase

Also this link on the: Object Model

 

[randylud]

The sound of a production facility suddenly going quite is almost deafening. I would take all the good advice you are getting and stay with conventional methods of working with PLCs and their communication packages.

 

[harryting]

..I work at a big food-manufacturing plant in the midwest. I've only been here a couple of months, so I don't necessarily want to give out my company's name. Nor do I see the need. I'm a .NET developer.
.

You are a HACKER! that's ok though.

Please don't take this the wrong way. If you are successful, you will be doing great harm to your facility.

I run into this problem more than once, that is, a programmer trying to do control. Because you don't understand RSView or PLC, you are trying what you think is the easier way, come up with a "roll-your-own" control/HMI/applet. A few years down the road, your little program will be impossible to troubleshoot and even harder to replace.

RSView, Wonderware, etc.. to you is a software for the dummie. Let me tell you, it's that way for a REASON.

 

[Peter Nachtwey]

I think his request is legit, I just don't think it is practial.

If Jabar puts anothers RSLinx on the network he will only be increasing traffic. A snooping device is passive and doesn't increase traffic and the resulting collisions or the need for level three switches.

SST makes a Profibus card that works in the snooping mode just to do what Jabar wants to do.

We have all those tools I listed above. We can snoop Ethernet packets. We use these tools to develope products. We had to invent the wheel by making our own CIP or Ethernet/IP analyzer.
We were the first or second company out side of Rockwell to make a Ethernet/IP certificed product. It just took 6 months to work it out. We can justify this effort because we make product that we sell over and over again. I don't think Jabar can justify the expense of doing what we do.

It would be easier and cheaper to buy the snooper.

 

[Sheldn]

I think what jarbar1026 vbmenu_register("postmenu_133195", true); is asking is how does he parse apart an IP packet from an AB PLC.... Some help (perhaps). AB uses a protocol called CIP which is embedded in the data part of an IP packet. This is a Rockwell protocol and is not (I think) an open / published standard. I do not know if you can get this level of information from the manufacturer with out paying alot for it.

What you are looking for is a driver to talk to the PLCs and get the data you need.

You may have some luck talking to Rockwell about their SDK Software Development Kit. It is the base software that all others (Intellution, Wonderware, Others) use to develop their device drivers. The software will allow you to write your own code to get data from PLCs through the RS Linx software.

I doubt you will be successful monitoring packets and digging into the data segment of the individual IP packets.

http://www.software.rockwell.com/download/comms/rslinx/rslinx%20product%20guide.htm

You also could look at the on-board messaging capabilities of the Ethernet modules. This may be good if you have 1-2 PLCs, however, set up and network traffic could be a problem if you have many PLCs.


<DIV class=smallfont>RSLinx SDK



RSLinx Software Development Kit (SDK)<SPAN style="FONT-FAMILY: Arial"> includes documentation and technical support for developing OPC or C-API clients to RSLinx. OPC clients are developed for data acquisition, while C-API clients are typically used for device configuration. A copy of RSLinx OEM is also supplied with RSLinx SDK.

 

[Peter Nachtwey]

AB uses a protocol called CIP which is embedded in the data part of an IP packet. This is a Rockwell protocol and is not (I think) an open / published standard.

CIP or Ethernet/IP is open.

I do not know if you can get this level of information from the manufacturer with out paying alot for it.

We paid $500 but I think it is free now.

You may have some luck talking to Rockwell about their SDK Software Development Kit. It is the base software that all others (Intellution, Wonderware, Others) use to develop their device drivers. The software will allow you to write your own code to get data from PLCs through the RS Linx software.

Read my post above.

 

[monkeyhead]

Hopefully the crotchety folks didn't scare you away, but we've got a process at work that the HMI was written in visual basic and does a lot of SQL interaction. They used a third party vendor's activeX module to read and write data from an AB ControlLogix PLC. Hard too believe, but I think there may just be another way to skin this cat!

If I remember tomorrow, I'll see if I can dig up the name of the ActiveX module for you and who sells it.

The one catch is that you'll have to have enough knowledge of the PLC program so you can know what data to read off the PLC.

The developer edition of RSView is ridiculously overpriced as are all of Rockwell Software's offerings.

 

[monkeyhead]

RSView is capable of doing what you want to do. It is the correct tool for the task you've described. What I can't understand is why you're more afraid of crashing the system by using the correct tool than crashing it through the use of some some backdoor method.

So aparanently you don't get it. Which makes it even more ironic that you're coming down so hard on this guy.

Packet sniffing would not effect the interaction between the PLC and RSView. It's like tuning your CB in to a conversation between two truckers. It doesn't effect their communication, but you heard all the data going between them.

 

[rsdoran]

So aparanently you don't get it. Which makes it even more ironic that you're coming down so hard on this guy.

Undoubtedly you do not get it, he already has RSView so why sniff etc when the data is already there?

Cost is not an issue because it has already been paid. Devolopment is not necessary because software is available that already does what is needed or can be easily adapted.

This would appear to be a no-brainer but I guess not.

 

[PhilipW]

The developer edition of RSView is ridiculously overpriced as are all of Rockwell Software's offerings

Confusing price and value as usual.

1. An RSI product manager once told me that the problem with the Automation Industry is that it grew up on a diet of software subsidised by hardware. When he would show automation guys RSSql for example, they would all throw their hands up in horror at the huge price...and yet when he showed it to the IT guys who were using it at the other end, many of them would look down their noses and say that "something that cheap could never work"!

2. The automation business is about 1/1000th the size of the PC market. Imagine if you had to pay $100,000 per Windows XP licence! And I suggest that when comparing RSI prices to other similar level vendors, Seimens, Scheider, Wonderware, Citect, Intellution, etc...then their prices are perfectly competitive. It's only the second-tier players who have to give their products away.

3. I guess for people like you the only valid price for any software is zero. If you cannot pick it up and drop it on your foot..it does not really exist and there is no damm good reason why you should pay for it eh?

4. It's ok though...Indians and Chinese are hot after your job and the price of software will plummet to zero anyhow....just don't come bleating on this forum when you have lost your job to three H1B visas though.

 

[monkeyhead]

Undoubtedly you do not get it, he already has RSView so why sniff etc when the data is already there?

I was referring to Steve's 'Backdoor' comment... There is nothing backdoor about packet sniffing and it was a logical idea for a software developer whose never been exposed to PLCs.

I love how this board is called "LIVE PLC Quesions and Answers", but anytime someone new comes around and asks a question, certain members decide to **** all over them and talk to them like their idiots unless they've got a bunch of PLC experience.