I want to configure a modbus RTU slave on MarkVIe. The slave is S7 PLC. I configured it there and simulated it using MODBUS simulator.

And then i have to display the slave data on cimplicity HMI. I hope you will be able to help me.

thanks
capriconian

 

xMasterSlave provides DNP3, Modbus Master and Slave simulator for free.
You can download it from the link below:

http://members.shaw.ca/xMasterHMI/xMaster

 

Have you tried to use OPC for this? Download OPC Server for Modbus:

http://www.matrikonopc.com/opc-drivers/128/base-driver-details.aspx

Once that is installed and configured, you will be able to get your data in cimplicity HMI.

Let me know if you need any help

Wassim Daoud
Global Solutions Architect
www.MatrikonOPC.com

 

Actually the client want to it through the controller. Otherwise using an OPC is good option. In My case the PLC is slave and the Mark Vie is the master. I need the reference manual which guide me exactly.

Thanks
Capriconian

 

MarkVI can only be used as a Modbus slave, not as a master, if you buy the opc servers separately it will certainly be a very expensive project.

The best thing you can do is use the OPC server from cimplicity. Cimplicity has an opc server for modbus usually used to communicate with the customer DCS.

fausto0

 

I've been watching this and other posts by this originator, and it's just not clear what capriconian is trying to do. As will be seen below, I don't how much I can really contribute--except to try to clarify a couple of things for everyone trying to help this originator, and maybe even the originator. It may, or may not be helpful in completing the task capriconian is trying to accomplish, but it should help everytine (including capriconian) in defining terms and in trying to determine what is possible and what's not. I would speculate if you asked three people in GE if (something like this) were possible, you'd get three different answers.

The GE Speedtronic HMI is NOT the Mark VIe (or the Mark VI, or the Mark V, or the Mark Ve, or the Mark V, or the Mark IV). <b>The GE Speedtronic HMI is a means of communicating WITH</b> the the Speedtronic panel and should be considered as such, because it is NOT the Speedtronic (regardless of Mark version). It's a necessary component of the turbine control system, but it's NOT the Mark [whatever]. For all intents and purposes, a GE Speedtronic HMI can be used with some Mark IVs, a Mark V, a Mark Ve, a Mark VI, a Mark VIe. It's just a way of monitoring, issuing commands, and configuring the Speedtronic it's being used to communicate with.

Next, the Mark VI and the Mark VIe are not the same. While they may share some common I/O terminal boards and components they are not the same.

Up until the Mark VIe, GE did not permit MODBUS communications <b>directly</b> with the Speedtronic panel. All MODBUS communications (ALL communications) <b>had</b> to be done <b>through</b> the HMI. Full stop. No exceptions.

And, it was my understanding (I'm no MODBUS expert and don't want to be) that, at least early versions of, the GE Speedtronic HMI were not capable of being a MODBUS Master. There were early versions of the GE Mark V HMI that used the TCI service for MODBUS communications. Then, without documentation or announcement, the CIMPLICITY MODBUS function started being used. I don't know if CIMPLICITY can be a MODBUS Master or not. I don't know if CIMPLICITY <b>as used on a GE Speedtronic HMI</b> can be a MODBUS Master for the Mark [whatever].

And I want everyone to understand that CIMPLICITY <b>as implemented on GE Speedtronic HMIs</b> is <b>not</b> exactly the same as CIMPLICITY in any other application. CIMPLICITY on a GE Speedtronic HMI does not communicate directly with the Speedtronic panel, so sometimes the things that can usually be done with CIMPLICITY on other applications can't be done with CIMPLICITY on GE Speedtronic HMI applications. (I've see several grown men very knowedgeable with CIMPLICITY throw their hands up in disgust and nearly break down in tears when trying to work with CIMPLICITY running on GE Speedtronic HMIs.)

Now, with the Mark VIe, there is a serial communications terminal board, the SSCA, which along with an I/O Pack, the PSCA, can be used to allow communications directly with the Mark VIe. In other words, if this card/pack combination is used then it's not necessary to communicate <b>through</b> the HMI.

This card/pack combo is described in some limited detail in GEH-6721. An electronic copy of this manual should be present on any of the HMIs being used to communicate with the Mark VIe at the site. If not, then it should be available on one of the CDs provided with the HMIs at the site.

