Using OPC to communicate with GE MKVIe

B

Thread Starter

Brian

I recently upgraded my turbine control panels from MKV to MKVIe. During the conversion we decided to use Modbus TCP/IP to communicate between the DCS and turbine control panels. This has caused a few problems due to the way signals are handled in the new MKVIe software. Our DCS Lead wants to quit using the Modbus and start using OPC.

Does anyone have experience using OPC to communicate between an ABB INFI90 and a GE MKVIe? If so, are there pros and cons that you would be willing to share about OPC compared to Modbus TCP/IP?

Any information is appreciated.
 
Brian,

My experience may be a little dated (I haven't seen a Mark VIe installation for over a year), but here's what I knew back then.

The Mark VIe turbine control panel has MODBUS modules that allow a third-party control system to communicate via MODBUS <i>directly</i> to the Mark VIe--that is, not over the UDH and not via the HMI. It is also possible to communicate with the Mark VIe via the HMI, which then communicates over the UDH to the Mark VIe turbine control panel.

The Mark VIe HMI CIMPLICITY Viewer is actually communicating via OPC to WorkstationST on the HMI, which is communicating with the Mark VIe via the UDH using EGD (Ethernet Global Database). BUT, it was not possible to communicate directly with the Mark VIe turbine control panel using OPC--that's only done via EGD over the UDH by the HMI. And GE doesn't (or at least it didn't) allow any third-party control systems to communicate with Mark VIe turbine control panels directly via the UDH. (The exception to this--and isn't there always an exception--is some Bently Nevada equipment is allowed to reside on the UDH (but then GE owns Bently Nevada, so, ...).

So, it's not clear from your post how you're communicating to the "Mark VIe" using MODBUS. I always think of the turbine control panel (in this case the Mark VIe) as separate from the HMI--because the HMI can be used for other Speedtronic turbine control panels and it's really just a "window" into what's going on inside the Mark VIE--there's NO control done in the HMI, so the turbine will continue to run even if there's no HMI communicating with the Mark VIe.

But, in my experience it's not possible to communicate with a Mark VIe directly using OPC. It has to be done through the HMI if one wants to use OPC. And, again, that's because the HMI, using WorkstationST, is the "gateway" between OPC and EGD when communicating with the Mark VIe turbine control panel.

I hope that wasn't too complicated.
 
B
CSA,

We've not been able to talk directly to the TCP using Modbus yet. We're going through the HMI right now. Supposedly, GE has set up the new UCSA controllers to accept an ethernet connection for Modbus communications. There's actually an ethernet port labeled Modbus on the controllers. However, the GE TA that was on site for our installation couldn't make it work. I do believe it's possible for the Modbus file to reside on the UCSA instead of the HMI. The software indicates that it is possible. I think the GE TA and the DCS "expert" didn't understand how to set the IP address properly.

Currently we've got the Modbus TCP IP linked through the HMI using a BRC410 on the Bailey DCS side. This caused an issue the other day when the HMI went down causing everything coming across the Modbus to go to bad quality on the DCS. That wasn't a tradegy, but when the technician decided to reboot the BRC410s it became a forced outage. I traced it back to some BOP logic in the BRC410. Unfortunately, by then a lot of people had already blamed it on the HMI being down and since they told the first story, it was hard to convince my manager otherwise.

Now, a suggestion has been made to go away from Modbus to a MKVIe viewer made by ABB that supposedly talks directly to the TCP through OPC. The best I can tell, the OPC server just adds another computer that could fail and cause the same issues we've already seen with everything going bad quality. Right now, we've got the ABB tied directly to the HMI through Modbus(Two points of failure). It seems like if we go with this OPC server we would have three points of failure to worry about. I just don't think we need to change the world due to a mistake made by one of our technicians. However, if it's the best thing since sliced bread, I'd be willing to give it a try. I just don't have any experience with it.

I appreciate your response. I've got ABB lined up to come out and explain how this MKVIe reader works. Once I find out, I'll try to update the post.
 
Brian and CSA,

I can tell you that I have worked at two sites now and have configured a connection to talk directly to a MKVE over TCP/IP.
Now I call it a MKVE, since it was a retrofit of an old MKV. I am confused sometimes by GE since the retrofits of the MKV have taken many names. But this site was originally a MKV and was retrofitted to a MKVE, or MKV life extension, but not a "real" MKVIE in my opinion.

Anyway to the topic, at this site we used direct modbus to the controller by installing a device right on the UDH. The device we had talking to the MKVE was not able to talk TCP/IP modbus so we used a TCP/IP to modbus RTU serial device server. In the MKVE ToolboxST configuration they have a "tab" to configure modbus communications. In the different manuals for ToolboxST they talk about using a separate controller as a "gateway" to talk modbus over a type of serial connection so as not to "burden" the controller. We did not go this route, and had no problems with controller idle time. Honestly if you are upgrading from a MKV to a MKVE I find it hard to believe the new controller could be "burdened" trying to run a machine that the MKV could handle.

Anyway, long story short, you should be able to talk directly from your Bailey DCS to the MKVE if that is what you have. There was some small issues and a learning curve during our install, basically in how you configure your modbus pages, as I recall you had to make sure and not skip any addresses, but call them spare. If you have setup modbus in the past then it should not be an issue. Again in my opinion the manuals do a poor job of explaining the modbus options, but in defense of GE manuals I have seen much worse with much less information.

If I can be of more help with this topic please let me know.
 
Brian Hall,

I completely missed your response; sorry.

For ABB to do what they're saying, they would have to have an EGD to OPC "converter"--and while that's possible for data points, it won't get you alarms and events which are handled in a completely different scheme (by WorkstationST Alarm Viewer and it's associated services).

So, it would seem that you are trying to communicate with the TCP (Turbine Control Panel) through the HMI. MIKEVI says he's seen it done through the UCSAs, and while I know that was a "desire" of GE's I know that it was tried and failed on a couple of jobs in years past, but maybe they've got it working now. And, yes, it was written in the manuals as if it was working, but it didn't.

So, it seems there are still some issues with the UCSA "MODBUS" comm port. I seem to recall at one point that the port used an RJ-45 connector, but was for a serial link (required a special cable with RJ-45 on one end and DB-9 on the other). At least, that's one version I saw a few years back--before they got the MODBUS TCP (Ethernet) port fully working. Again, I'd be referring to the Mark VIe System Guide for hardware details--and ToolboxST for software details.

I believe there is a block in ToolboxST that can do the MODBUS communication fairly simply via the card/IOPACK, and possibly the intent is to use that same block for the UCSA MODBUS port.?.?.?

The only way I know of to get MODBUS communications directly with the Mark VIe is through a separate card and IOPACK (don't recall the name, but you should be able to find it in the Mark VIe System Guide, GEH-6721). It had serial (RS232 and -485) as well as MODBUS TCP (Ethernet) capabilities.

Again, as recently as last year the only external communications with a Mark VIe were either through the HMI or via the MODBUS card/IOPACK. The Mark VIe TCP communicates over the UDH (Unit Data Highway, which is an Ethernet link) to the HMI(s) for data and commands using EGD (Ethernet Global Database). One of the functions of WorkstationST is to convert data to OPC and "serve it up" to other OPC machines (I always get the OPC client/server relationship wrong, so I don't try anymore)--including CIMPLICITY Viewer. Alarms and events are handled by other functions of WorkstationST and passed to the WorkstationST Alarm Viewer.

I would imagine it's not a stretch for anyone (ABB included) to create an EGD to OPC converter, but you are right--it's another computer interface/gateway that is a point of failure.

Please write back to let us know how you fare with this.

 
P
Some years ago we developed code to directly communicate with GE Mk VI controllers and this runs on different operating systems and so there is no OPC although we have an OPC server and scanner. If there is interest, why not contact us directly?

--
Peter Clout
Vista Control Systems, Inc.
2101 Trinity Drive, Suite Q
Los Alamos, NM 87544-4103

[email protected]
http://www.vista-control.com
OpenPGP Key 0x0A5A6C85
 
Top