Why is Rockwell putting VFD's on PLC network?

lunenburger

Member
Join Date
Jul 2008
Location
Summerside
Posts
207
Does anyone know why Rockwell has changed the way they do their ethernet configuration?
For years we used 2 ENBT modules, one to connect to our plantwide PLC network. And one to connect all the VFD's and device level I/O.
Now Rockwell is suggesting to put a ring inside the panel with a 1783-ETAP connecting all the drives, PLC, PanelView, and connection to our PLC network.
(see pic)
The issue I see with this is that I can now ping the VFD's and servo controller from our programming computer which makes me nervous....
As far as I can see there is no way to partition an ETAP, and the Rockwell rep doing the installation doesn't recommend using an ENBT????

41249.jpg
 
Was that from your rep?

Yes keep your field IO and VFDs on it's own IO network, I am moving toward using DLR on all IO networks. I my opinion DLR doesn't really change anything that I would typically do. Only gives me additional fault tolerance.

If you have a SCADA network and an additional PLC comms network I would keep them separate. But if you only have a separate SCADA network and IO network, PLC comms need to go somewhere.
 
On larger systems here, since we are moving (against my will) to Ethernet I/P for everything, I have been specifying 3 separate networks. Supervisory, Drives, and I/O. Even small lines get two, just so that the IT department cannot touch any actual line equipment.

That sounds more like a cost-saving suggestion from your representative, and not good practice.
 
My guess is that this is a marketing slide showing what is possible, not necessarily a recommendation.

In my experience, having at least a plant network and a local cell/IO network is almost always a good idea. Most of the time, even with large architectures and multiple layers of PLC, there is an upper system that needs to talk to the PLC, but has no business talking to its subordinates.

I've only worked on two systems where we broke that best practice. Both of them had good technical reasons why doing something different was necessary, and both of them have been huge headaches. We are now having to do some very creative networking (like reprogramming wireless clients on the fly) to cover up other flaws/limitations in each system.
 
rdrast, why do you split drives and I/O ?
Just curious.
As I see it, drives are just another kind of I/O.

Carryover from running everything on ControlNet. We usually had to split drives and IO there to keep the NUT's reasonable.

So, going to EtherNet/IP, we are keeping the same approach, even though it isn't as necessary. And, if by some horrible accident, IT gets access to the drives/IO, we can switch back to the original architecture again.
 
So, I have a question on that note. I still want to be able to access the drives and I/O from the plant network as that is where our PCs reside. But I do want to isolate them to minimize traffic on the network and also limit access to them from non-control (IT, production, management) people. What is a best practice method to achieve that.
 
So, I have a question on that note. I still want to be able to access the drives and I/O from the plant network as that is where our PCs reside. But I do want to isolate them to minimize traffic on the network and also limit access to them from non-control (IT, production, management) people. What is a best practice method to achieve that.

You want to look into creating subnets, and using the subnet mask to open/close access. Your production computers would use a subnet mask to isolate them to what they need access to. While your engineering computers would have a subnet mask that allowed access to it all.

Say 255.255.255.248 vs 255.255.255.0
 
So, I have a question on that note. I still want to be able to access the drives and I/O from the plant network as that is where our PCs reside. But I do want to isolate them to minimize traffic on the network and also limit access to them from non-control (IT, production, management) people. What is a best practice method to achieve that.

Using subnet masks is one way, but it can be difficult to limit different devices to multiple different groups. Potentially more importantly, it doesn't limit the traffic on the network.

I'd recommend a NAT router/firewall device. You can limit what traffic is allowed to pass through by IP address, protocol, direction, etc. You can also reserve IP addresses for a device on the other side of the network. If your PC is on the plant network at 192.168.10.20, and your drive is on the local network at 192.168.1.30, you can have the NAT router reserve 192.168.1.31 for the PC. Traffic from the PC into the local network behaves as if it were from the local network, and the drive doesn't need a defined gateway.

I've also seen devices that can have user specific firewalls, so that you can define different firewalls/permissions for different users. They log into the firewall, it recognizes their PC, and then allows them access until they log out.

Note that NAT Routers block layer 2 traffic (LLDP and most other discovery protocols), and only allow layer 3 and up traffic (IP based) which is often desirable. However, sometimes you WANT a specific layer 2 protocol, and NAT stops being an option.
 
We are using a few 9300-ENA NAT devices already, but I want to really get our network as strong and reliable as possible. Since we don't look to have any major projects coming up in the next year I thought it would be a good time to really concentrate on upgrading my knowledge and the networks.
 
The picture is almost identical to our latest equipment install by our Rockwell integrator.
After digging in to it, I found the 1768-ENBT that I was looking at is not compatible with our 1769-L32 CompactLogix processor. So the only alternative was the 1783-ETAP.
We are kicking around the idea of going with a star topology and a Stratix switch, rather than the ring in the last install.
That would at least allow a partition between the I/O and the PLC network.
 
So, I have a question on that note. I still want to be able to access the drives and I/O from the plant network as that is where our PCs reside. But I do want to isolate them to minimize traffic on the network and also limit access to them from non-control (IT, production, management) people. What is a best practice method to achieve that.
.

I would not use subnet masks unless it was a last or only resort. Making a subnet mask that could "access it all" so to speak would really be doing what is called super netting and depending on the subnet range you have chosen could be a real problem.

Also it's easy to defeat and does not limit traffic well or provide granular control.

