To Ken Roach and the AB Aces

I'm not being a smart-butt, you guys really are

I'm working on a pretty massive SCADA project with Rockwell products, including plantmetrics. Among the equipment in this proposal are several Panelview 1250 Plus, a CompactLogix PLC, and lots of ethernet-based point-IO.

I've taken issue in the past with AB based on price and the whole support-contract thing. But since support contracts are becoming an industry norm, I've let that one go, and in this case, I think the prices are pretty reasonable (ok, the PVs are kind of salty, but I'll live with it).

Anyway, what convinced me to pursue the AB route was was the quality of the product. I've used AB in the past, and I've always maintained they have a good, if pricey, product, and since I REALLY want this project to go without a hitch, I decided on their stuff.

But I have to admit, the stuff being said in JDBrandt's post is - concerning me. If it was just comments about AB in general, I wouldn't lose any sleep, but when this many luminaries piles onto a particular combination of hard- and soft-ware, one my vendors are trying to steer me into, now I'm getting worried.

I guess what I'm asking you, the experts, is, with emotional outbursts aside, do I have anything to worry about buying Panelview Plus hardware and RSView machine edition to set it up? I'm looking to communicate with a single PLC from multiple PVs, via ethernet. I'm going to use RSLinx OEM edition to get data out of the plc.

Seems simple, but is it simple enough?

Thanks for anything you have to say on the subject.

TM

I didn't weigh in on the other discussion, and won't comment about it.

I have used View SE and ME for several applications to date, starting with version 2.5, then 3, and now 3.1. I really haven't had any actual problems with any of them.

The most difficult thing, especially (and unfortunately) with our typical 'Do All Development/Editing PC's and Laptops' is to keep the versions straight.

I often have to switch back and forth from 3.0 to 3.1, so I keep the install images for all required software on my laptop all the time. PLC Programming Software versions don't matter a whole lot, but View Studio, RSLinx, Linx Enterprise, and FactoryTalk Platform are extremely important to keep in sync.

I'd suggest before installing any of the Dev software, you uninstall all (or any parts) of the above software, and then install:

FactoryTalk Platform (From the Studio CD/DVD)
RSLinx (From the Studio CD/DVD)
and then View Studio (Complete, from Studio CD/DVD... It should install Linx Enterprise if needed (ME or 3.1))

I use only Win 2000 Professional currently on my dev laptops, and have had no trouble keeping all that running just fine.

ME (PV Plus), and Linx Enterprise are incredibly good at dealing with multiple node networks.

Studio / Linx / Linx Enterprise are fairly complicated at first, but not too bad as long as they get installed properly.

Good luck Timothy

I haven't done a system quite like yours in scope, but we did have problems with one O/I talking to four PLCs - one SLC and three MicroLogix. It was difficult to get the communciatoins working properly, but new firmware and another update on the programming software eventually fixed that. We still have a problem trying to communicate from our laptop using RSLinx and RSLogix with the PLCs through an AIC+ when the Panelview Plus is connected to the network. As soon as we unplug the Panelview Plus the link to the PLCs from the laptop is OK.

Make your PO contingent on approval of an in office test. I suggest you have your distributor bring in a CompactLogix, a laptop with the SCADA software, and at least three PanelView Plus units, and set up the network in your office. If the Panelviews didn't come out of the box with the latest firmware, make them burn the new firmware in your presence. Make them configure in your presence a different screen on each PanelView. Have them do the actual comm link configuration while you watch. Use PLC time as one of the registers being read by each Panelview, and see what the latency in the network.

After watching them go through this, make up your own mind as to whether or not you want to use this system. If they aren't willing to do this test, you also have an answer to your question.

If you're going to be running RSView, stick with a time-tested operating system like Win2000. AT LEAST make sure you talk with Rockwell about which operating systems (including service packs!) are supported. If they say RSView isn't ready for the operating system of your choice, SWITCH!

AK

?

?

If your going CompactLogix and PV+ or Versa View then be sure you have the updated patch for the L32e if that is the PLC! Lots of new stuff coming out for CompactLogix, and unfortunately the programmers at Rockwell are just catching up! Good thing though, it is a VERY robust system, and once you get all the poop on the software it should be a no brainer!

Good luck on your project, and don't forget to check the knowledge base on the Rockwell web site.
Just say NO to SP2!

bitmore

I think that Tom's idea of having AB making a test setup while you watch is excellent. You could decide to visit AB rather than the other way around (and get a free lunch maybe).

One question:
Is the Ethernet point i/o going to hang on the same network as the network used for the PVs and Plantmetrics ?
In other words, everything has to pass thru the same Ethernet port on that CompactLogix.

I would definitely have a test setup of the entire system, or something approaching the entire system in size.

Even if the test goes well, I would not be comfortable with mixing i/o network and higher level network (HMI, data logging, programming).
You are really locked with only one port.

If the system is so complex, why not use a ControlLogix with two separate network cards ? One for i/o and the other for PV and Plantmetrics. I wouldnt be so penny pinching if I were you.

And while we are at it, this would be the first post that I have seen with someone really using Ethernet at the i/o level (*). It would not be my choice. You could consider to use Controlnet or Devicenet for the i/o.
*: Right, I know that everybody says Ethernet is the future, even for i/o. But they also said that PC based automation was the next thing, for sure.

Jesper has just beaten me to it. I think you may be trying to put too much through one Compactlogix Ethernet port.

Each PVPlus will be generating traffic, the RSLinx OEM will have it's own set of OPC tags, the I/O will be hammering away, and from time to time I'll guess you might want to online program it?

With all these different drivers trying to attach to it the CompactLogix comms process is going to have a hard time optimising all the packets which won't help either.

I haven't seen a frames/sec spec for the 1769-L32E port, but I would be pleasantly surprised if it was as high as the 1756-ENBT. In the 1756 processors the backplane comms has it's own processor that exchanges data with the logic processor via dual port memory, whereas the 1769 processor comms is handled as a task within the logic processor. Comms throughput is likely to be lower.

Unlike Jesper, I have no problem with the Point I/O on Ethernet, I seen it in action and it works fine, but I would still want the network with it's own seperate network path to the processor.

If as you suggest it is really important that the system works well first time, I would get your local AB shop to be going over this proposed config very carefully.

Thanks!

Thanks for the info guys

I'm going to bring this up with my Rockwell rep shortly and see what he has to say about it.

TM

Originally posted by JesperMP And while we are at it, this would be the first post that I have seen with someone really using Ethernet at the i/o level (*). It would not be my choice. You could consider to use Controlnet or Devicenet for the i/o.

Click to expand...

I'm about to commission my third system using ethernet I/O. About a half-dozen flex adapters, remote 1756 chassis and a remote CLX, plus RSView and 2 InView displays (and programming). It's fast and hasn't given any problems. It can all be configured without any requirement for RSNetworx or tedious mapping to UDT's.

Look at the Logix 5000 Design Considerations manual:
Rockwell does not reccomend ethernet based I/O as a BEST choice.
It is easy to do compare to the ControNet, but is not that reliable and easy to troubleshoot. For critical highspeed I/O I would definately go with ControlNet.

In any case never put ethernet I/O on the company (information) network - it will flood it with UDP broadcast.

Contr_Conn said:

In any case never put ethernet I/O on the company (information) network - it will flood it with UDP broadcast.

Click to expand...

Not if you use the right hardware. You need a switch with IGMP snooping capability to contain the multicast messages. We're using Hirschman "MICE".

What sort of problems are more difficult to troubleshoot on an ethernet system vs ControlNet or DeviceNet?

My apologies to Timothy, as I didnt mean to hijack his thread, but I think I need to elaborate on why Ethernet is not my 1st choice.

I would expect Ethernet i/o to work , it is not that what is my worry.

My main worries are the following:

1. Generally cost is higher than other distributed i/o systems.

2. The architecture can be set up in three ways (to put it short), each with its own problem:
- One central switch bank from where Ethernet lines is distributed out. The problem is that this makes the cabling extremely costly and cumbersome. And if the central switch goes, everything goes.
- A series of switches linked together. Seems like the most reasonable compromise, but if one switch or connection fails, then everything downstream is disconnected.
- A redundant Ethernet ring. The most reliable solution, but also the most expensive.

3. RJ45. Right - there are a number of alternatives, but none is standardised.

4. You will have to fight off the IT department. If they get the wind of an Ethernet system in their area, they will try to get control of it.

I would consider Ethernet i/o for very large systems - 10000+ i/o.

Why use Ethernet? YUCK!!! IT will, try to hijack it for sure. Use a token ring based peer to peer and Device Net or something similar for I/O/ and IT will run the other way. Quite frankly, from my experience token ring works much better than Ethernet.

Ethernet is fine for a SCADA system to pull information. About the only place I would use it.

I worry about AB with the problems discussed on this site, and the number of versions of software, firmware etc. Why are they not backwards compatible like most others?

My preference is still Omron. All the latest versions of CX-Programmer will work with anything from past versions. NO ISSUES!!! I have only once had to update firmware and that was only to correct a problem with the low battery flag, would you believe.

Schneider are coming to see me shortly with the latest guff on the TSX premium and PL7 software. Will wait and see if things have improved there.