Remote GT Operation Modbus or Ethernet or Controlnet


Thread Starter


We have Solar GT controlled by turbotronic Control System using Controllogix AB PLC system with the HMI located in remote area. As our plant operators are sitting in another Place (Main Control room), then we need to transfer the operation facility to be located also in the Main Control room. There are different options to implement this, like using Modbus to communicate between AB PLC and Honeywell DCS and operate the GT from Honeywell DCS. or using Ethernet or ControlNet and install AB HMI in the Main Control room or use hardwired to connect signals from AB PLC to Honeywell DCS. DO we have to use hardwired? or Software communication is OK? which is better to use in this case Modbus and operate from DCS? or we better use remote station from Allen Bradley itself and locate in the control room where our DCS operators are sitting?

Unless there is some company practice or technical regulation or standard that requires the use of hard wired signals for control of equipment such as a heavy duty gas turbine you are free to use whatever scheme is easiest to implement. MODBUS generally doesn't have controller time-date stamps transmitted with data.

But all methods have been used, and some will require more effort and hardware than others. Most sites seem to prefer having all operator interfaces in one control system (DCS) so the operators can remain sitting as much as possible (that is, the operators prefer to remain sitting as much as possible whenever possible....). But, unless you have someone at the site who's well-versed in many aspects of the DCS (hardware interfaces; programming; display creation and modification) you will need to hire one or more aspects of the project out to be done--and that can be difficult to coordinate and supervise. Not to mention trying to "satisfy" all the operators when it comes to displays and buttons and, well, just trying to make operators happy can be a never-ending and unforgiving and frustrating and maddening and thankless task. Power plant operators are the most resistant to change of any group or entity or substance known to mankind--that is, they have the highest inertia known to mankind. They are extremely resistant to change, but if you can get two or three of the motivated and involved in improving the operator interfaces you can't STOP them, either! The perfect example of the principle of inertia--and sometimes it's just best to let sleeping dogs lie and get another HMI exactly like what they're already accustomed to and move on to a project with a lesser degree of difficulty and which will provide more personal satisfaction and reward than trying to appease operators.

Hope this helps!
Thanks CSA for your reply.

You have mentioned that"MODBUS generally doesn't have controller time-date stamps transmitted with data". Can you please elaborate more on this Point? Does this mean I can not use Modbus for Control as there is no time stamp? What other type of communication protocols that have time stamp?

MODBUS communication doesn't generally put time/date stamps from the controller where the data originates. It doesn't preclude using it for control; it just means that if you try to store the data on the DCS for retrieval or try to use the data for troubleshooting it can be very difficult to relate data to time when looking at multiple data sources. Ideally, a value or state will be time/date-stamped with the controller's time/date which will make troubleshooting easier. But, LOTS of plants use MODBUS for control without time/date stamps. It all depends on what you want to do with the information--and many plants make the mistake of assuming the data has accurate time/date stamps and only after trying to troubleshoot a problem do they learn it doesn't.

MODBUS is very popular, but it does have some limitations that are not always understood when it is chosen and implemented. I'm just suggesting you understand all of the factors of any communication method/protocol before choosing and implementing one only to find out it has unanticipated shortcomings.

As for the properties of other communication methods/protocols, I don't generally work with them. You would need to research them using the manufacturer's data sheets which are implementing them--as I like to say, there is MODBUS--and then there is MODBUS. Even though it's a pretty widely known and used "standard" many manufacturers take some liberties with some aspects of the "standard" which can lead to some aggravating and frustrating times trying to sort out why one or two critical things aren't working--only to find out the manufacturer at one end of the comm link chose to do something different than the manufacturer at the other end of the comm link. (Little things like this are rarely documented by the manufacturer, and require the manufacturer's assistance to solve.)