On almost all systems even smaller systems it's a good practice to have Drives and I/O on it's own network (Physical and Logical) and have HMI and Supervisory on another (Physical and Logical) network.

On larger or sensitive systems this should be carried further and may have Drives on their own (Physical and Logical) network. and I/O on their own (Physical and Logical) network and HMI / SCADA on their own (Physical and Logical) network with yet another dedicated connection to the corporate network for data collection etc.

I see many people that have PLC access from their office PC on the corporate network and this is a security nightmare.

IMHO best practice for most systems and what I use in my plants is to have PLC, Drives and I/O on one network (Physical and Logical) then have HMI /SCADA on another network (Physical and Logical) and have yet another connection to a DMZ where Historians and other data collection servers sit as well as any program or asset management servers sit etc.

Your corporate network should only connect to your DMZ for data collection reports etc.

To give myself and my employees access to PLC's Drives HMI's from their office we have a server on the plant side of the DMZ that has VM's that run the correct PLC and HMI software and have access to all automation devices through a system of switches and VLAN's.

We access these VM's in the DMZ from our office by means of a Pertino VPN connection and RDP. It's just like being in front of an engineering console but I can get to it from anywhere in the world with my laptop or any desktop just as easily as I can from my office and everything stays Isolated and secure but we have the access we need and the corporate environment has the plant floor data it needs to help run the business.
 
As far as DLR I would use DLR if possible just because it's not that more work to install the redundant media and it gives you a great peace of mind.

With some of the machine operators I have encountered QLR Quad layer ring would not be a bad thing to have.

The only thing I will add about DLR is I see many people use it and follow the same with both cables or run both in the same conduit etc. If it get hit by a fork truck the DLR is not going to help you if it's in the same path or pipe. Just something to consider.
 
Does anyone know why Rockwell has changed the way they do their ethernet configuration?
For years we used 2 ENBT modules, one to connect to our plantwide PLC network. And one to connect all the VFD's and device level I/O.
Now Rockwell is suggesting to put a ring inside the panel with a 1783-ETAP connecting all the drives, PLC, PanelView, and connection to our PLC network.
(see pic)
The issue I see with this is that I can now ping the VFD's and servo controller from our programming computer which makes me nervous....
As far as I can see there is no way to partition an ETAP, and the Rockwell rep doing the installation doesn't recommend using an ENBT????

Is this a new install or modification? I would not use an ETAP to connect the drive to DLR. if it;s a 755 drive I would use that DLR option card and it's another Rockwell drive that uses the 20-COMM series cards then I would use the 20-COMM-ER.

Using the ETAP used to be the method a couple years ago but it sounds like the person advising you has outdated information. An ETAP would work but the 20-COMM-ER would perform better, takes up less cabinet space and is a little cheaper in my neck of the woods so it's a no brainier. I would look carefully at both options.
 
.

I would not use subnet masks unless it was a last or only resort. Making a subnet mask that could "access it all" so to speak would really be doing what is called super netting and depending on the subnet range you have chosen could be a real problem.

Also it's easy to defeat and does not limit traffic well or provide granular control.

On almost all systems even smaller systems it's a good practice to have Drives and I/O on it's own network (Physical and Logical) and have HMI and Supervisory on another (Physical and Logical) network.

On larger or sensitive systems this should be carried further and may have Drives on their own (Physical and Logical) network. and I/O on their own (Physical and Logical) network and HMI / SCADA on their own (Physical and Logical) network with yet another dedicated connection to the corporate network for data collection etc.

I see many people that have PLC access from their office PC on the corporate network and this is a security nightmare.

IMHO best practice for most systems and what I use in my plants is to have PLC, Drives and I/O on one network (Physical and Logical) then have HMI /SCADA on another network (Physical and Logical) and have yet another connection to a DMZ where Historians and other data collection servers sit as well as any program or asset management servers sit etc.

Your corporate network should only connect to your DMZ for data collection reports etc.

To give myself and my employees access to PLC's Drives HMI's from their office we have a server on the plant side of the DMZ that has VM's that run the correct PLC and HMI software and have access to all automation devices through a system of switches and VLAN's.

We access these VM's in the DMZ from our office by means of a Pertino VPN connection and RDP. It's just like being in front of an engineering console but I can get to it from anywhere in the world with my laptop or any desktop just as easily as I can from my office and everything stays Isolated and secure but we have the access we need and the corporate environment has the plant floor data it needs to help run the business.

I agree with every single thing PBuchanan said, as well as his remarks about DLR below.
 

Similar Topics

I have a PH meter that I am trying to bring its data into 1756-L81. I have downloaded the Rockwell MODBUS AOI kit, but I am not sure if I need to...
Replies
2
Views
53
Hi all. Customer wants analog faceplates really bad, even if we explained that it doesn't make much sense in his process. What he wants to see...
Replies
5
Views
90
Hello, recently I saw a graphic from any Rockwell App, I cant identify which one is. Attached a SS. Its used to see dashboard from datapoints and...
Replies
2
Views
127
I'm working with a project that contains some routines in ST but mostly in ladder. Am I correct in assuming this 'rung': DB1001DO._01AV55_OPEN :=...
Replies
4
Views
112
I noticed in Rockwell AOIs, they add a BOOL Output parameter at the end of the "Parameters" list of each AOI that carries the same name as the...
Replies
1
Views
72
Back
Top Bottom