I am going to be automating a tank farm this fall and have a few questions. Right now we are in the early (hardly a twinkle in the eye) stages of this, just trying to get a head start, so I have minimal information, and this may sound kinda generic. We have around 10 stock holding tanks, all will have a stock fill valve, a water fill valve, a dp level sensor, an agitator and a pump. These are fed by two mixers that each have a mixer motor, pump out pump, dp level sensor, dump valve, and a water fill valve. There is also 5 water reuse tanks that have water make up valves, dp level sensors, and pump out pumps. No that that is out of the way. Most of the equiptment that we will be using is going to be exisiting and kinda old. I am wanting to know what the best way to connect this all together. I prefer to not run all new hard wire. Tanks are in the same building but not right next to each other and not real close to the main control panel. We will be using Allen Bradley controllers, not sure what one yet. I have read some articles comparing Devicenet and Ethernet/IP and am having some trouble figureing out what one would be better, or even if they would be the best.
this is kinda a mess of a post but thought I would throw it out there.
Thanks


(dp level sensor = differential pressure sensor 4-20 mA output)

From a personal stand point, I like Ethernet. But Devicenet has many advantages so it really depends on your situation. I have used both and had great success

But for your situation, if this tank farm is as big as I am picturing it, you are going to run out of length on Devicenet and it would be hard to layout. The big difference to remember about Devicenet and Ethernet/IP is the network layout. Devicenet has a main trunk line that is limited to about 1600 feet. Off of this trunk, your drops going to your network nodes can only be 20 feet. I'm thinking that you are going to end up wrapping your Devicenet cable around and around trying to hook it to everything.

Ethernet uses switches to go to the nodes so I'm thinking you could put a switch in the middle of some of your tanks and branch to them, then make a straight shot to your controls.

If you need a lot of specialty type I/O, you may want to give Devicenet a better look, right now Ethernet is pretty much limited to displays and hardwire type I/O

How big is this thing?

G'day,

As TWControls mentioned, watch your distances with DeviceNet, go to the Rockwell site and there should be a manual to help with the planning. I would probably go Devicenet, maybe because I am more comfortable with it, but you have a good variety of devices to put on it. Use care if you start looking at the flat trunkline cable, 2 off the 3 installs have given headaches. Not as noise immune as the sales people tell you. But with the 30+ other cable installations, I have only one that 'plays up', and that is because it is a badly installed job, not by me..

I would check out AB's PointIO and Wago's IO system, which allow for a variety of low IO counts. The other bonus is you could look at using DeviceLogix in the distributed IO, just simple logic in the IO which can be used if the processor 'crashed'. Also look into the E3Plus overloads, great item, the also have 4 inputs and 2 outputs available, as well as being an intelligent overload.

Cheers,
Trevor.

Are the pumps and agitator motor starters located in a motor control center? If so, I would consider placing the PLC in the same room and hardwiring the motor starters, use one Control Logix PLC with a couple of remote racks connected via devicenet, the instruments and valves would be hard wired to the remote racks, then use ethernet to an HMI located in the main control area.

I guess my solution is somewhat of a mix of new and old, but I prefer having hard wired insturments and valves, it's just too easy for someone to damage unprotected wiring, things get dropped on it, people step on it, etc...

I wish!

What I was thinking about was possibly putting a control box at each tank and hard wiring to the valves, level controls and starters. Then connecting that control box to all the others and the main control center. I think that there is probably a great way to do this, I just have never done it before.




An off the top of my head answer, 150+ inputs (maybe double that depending on how we get feed back from some of the valves), 150-250 outputs, 20-30 analog inputs, possibly some analog outputs, 1-2 HMIs. Just starting the planning of this whole project, still waiting for the project to be "real" as opposed to the higher ups dreaming, and asking me questions.

Attached is the DeviceNet planning and installation manual; it contains trunk/drop line length restrictions for all of the possible baud rates. Since you haven't selected a controller yet, if you choose Ethernet/IP, you will have to use ControLogix/CompactLogix. SLC/ PLC5 will only support peer-to-peer data transfer over Ethernet; no I/O control.[attachmentid=1987]

That is a good question! I just went through all of that when we are installing 170 freq. drives and I was kicking around how to control them. I did find out if you use AB SLC 5/05 ethernet it is not a true ethernet/ip and you are limited to 300' per hub but its the way of the future. And if you use devicenet their was a great more of a cost per drive to have that installed. So I ended up using Modbus, well it still is in the making, because the drives come standered with that option. I guess what I am trying to say is their are alot of options out their and you have to look at the whole picture.

Physically how big is it (foot print)?

I'd use Ethernet for long distances, RIO/Devicenet for relatively shorter (work area or machine). Devicenet is really nice to use if you are using smart devices with diagnostics like E3 overloads.

Ethernet is great because of its speed, scalability and widely available hardware. But, I've noticed with some devices that are listed as Ethernet I/P but aren't truely deterministic so you have to be careful.

If it was a rectangle it would be about 50' x 100'

Let me just play devil's advocate here.. What would be the reason not to use RIO for this?

My understanding is that RIO is essentially obsolete and has been replaced by the newer networks previously mentioned. I still some of the 1794 flex I/O in a couple of plants that have existing infrastructure, but I have taken quite a bit of crap about it.

Looks like a good application for Ethernet to me. I am still trying to visualize it but it looks like Devicenet would have problems with drop length and general layout since it its not in line. A central switch could be put anywhere convenient and there would not be any problem with cable lengths