This card/pack combo is relatively new, though, and may not be in earlier revisions of the manual, so one would like to have the latest revision possible. (No; I can't provide electronic copies of the manuals.)

The last time I had a chance to look at GEH-6721 with respect to the PSCA/SSCA card/pack combo I believe I read something about 'serial MODBUS Master' capability. But, as is typical of GE manuals, it was very cryptic and not being MODBUS-minded I just kind of glossed over the info, making a mental note of the statement. ToolboxST must be used to configure the card/pack combo for MODBUS communications, and I would imagine that there is some limited 'Help' information in ToolboxST about that.

I believe there is also a GE manual for MODBUS communications with Mark VIe panels, but I haven't seen it (it's only an unconfirmed rumor).

So, capriconian, I don't know what you've agreed to provide or do, but it does seem that you don't understand how MODBUS communications can be accomplished with a Mark VIe: either through the HMI, or through a PSCA/SSCA card/pack combo, which is programmed using ToolboxST.

And, this is the extent of my knowledge on this subject, which is why I've been reluctant to respond until now. I'm just trying to get everyone who's trying to help capriconian, and capriconian, to step back and understand what the possibilities are or might be, and then get capriconian to explain what exactly is trying to be accomplished using what components.

capriconian, are you trying to use the HMI as MODBUS Master? Or are you trying to configure a PSCA/SSCA card/pack combo using ToolboxST as a MODBUS Master? Have you looked at the 'Help' function of CIMPLICITY to see what might be possible with CIMPLICITY? Have you looked on the GE Speedtronic HMI to see if the manuals you seek are there (they should be)?

I would imagine that if the originator is trying to communicate with the Mark VIe through the CIMPLICITY-based HMI, that there would be some 'Help' information in CIMPLICITY that could be used to understand what is possible and what isn't, at least with CIMPLICITY, though probably not what can be done with <b>CIMPLICITY as implemented on a GE Speedtronic HMI</b>.

So, the recommendation is this: Define how this communication is to be done. Determine if the method can be made to work (i.e., can CIMPLICITY be used as a MODBUS Master with a GE Speedtronic Mark VIe). Then proceed with implementation, if possible.

Yeah; every Customer wants a "direct" connection to the Speedtronic (Mark whatever). But, that isn't always possible. And, unless the Mark VIe has a PSCA/SSCA card/pack combo, MODBUS communications will likely have to be done through the HMI running CIMPLICITY. Using whatever means possible (CIMPLICITY MODBUS; CIMPLICITY OPC Server; third-party OPC Server).

Now, there's one more thing that's really going to make everyone's day. The GE Speedtronic HMIs that GE is now shipping with Mark VIe Speedtronic control systems are using something called ControlST to communicate with the panel, and the "role" of CIMPLICITY is being reduced to that of a "viewer", just for the graphical user interface. (Hopefully even that will go away some time soon!) So, depending on the vintage of the Mark VIe at the site, there may even be more extenuating and restricting circumstances.

Ain't this GE Speedtronic HMI stuff fun? (It's really sad, actually.)

 

If you want (and GE allow to do this)

MarkVI: you can use VSCA+DSCB card acting as Master Serial Modbus

MArkVIe: you can use PSCA+SSCA card acting as Master Modbus for both Serial and Ethernet communications.

You can find details on GEH-6421-VolII for MArkVI and GEH-6721-VolII for MArkVIe

Simone

 

Just to clarify, ControlST is the name of the whole software package for the Mark VIe DCS, including ToolboxST, WorkstationST, and various other components. WorkstationST is the services component that runs on the HMI PCs and performs a number of useful functions: OPC DA/AE client/server, Modubus master or slave, alarm server, historian/recorder, GSM, etc. WorkstationST is the modern equivalent of TCI, but on steroids. It even supports Mark V directly now.

I doubt Cimplicity is going away any time soon, but the user experience is getting much better since ControlST V3.3 or so. For instance, adding a new point to an HMI screen used to involve multiple steps and rebuilding the HMI project. Now, you just mark the variable as on EGD in ToolboxST, save, and it is immediately available in Cimplicity.

