 |
plc.myforum.ro PLCs users www.plc.myforum.ro!
|
| View previous topic :: View next topic |
| Author |
Message |
turbokinetic Junior 2

Joined: 21 Oct 2012 Posts: 23
|
Posted: 19/09/2020 02:34 Post subject: Dual independent Ethernet ports in one ControlLogix module.. |
|
|
Got a question. We have a ControlLogix chassis which has no empty slots remaining. The processor is a 1756-L75. There is a need to install an additional Ethernet network connection, which is independent of the existing 1756-EN2T connection. It needs to have a separate IP address and not bridge the two networks together.
The reason is as follows. This is a generator control system. The metering and synchronization hardware communicates with the PLC via Ethernet IP. This is a critical connection, which if interrupted is a critical failure and requires a shutdown of the machine due to loss of safety functionality.
The design of the internal cabinet Ethernet has the PLC, a local PanelView HMI, and the metering hardware interface; connected with a network switch.
All was well until the customer decided to connect a "maintenance network" to the system. This was not in their initial project specification but was decided after production of the cabinets. When they connect their "maintenance network" to the cabinet's internal network switch (which we told them not to do) there are IP crashes with other random equipment on the facility. This causes a loss of comms to the metering hardware, and a unit shutdown. There are endemic network security and integrity issues on this facility which are outside of our control, and which we want to prevent from interfering with our equipment.
We have been looking at the option of a dual-port Ethernet module; however it seems that these modules do not have two independent ports with separately configurable IP addresses. It looks as if anything plugged into the second port of a module such as a 1756-EN2TR will become a part of the internal network in the same manner as if it were plugged into the Ethernet switch in the cabinet.
So basically, what we are looking for is a single module which provides the functionality of two separate 1752-EN2T modules but taking up only one chassis slot.
This is a 13 slot chassis, with the next size up being 17 slot. According to the literature I could locate, the dimensions of this chassis are slightly too long to fit in the cabinet; and there is no room for any additional remote chassis sections.
Thanks for any info!
Sincerely,
David |
|
| Back to top |
|
 |
nobodyspecial Junior 2

Joined: 26 Oct 2018 Posts: 21
|
Posted: 20/09/2020 04:16 Post subject: |
|
|
As a previous PG gas turbine controls tech/test engineer I will tell you that you need to be careful and prioritize the control over the maintenance network. The PLC will give all other non-essential comms the middle finger if needed. e.g. if using OPC data logging or other crap, the PLC CPU will hold off these comms to ensure control functionality. See my comments below.
I would deploy a high end managed switch with a "control" VLAN setup to operate all critical equipment. If necessary I would deploy another switch to consolidate all "control VLAN devices onto. I would then deploy a second VLAN for "maintenance". I would connect this "maintenance" VLAN port to a router to handle DHCP addresses so all users can use DHCP and not static addresses. This way if some dummy connects a programming laptop with the same IP as the AVR the whole thing doesn't come down. Obviously using separate IP subnets. Some managed switches can do the router in there also, depends on make/model.
Throw an EWON for remote support in there too.
The last thing you want is the sync or AVR to be delayed due to comms. You haven't lived until a 250 ton turbogenerator twist the 36" tall I-Beam frame due to load steps or closing out of sync!
We would run redundant CL racks with the redundant module, one ethernet network for all controls. The end user had the luxury of carving out a VLAN but most didn't and rolled the dice. We would datalog at the factory at 100mS during performance testing without issue. Sometimes during critical junctures of testing the PLC would hold off comms in order to maintain control. Using OPC dataloggers we tried to cripple the controls on purpose as internal testing required it. We used mostly structured text and some ladder with scheduled task for the most sensitive. Due to the scheduled task timing, the CPU would push off non essential comms based on the module/sub system's RPI. The identical IP would not bring it down but could based upon the nature of the connection, is it a laptop with someone surfing the internet for face crap or youdummy tube? or a hacker trying to hack/take it offline. Hence my reasoning for the router to isolate the control from the maintenance. The router provides significant security assuming you didn't get it at Walmart. |
|
| Back to top |
|
 |
turbokinetic Junior 2

Joined: 21 Oct 2012 Posts: 23
|
Posted: 20/09/2020 04:23 Post subject: |
|
|
| nobodyspecial wrote: | As a previous PG gas turbine controls tech/test engineer I will tell you that you need to be careful and prioritize the control over the maintenance network. The PLC will give all other non-essential comms the middle finger if needed. e.g. if using OPC data logging or other crap, the PLC CPU will hold off these comms to ensure control functionality. See my comments below.
I would deploy a high end managed switch with a "control" VLAN setup to operate all critical equipment. If necessary I would deploy another switch to consolidate all "control VLAN devices onto. I would then deploy a second VLAN for "maintenance". I would connect this "maintenance" VLAN port to a router to handle DHCP addresses so all users can use DHCP and not static addresses. This way if some dummy connects a programming laptop with the same IP as the AVR the whole thing doesn't come down. Obviously using separate IP subnets. Some managed switches can do the router in there also, depends on make/model.
Throw an EWON for remote support in there too.
The last thing you want is the sync or AVR to be delayed due to comms. You haven't lived until a 250 ton turbogenerator twist the 36" tall I-Beam frame due to load steps or closing out of sync!
We would run redundant CL racks with the redundant module, one ethernet network for all controls. The end user had the luxury of carving out a VLAN but most didn't and rolled the dice. We would datalog at the factory at 100mS during performance testing without issue. Sometimes during critical junctures of testing the PLC would hold off comms in order to maintain control. Using OPC dataloggers we tried to cripple the controls on purpose as internal testing required it. We used mostly structured text and some ladder with scheduled task for the most sensitive. Due to the scheduled task timing, the CPU would push off non essential comms based on the module/sub system's RPI. The identical IP would not bring it down but could based upon the nature of the connection, is it a laptop with someone surfing the internet for face crap or youdummy tube? or a hacker trying to hack/take it offline. Hence my reasoning for the router to isolate the control from the maintenance. The router provides significant security assuming you didn't get it at Walmart. |
Thanks for the detailed reply, I greatly appreciate it!
Our system is not as in-depth as yours were, but the idea of a managed switch would be a good step in the right direction. The cabinet does have a managed switch (a Stratix) which may offer some functionality we could use. This is going to be "plan B."
But I believe we're going to more than likely go up a size with the chassis and install a second -EN2T |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group Fa-ti si tu propriul forum GRATUIT, pe www.myforum.ro
|