RIO is very limited on variety of devices and the number of devices is dropping so this would not be the way to go on a new project.

If you are using RIO, there is still plenty of hardware available due to legacy user base and it being a proven/robust network.

The same cannot be said for Ethernet/IP. Due to the limitations of the Ethernet architecture, anything built opon it is not optimal for time critical data transfer. I understand they use software to monitor if your network is reliable, but you can't acheive true determinism of every packet with it.

I guess I've yet to be convinced for using ethernet other than for high end, or widely distributed, non-time-critical applications.

I would disagree with this for true Ethernet/IP devices. The problem I see most people running into is that they are using Ethernet devices and not Ethernet/IP devices.

A good example is a Standard Panelview which is Ethernet/IP compared to a Panelview Plus which is only an Ethernet device and not Ethernet/IP compliant. A Controllogix communication to a Standard Panelview over Ethernet in the proper way, using assembly tags with the Panelview in the Controllogix I/O configuration is very deterministic and reliable. Using a Panelview Plus or a Standard Panelview using the old Controller Address method over Ethernet or any other network for that matter is an accident waiting to happen.

I have achieved reliable control between true Ethernet/IP I/O devices with RPIs of 2 ms which I would say is a very good response time.

And I have also seen Ethernet devices that are not Ethernet/IP compliant stop communicating for 30 seconds.

The key is making sure your devices are Ethernet/IP Conformance Tested. The same goes for Devicenet. I had to go all the way the Thailand once to replace a device that was for Devicenet but not Devicenet Conformance Tested. The plane ticket cost alone was enough for me to realize that the cost savings for buying products that claim to be up to spec but have not been tested is not worth it.

I am not questioning the speed of Ethernet. It's hands down faster than RIO or even controlnet for that matter.

Say all of a sudden your network is flooded with traffic (faulty device or joe schmo plugs his laptop into your network), a request could be put in a long queue. Your device which you expect to respond in 2ms now responds in 8000ms... who knows how the equipment will act in a time-critical application. Ethernet nodes have to wait in this scenario, no matter how urgent your message is. Also, Ethernet/IP may reduce and detect collisions, but from what I've read and understood, they can't be eliminated based on how the Ethernet architecture inherantly is.

I should mention, that by no means do I consider myself an expert, I welcome someone to explain it to me how it is deterministic other than detecting that your network is unreliable.

Thanks. This is all great information, and keep it coming. Some of this stuff is new to me, so every bit helps.

Thats not quite how it works. A request will not be put into a long queue. A packet request may be lost but it will fire another one right behind it. The RPI detemines this. This is part of how they make Ethernet/IP deterministic.

No, joe schmo should not plug his laptop into the plant network but it will not bog it down. But think of it this way, should joe be hooking his laptop into a Devicenet network? The Office and Plant networks should be separate. But the only trouble I have encountered with doing this is actually Ethernet/IP devices bogging down office equipment.

Just checked a 1756-ENBT and since the last power cycle which was 12 days ago it has not lost a single packet. Also there has been zero collisions.

Also I don't believe Ethernet is faster than Controlnet. Have you ever transfered 100 megs/sec on an Ethernet network. It's probably much lower. With Controlnet the overhead is much lower and if you want to transfer 5.5 megs/sec it will. Ethernet won't.

I used to be diehard Devicenet. There is a paper on Etherent/IP that was not written from a sales point of view that I must have read 200 times before I tried Ethernet for I/O control for the 1st time. I will try to find it for you. It explains very well how Ethernet/IP is deterministic.

Now is Ethernet/IP more deterministic than Devicenet? According to the specs I would have to say no. But in real world applications, as long as the either network is installed correctly, I have never had any problems with them.

Another big mistake people make is going to the local office supply place and buying their cables and hubs. This will cause big problems. This is going in a plant, not an office. Used industrial switches and shielded Ethernet cable. Personally I use N-Tron switches and Beldin 7919A Ethernet Cable.

TW, is this the paper you are looking for. Has some good explainations of Ethernet IP.

No thats not the paper. The one I was looking for was a technical document explaining both Devicenet and Ethernet/IP. It wasn't weighted towards Devicenet or Ethernet/IP but was just a good explaination. It wasn't written by Rockwell.

But this document hits the highlights very well

This post may come a little late but how are you controlling the tank farm now? You mention valves and level sensors. These have to be wired to something? What you presently have may affect what you use for the future.

Has the concept of redundancy or the need for it been discussed? This would also affect what you choose.

Rather than devolve this into a DeviceNet vs ControlNet Vs Ethernet discussion why not look at what you need to accomlish and choose the format which gives you that for the least hassle.

Right now it is all controlled with mag starters, manual pushbutton stations and diaphragm level switches...all hard wired. The people in charge are still working on redundancy requirements. they are thinking about leaving all the hard wired stuff in place and adding another automated control system on top of it. There is still allot of planning left. There are some other issues with arc flash and the interrupting rating of about 86 breakers, including the mains that we are trying to sort out. Should be an interesting summer!

I to have been burnt by selecting a product for device net that was not ODVA approved.

BTW ODVA.org has a ton of info on Ethernet/IP including Ethernet EDS files.

I personally like the 1734-AENT for remote Ethernet I/O and have good success with it. If controllogix is a little pricey for you the compact logix ethernet processor is true ethernet/ip compliant.