Control via Ethernet ?

T

Thread Starter

Tom Crofton

We have an application using AB SLC5/05's which are connected via Ethernet.

We need to implement four PID Loops where the PV signal is wired to our 'local' PLC and the CV signal is wired to the 'remote' PLC. I would prefer to wire the CV signals directly from the local PLC to the valves (about 1000'), but my customer is insisting that we perform the PID function in our PLC and pass the CV signals over Ethernet to the remote PLC.

I've told them about the non-deterministic nature, of Ethernet vs. hard wiring and they've told me that its just too expensive to hardwire. My rule of thumb is to never do real-time 'control' via communications, but I just can't seem to convince them that this is the way to go.

Does anyone have any compelling arguments, either way?
 
R

Ralph G. McDonald, P.E.

Hi Tom:

We do a lot of control via communications system. However they are slower operations in water and wastewater with required responses in 30 seconds to 5 minute range. You will need to answer several questions.

1. What is the required process response speed vs. network response speed under worst case.

2. How do you detect loss of communications between processors and what is the correct response at each end of the comm link. In a pneumatic convayor that we did had a number sent between registars in the two PLCs. In the remote PLC it caused a reset of a free running timer and the number was sent back to a registar in the master PLC. When the master PLC recieved a correct match it reset its timer, incremented the number which was then sent to the remote PLC. Time out of either timer would initiate correct convayor shutdown and operator notification.

It can be done safely as long as the worst case timing is less then the process timing requirements and the com failure shutdown can be processed in time.

Good Luck

Ralph
 
J
I work for a large international oil company and am in the pipeline operation department. We have a written policy that all control devices will be hardwired to the process control device, which will control the device. We use AB, GE, Modicom, and variest other PLC, for PID operation. Using your problem as an example, due to the SLIGHTEST possibly of loss of communications, between PLCs, the pipeline could be overpressured, causing a breakage of the pipeline and either crude oil, gasoline, LP gas, or harsh chemicals will leak out.

Instead of running the CV all the way back to the SLC5/05, which might pickup noise, place a remote rack for the CV. For the remote rack, to cut cost, you can use Flex I/O, for the CV. Either way, still will need to hardwire the CV to the SLC5/05 that's doing the PID.
 
D

Dean Kindrai

There's another compelling issue about using common Ethernet as a control network. Losing a single Ethernet node can disrupt or totally halt a network. I've personally had this happen (a PC network, a node was damaged be a lightning strike on a phone line, halted the whole network until that node was removed).

Sometimes you just have to bite the bullet and pay for what you need.
 
T
Jerry,

Thanks for your input. You mentioned that using remote i/o would be acceptable. Can you explain why this in any different than using e-net to a remote PLC. Both signals are 'communicated' to the device which is hardwired to the valve. Is e-net less reliable than remote i/o, or is there some other reason? (I'm not trying to be a PIA, just bringing up some points my customer has mentioned to me.)

I think all remote i/o protocols are 'token ring' based, while e-net is strictly peer-peer and does not have a network 'master'. The token ring protocol gurantee's each base some time to communicate with the 'master', while the e-net protocol does not. This makes the token ring setup 'deterministic' while the e-net setup is 'non-deterministic'. To me, this is the biggest problem with using e-net for control purposes.

Does this bother anyone else, or just me?
 
D

David Klebe, WebDock Information Systems

I concur with the other responses. The customer certainly wants to save money, but at the cost of a very unstable system. The question of course is what type of industry this is used in. To show worst case scenario, have the PID operating and yank out the ethernet cable; that should give the customer an idea what extent problems can go to. Also, you would want to have an emergency shutdown somewhere in the PLC local to the CV control actuator. Assuming ethernet slows down or craps out, the process variable will be out of synch, and thus the control output will have radical swings, as if your sampling rate was very very slow and inaccurate. The local PLC should cut out the PID control if the control values exceed any predefined "outer limits". Then at least the pipes wouldn't blow or any other catastrophic loss. Of course, you will be limiting the amount of PID control possible.
Good luck in convincing your customer to do things the right way and the safe way, because it will only hurt them in the end. Perhaps the argument is the extra engineering required to make the system work is more expensive than just wiring the remote rack and Flex I/O...?
 
Top