I'm curious though, what specifically are the problems with Cimplicity with a Speedtronic? I hear a lot of general complaining, but little specific. I've never had a major problem with it, but then I haven't extensively used many other HMI or Scada packages.

 

GE's implementation of CIMPLICITY for turbine control has never been a straightforward CIMPLICITY installation. Until the most recent versions of ControlST, there has always been at least one app running in the background (CIMBRIDGE or TCI) and the alarm display and the synchronizing display are special AMV objects which are peculiar to the turbine control HMI application.

Further, just as you have noted, adding a point to a CIMPLICITY project can involve several steps, and GE has failed miserably in documenting those steps for the various versions of CIMBRIDGE, TCI, and CIMPLICITY over the years. So, what works at one site with TCI v. 1.4 and CIMPLICITY 6.1 SP 3 on MS-WinXP will not work on another site with TCI v 1.2 and CIMPLICITY 5.3 SP1.

And, then there's the application issues. There are .m6b file, .hmb files, and .reb files, and on a multi-unit site with Mark VIs and Mark Vs, it's really complicated. It's very complicated on a multi-unit site with Mark VIs, EX2100s, and Static Starters (LCIs). It can take four to six hours to add just one signal to each of four gas turbine applications on a site with four GTs, two STs, six EX2100s, four LCIs, and 10 HMIs. And heaven forbid if you mistype the signal name on one of the GT HMIs!

There's the frustrating use of changing colors on bar graphs for exhaust T/Cs that exceed the TTRX value. On any gas turbine, there may be two, three or more exhaust T/Cs that exceed the exhaust temperature reference when operating on exhaust temperature control, but the average exhaust temperature is still equal to the exhaust temperature reference. But, those bars changing to red just freak operators and their supervisors out! And for no good reason.

And, then there's the maddening use of multiple target (push-button) methods, which was also never documented. You can open a CIMPLICITY display and find SRTP pushbuttons, analog setpoint pushbuttons, smart object pushbuttons, and scripts driving pushbuttons which all have the same appearance to the operator. And why? Because GE have no standard for changing all of the targets/buttons on a display when they change one. So, one ends up with a mish-mash of target/button types. And, there's no documentation for any of the methods, no standard for what should be used when or for what purpose. It just adds to the madness.

How about buttons on the Alarm Display that come from the factory that don't work? Alarm Lock, Alarm Unlock, and Alarm Silence are the three most common buttons that don't work "out of the box." And those are pretty critical to proper Alarm Management, wouldn't you say?. Of course, the fixes are usually relatively simple, if you understand the AMV object and how to implement them. If they haven't changed to scripts.

Lastly there's the whole business of password levels for the OS, for CIMPLICITY, for Toolbox or ToolboxST, and how they work sometimes and don't work others. None of the password level intentions are documented, as is none of the implementation methods and what to do for which type of application. It's very common for field services people to have to spend hours to get basic operation functionality working for the OPER level! It usually becomes a punchlist item for people to have to return to site to get working, with lots of factory support. And, it all seems to change with every version of CIMPLICITY, and Toolbox, and ToolboxST (ControlST) and OS (MS-Windows version).

As has been said before, grown men with a lot of CIMPLICITY experience have been reduced to tears trying to modify CIMPLICITY displays on turbine HMI applications. And more than once.

That's just a partial list of problems with GE's implementation of CIMPLICITY on turbine control HMI applications. The take-away (to use GE-speak) from all this is that there is or are no standards that even people in GE can refer to, there is little or no documentation for most of the functions that are peculiar to CIMPLICITY as applied for turbine control HMI applications, and it changes quite frequently, with no documentation for the new methods.

It would be one thing if GE field services people knew how to work with these various versions and changing implementations, but generally they don't. And, it's very difficult for them to find a reliable source of information, so a lot of what's generally known is all tribal knowledge, and a lot of that is just myths and wives' tales.

Kind of like calibrating LVDT feedback every time there's a problem with starting or tripping or a servo is replaced. Tribal knowledge that's not worth the paper it's not printed on.

 

You can use the OPC Server for MarkVI here for this:

http://is.gd/cKfA0

Wassim Daoud
Global Solutions Architect
www.MatrikonOPC.com