SLC 5/05 to MIcrologix 1100 Comms

[Colin Carpenter 10]

Hi, I have a project where I'm programming a Micrologix 1100 which needs to communicate a small amount of data backwards and forwards between itself and an already installed SLC 5/05 CPU. Speed is not really an issue on this job, so update times measured in whole seconds is not an issue. Both PLCs have ethernet ports, but the client is not happy about using the ethernet ports for this "mission critical" data, as the corporate and SCADA systems are already using the physical hard wiring of the ethernet network, and occasionally there are problems with this. Based on experience, please could anyone advise on the best method of achieving short distance secure comms between the two PLCs. Many thanks, Colin

[BobLfoot 302]

If you can't use properly watchdogged ethernet communications {can't believe I am even considering ethernet, I've come a long way in my understanding and so has the technology - but I digress and wander} then ControlNet or DeviceNet would be obvious choices given these PLCs.

[paulengr 44]

Can't be done with a Micrologix. Remember...they hobble these things to avoid letting you do anything like that. So unless you are using serial ports, you can forget about DeviceNet or Controlnet for a Micrologix PLC. To say nothing of the outrageous pricing for SLC's, and I'm not even sure you can get a Controlnet card for one. So if you have the spare serial ports and don't mind losing them, you could cable them both together with RS-232. If they are physically separated by a sizable distance, then you can put RS-485 converter cards on either end and use that. You can buy these relatively cheaply from www.bb-elec.com. You can also buy some decent RS-232 radio modems from Mouser.com. Look for the Aerocomm modems at 900 MHz as these are slow but easily punch through almost any kind of industrial radio clutter and metal shielding with a little planning. OK, so what we have here is that we want to exchange data between two PLC's. We want to insure that if the ports between them are shared, we don't get interference from say an IT guy getting a brilliant idea, not telling anyone, and just reprogramming your switch in the middle of the day. Or that someone goes and starts running some kind of monster accounting program or even does a giant ping-scan on the network or somehow blasts out broadcast packets and simply kills your PLC's, correct? Well, what you need to do is first buy your own switches. Stay away from anything Cisco. This stops the IT guys dead in their tracks because if it isn't Cisco, they don't understand it. Also, Cisco switches have a tendency to lock out ports somewhat arbitrarily if they detect any electrical noise problems on their ports, and after a power up, they can take anywhere between 10 and 30 minutes to suddenly decide to start allowing traffic again. They are in short, anything but industrial rated. First off, buy your own switches. Get away from the ones IT put in. You need to put your two PLC's on their own "local LAN". This means at a minimum, buying a dumb (unmanaged) switch. This prevents anyone from getting a "reprogramming" hair. It avoids the 10-30 minute startup delay from Cisco switches. It doesn't avoid cross-traffic issues, but we're getting there. When you write your MSG blocks, do a READ at both ends. And watch the error/timeout signal. If the packet errors out, then you should have defined a "fail safe" function in your program to go to whenever you lose communication. In fact, I often flash lights or set off alarms or something letting everyone know that communication is down ASAP. Now if you want to avoid the cross-traffic issue, then you need a better switch. You can get a Cisco switch to do it but it has other problems. Better would be a true industrial switch such as one from Hirschmann, N-Tron, or Sixnet. This needs to be a managed switch. I do NOT recommend the Allen Bradley rebranded Cisco switches. So far they don't have a track record in my mind to prove that they've overcome the problems with standard Cisco switches. And Cisco's IOS is full of all kinds of proprietary nonpublished stuff and bugs with every version. Set up QoS. This means that you will program packets eminating FROM your two PLC ports to take priority over incoming packets from the IT LAN. I usually set it to 8:1 (8 PLC packets for every IT packet) or some such, guaranteeing that you will push your traffic through at all times. Turn on any "broadcast storm" protections and such that you have. Also figure out the maximum packet data rate for your PLC's and throttle the packet rates to those limits in the switch. If you don't know, 500-1000 packets per second is usually a good guess. AB Drives are very limited and can only handle something like 200-500 packets per second. The result is that no matter what IT does, you have control over your switch. Your PLC's are not dependent on whatever the rest of the network is doing. And no matter how much garbage comes in from the IT network, your inter-PLC traffic takes priority and will pass through unscathed. In the event that there is a physical communication problem (wire broke), the PLC at each end does it's fail safe and alarming actions to let someone know that communication is down. Be forewarned about Panelview Plus's. They will lock up on you in short order with intermittent communication problems on Ethernet. They are anything but robust in this regard. They also don't really meet their temperature specs, are prone to vibration issues, grounding issues (DH+/RIO interface cards are notorious for grounding problems on these), power issues, and pretty much anything else that I would consider "typical plant conditions".

