networking

[pooch70]

I see a lot of people asking where they can learn about PLC programming, and what I am wondering is where I can learn more about networking and different types. The only one I use is DH+ and would like to know the differences in the rest and whether I should be using something different

[gravitar]

Well first of all, see what A-B has to say here: http://www.ab.com/networks/ DH+ is an older technology that is still supported but not emphasized by A-B any more. For the last several years the push has been toward Devicenet, ControlNet, and (more recently) Ethernet. Each has its own strengths and weaknesses, and certain applications favor one over the others. The link above should give you a pretty good starting point toward figuring out where to use which network.

[TimWilborne]

One thing to add to gravitar's comments is that while Devicenet, Controlnet and Ethernet/IP are are different on the physical layer, they all use the CIP protocol to communicate. If you learn one of these, the others will come very easy. And it is very easy to communicate from device to device in a bridged enviroment across these networks

[Chris Elston]

See what other members of MrPLC are using: http://www.mrplc.com/cgi-bin/vote/vcenter....=show&topic=bus

[Guest Guest_Monster]

There's a lot of hoopla being made about Ethernet I/P, which concerns me. I like DeviceNet for a general purpose network, because to me it seems the most supported network as far as different vendors go. I have used Ethernet I/P for some limited applications, such as vision systems, barcode scanners, and HMI's. I never have nor every will use Ethernet I/P for remote I/O, because it is not a determinist network. (that's another conversation in its self). I am starting to second guess myself on using ethernet HMI's. I have had some erratic behavior lately that involved ethernet PanelViews.

[TimWilborne]

What type of erratic problems have you had with the Ethernet Panelview. Do you use a Controller Address or Assembly tag scheme

[Wordman]

Controlnet is deterministic, and much faster than RIO. EtherNet/IP was first introduced as "Controlnet over ethernet", ie: tcp/ip encapsulation of data packages. Delivery of your data is safeguarded using time-deterministic messaging.

[TConnolly]

That all depends on what you mean by deterministic. Ethernet/IP configured properly with a managed industrial switch can be deterministic. It all depends on what you do. Tell us, what do you mean by deterministic? I ask this because Ethernet/IP does in fact meet the definitions of determinsm for most people and applications. The reason I stay away from Ethernet/IP for IO is political, not becasue of capabilities. The last thing I want is some knot-head wannabe from IT coming along, spotting a CAT-5 cord or switch, and thinking he can screw with the system or plug something in. I already have enough headaches with the Win XP HMI stations.

[TimWilborne]

I agree with Alaric. Tie all the ITs up, throw all there computers under them and burn them both. But seriously I feel Ethernet can be deterministic if set up properly. We use it and have never had a problem. But I do feel you should set up you tags in the Panelviews as Assembly objects and not controller address. Then the Plc controls the messaging and knows when the Panelview is not communicating. Edited October 27, 2005 by TWControls

[Monster]

Ethernet IP Does not have True Determinism. It sends a packet and hopes it gets to it destination in a timely manner . It depends on pure speed to work effectively. It doesn't have a repeatable scan time or heartbeat. Sometimes the information wont even arrive at all. I have been using L5K since its introduction, and do like what it brings to the table. However that is also about the timeline when we started bringing Ethernet PanelViews onto the plant floor. I've taken every measure I can to assure proper network health. I've segmented the network as much as possible and even installed a Cisco "layer 3 aware" switch to bridge over to the IT network for data collection on network drives. But... For a couple of years now I have the occasional ghost bit that an Ethernet PanelView, or PanelView Plus will turn on and then not turn off. I have have talked to A/B's tech staff and all I have learned is that the momentary push buttons in a Panelview project basically latch a bit on, and then after the selected dwell for the button is then unlatched. Which does explain what's happening, the unlatch from the Panelview gets lost. There must be over 30 Ethernet PanelViews on the floor, and I only see this once every 2 or 3 months (or maybe longer) be it can sure make you scatch your head for a little bit when all of the sudden you have a machine starts doing odd things for no reason.

[TimWilborne]

Monster, are you still using the old Controller Address scheme or are the Panelviews actual I/O in your Controllogix I/O configuration. The Panelview Plus does not yet support this setup. And I will agree that this is not a good setup and is why we have not yet gone to the Panelview Plus. But if you are using Standard Panelview and their Assembly objects, its just as deterministic as Devicenet and Controlnet. They have RPI's and heartbeats just as other modules. Just did a check on the time it takes for the processor to discover the Panelview is faulted and the maximum was 202 ms. Which with a 100ms RPI, means it gave it just enough time to receive one, request the next, 100ms for one to be received when it was offline, and 2 ms to think about it. I would say that was pretty fast. How are your tags setup in your Panelview? Do you have code in your Controllogix program to realize the Panelview is offline? If you are still using Controller Address(specifying the actual tag in the Controllogix) get rid of it, your setup is an accident waiting to happen!!!

[Monster]

I didn't realize that you could add a PanelView to your Controllogix I/O configuration. That would make a big difference. Sometimes info like this is hard to come up with. I've spoken directly to my A/B distributor and A/B tech support and no one has mentioned that this was now an option. I will have to check this out. As far as the question that "Pooch70" posted, I still like DeviceNet for a general purpose network. Correct me if I'm wrong, but for multi-vendor integration I use DeviceNet. For example I have had to integrate about 4 different brands of robot controllers. Everytime I ask the engineers to add a DeviceNet interface, and each time I get a ethernet card. All of which have been usless to me. These have ranged from Modbus IP to generic ethernet ascii. Nothing I would consider deterministic. Even if they had been ethernet IP, it would have required a CIP message command? This is where I would like to see a DeviceNet network. Do you agree???

[TimWilborne]

I like to use Devicenet for device level components. Devicenet usually has many more switch level features such as short and open circuits, dirty photoeyes etc. As far as HMIs, robots and equipment like that I would perfer ethernet. You are usually wanting larger volumes of information in these instances. What you need to look for in these devices is that they support I/O messaging(can't remember the proper term, but i think its Class 1 Messaging). Any device that supports this can be put into the I/O configuration of Controllogix. Most of these devices will have one assembly instance that groups more critical information together. This is the the assembly you would put into your I/O configuration. Other assemblies will have information that is not time critical. Look at the generic ethernet module and you will understand what I mean by Assembly instance. This less critical information is what you would use you CIP messaging for. This is the same thing you would use devicenets Explicit messaging for. Devicenet and Ethernet/IP use the same CIP messages. As long as a device is truely Ethernet/IP it will work regardless of the manufacturer. If you look at the specs on Devicenet product, many only support explicit messaging, which means you can't poll them either. This is the problem with many products that are supposively Ethernet/IP. Which by the way, the Panelview Plus is not Ethernet/IP compatible. Go the the ODVAs web site if you don't believe me. I have been burnt serveral times on Devicenet products that were supposively to spec. This is what is happening to Ethernet/IP. The hardware is so cheap that anyone can pop an ethernet chip into there setup and say it supports Ethernet. For both Devicenet and Ethernet/IP, make sure all products you use are conformance test. Yes they cost more, but you will have less headaches with them

[TimWilborne]

Just thought about it, if you use and Assembly scheme in the Standard Panelview and use mutiply assemblies, you need to set the size of the output assembly for the I/O configuration to 111. It defaults to 112 but if you use Assembly 6 for your output assembly this will write 2#1010_0111_1010_0111 to the first word of assembly 8. Messages to other assemblies can be 112. Going to call Rockwell one day to discuss this problem, but waiting till a day I'm feeling very patient