[Ken Roach 194]

Paul, can you provide some background on this assertion ? Is this something you have observed in the field, or is this something that is documented as a function of the Cisco IOS and could be detected in the switch logs or SNMP objects ?

[Colin Carpenter 10]

Thanks for the replies, and it seems that there are issues to be wary of whenever connecting to ethernet networks used by others. I'm currently investigating the methods of connecting the Micrologix RS232 port to the 5/05 port using DF1 protocol, but would prefer to use the inbuilt DH485 capability of the MIcrologix as it would be more resistant to noise and distance. Just means that I have to find a way of getting the 5/05 to talk DH485 using an external adaptor which can plug into its serial port or by using a dedicated card in one of the slots.

[paulengr 44]

Arbitrary port lockup is a well documented proprietary feature that is specific to Cisco switches. Remember, this is a feature, not a "bug". You cannot turn it off. They will just arbitrarily shut down parts of your network because of some sort of problem that occurred on the plant floor, even someone trying to plug in a connector and having some difficulty with doing this, or fiddling with a cable trying to get a damaged cable going. It doesn't just shut it off for a while and then come back either. Once you trigger this feature, the port is "dead" until restored through administrative access. Here is a reference document straight from Cisco: http://www.cisco.com/en/US/tech/tk389/tk21...080093dcb.shtml Read the following paragraph taken directly from the above Cisco web site very carefully: "At first, this feature was implemented to handle special collision situations where the switch detected excessive or late collisions on a port. Excessive collisions occur when a frame is dropped because of encountering 16 collisions in a row. Late collisions occur after every device on the wire should have recognized that the wire was in use. These types of errors could be caused by a cable that is out of specification (too long, wrong type, defective), a bad network interface card (NIC) card (with physical problems, or driver problems), or a port duplex misconfiguration. This last cause is common because of failures to negotiate the speed and duplex properly between two directly connected devices (for example, a NIC card connected to a switch). Only half-duplex connections should ever have collisions in a LAN; due to the Carrier-Sense Multi-Access (CSMA) nature of Ethernet, collisions are normal for half-duplex, as long as they do not exceed a small percentage of traffic." Conclusion: Ethernet port or cabling faults cause a Cisco switch to totally lock out a port. It cannot be restored unless you have administrative access to the switch to reset the port. Now I'm all for giving out access to the troubleshooting crew and training them in using it, except that there's no way to limit access to some features without giving access to others. Never mind the fact that IT is not about to give out the keys to the kingdom on this one. This is a great troubleshooting feature of course in an office environment where damaged cabling almost never occurs except when Fred slams a cable in the door. It's a much different story in an operating plant floor environment. So even when you fix the bad cable, the switch is still locked up. Ethernet cannot be diagnosed with an oscilloscope or some such. So all you know is that you fixed what is apparently a bad cable and nothing works. So you keep searching for the problem, and searching, and searching. OR, you get into the "Windows attitude" and just arbitrarily reset locked up ports all the time with no thought behind tracking down why they are occurring. No matter how hard Allen Bradley pushes them, Cisco switches simply have no place in industrial networking. They are not designed for it. Even the vaunted 2955's have this "feature". Since the Stratos switches are also Cisco Catalyst based, as far as I know, they have this cool "feature" too. Slow startup is field observation. It's a switch. It is not a server. It should not take longer than 30 seconds or so to power up. I can't recall how many troubleshooting calls I've received after a plant power outage that end up being a switch. In the middle of trying to troubleshoot it, suddenly everything goes back to working "on it's own". More than once I've narrowed it down to the switch because local comms work, and other parts of the operation that aren't dependent on Cisco work. Not sure why this is or how to fix it, but come on...it's a switch.

[Colin Carpenter 10]

Just an update to say that I've decided to use a 1761-NET-AIC+ connected to the serial port on the 5/05 by cable 1747-CP3 or 1761CBLAC00, then to use a 1763-NC01 cable to connect the Micrologix 1100 directly into the DH485 of the AIC+, with the cable being split, connected to terminals, then using Belden RS485 spec cable between the panels. Think it should do the job.