CuriousOne,

Hopefully this solves Wajid29's problem--and thanks for the information!

> Open your Cimplicity Screen in Edit. DO NOT NAVIGATE to
> different frames of the screens. Using the menu bar; go find
> your properties for the screen and go to variables to ensure
> "local_project" is defined.

> Or same process, Right click on AMV and access it's
> properties. AMV properties ONLY. Unclick local project and
> try to add your project. If your project shows up in the
> pull down. Problem Solved!!

 

Wajid,

If you use the Toolbox and try to go on-line, does it connect to the MarkVI and show data? As far as I remember, Toolbox uses TCI and UDH to connect to the panel. If you cannot connect, you have a clear indication that something is wrong with your network configuration and I would concentrate my efforts on that part. I have the feeling that your not marking the network cards and not placing them in the exact same location has something to do with your problem.

Anyway, as everybody else suggested already, this is the kind of problem that, if not easily solved by few clicks, requires somebody with proper MarkVI/HMI/computers knowledge on site.

By the way, the replacement motherboard is identical to the defective one? It might be also a problem of drivers. In the Windows Device Management applet, do you have any unrecognized devices?

 

MArk6TA,

> As far as I remember, Toolbox uses TCI and UDH to connect to the panel.

Many times I've used TCI on PCs which aren't running TCI. I've used wireless PCs running Toolbox to do loopchecks in the field--and I only had Toolbox running on them--not TCI or CIMBRIDGE or CIMPLICITY. (One really can't do loopchecks properly with CIMPLICITY displays.)

CIMBRIDGE also uses the UDH to get data from the Mark VI to pass to TCI. And that's working okay because CIMPLICITY is displaying data from the Mark VI.

This is something very fundamentally wrong, and I'll wager it's self-inflicted (something done during the troubleshooting that wasn't written down and can't be remembered, so it's not being undone). That's usually what happens in these situations when people get into a big panick (which they usually do--I'm not saying that's what's happened in this case, but it seems pretty close). I'm not sure the problem is slot-related with the NIC placements, but if the Primary UDH NIC is not working and there is teaming, then my money's on the teaming set-up. Unfortunately, the teaming thing can get quite complicated--and, as usual, it's NOT well documented (if at all).

GE HMIs are among the worst in the industry as far as complexity and lack of documentation. They update quickly and can be made to display some very nice graphics, but they are just fraught with issues from a mix of types of configurations and button types and display types and points which don't appear in the Project (as many displays are simply copied from other jobs, or the template displays never get cleaned-up prior to or after FAT (Factory Acceptance Test).

My sincere hope is that they get someone to site--because they've invested a LOT of time and money on site up to this point with very little to show for it. And, we all hope that Wajid29 writes back to let us know how the issue progresses--and is resolved!

 

CSA,

I disagree with your comments relating to Cimplicity. Although, the manuals could fill a bookshelf. Cimplicity is well documented.

I, however, agree with your observations relating to GE TA using templates from the factory.....

I will not "take that bet" regarding someone "monkeying" with the screen setup. Your observations over many years would overwhelm the I&C industry with too many examples.

Too many folks get beyond their depth and cry for help. GE would be happy to help.

If I remember correctly; all data for the screens is displayed. Only alarm data is not. Correct me if I am wrong.

If data is displayed, then all connections are working
Software is the PROBLEM.

 

CuriousOne,

I try to be pretty specific, and when I refer to issues with CIMPLICITY I'm referring to the way that GE (Salem, VA USA) implements CIMPLICITY on their HMIs--be it for Mark IV, Mark V, Mark VI or Mark VIe. The whole setup of the HMI is a mysterious moving target which is undocumented. The need to use CIMBRIDGE to communicate with a Mark IV, Mark V or Mark VI makes the implementation a kludge.

I have literally--and I do mean actually, physically--seen a grown man cry when working on a GE Mark V HMI. He was a CIMPLICITY guru--new everything there was to know about CIMPLICITY, and then some. But hard as he tried, he could just not get a once-working GE Mark V HMI to communicate with the two Mark V turbine control panels at site. He spent two LONG days and evenings and nights and just couldn't do it. He called his contacts in Albany, NY, and somewhere in Europe, also. They were all CIMPLICITY (GE Fanuc) experts--but the way GE (Salem, VA USA) implements CIMPLICITY on their Speedtronic HMIs is just a bastardized, undocumented kludge. This man was literally in tears on the third day, defeated and beaten down. He was given the name of a contact in Salem to get some help from and it was like the two of them were speaking totally different languages. He finally called his manager and asked to be allowed to leave site, and was granted permission to do so.

GE Power Generation Services sent three more field service personnel to site, before they finally boxed up the HMI and sent it back to Salem, VA USA, where it took them several days to re-configure the machine and get it communicating with some trainer panels in their lab, and send it back to site. It took the on-site field service person two more days with phone support to get the site information loaded, and to get CIMPLICITY working and get the Alarm Window working after the HMI was returned to site. And, I think the Customer was extremely unhappy with the service--and the bill.

All of this was caused by someone one site trying to add a single CDB signal to the CIMPLICITY Project database--without any written instructions. Of course, he didn't make a back-up of the working Project and HMI files, and when it didn't work he just started willy-nilly trying this, that and several other things--before the site Operations Manager stopped him and asked GE to help (we were on site commissioning another, third turbine). It was clear the issues were beyond us (and we weren't there to work on existing system problems, the existing units were out of warranty and we were in the throes of just beginning to fire the new unit so we didn't have time). The Service Manager found this GE CIMPLICITY guru was available, and the man was knowledgeable and polite and passionate (which is why he got so emotional when he couldn't understand all of the bridging and such).

You have to admit, CuriousOne, GE Speedtronic HMIs using CIMPLICITY are <b>NOT</b> like CIMPLICITY used for a GE 90-70 PLC HMI. They are much more complicated, and with the whole UDH/PDH and teamed network cards (the configuration of which has changed several times since it was initially used--and is <b>NOT</b> documented!) it just adds several layers of complexity. It would seem intuitive to use CIMPLICITY Alarm Manager for alarm display and printing--but, NOOOO! That doesn't work. And one does use CIMPLICITY Alarm Sound Manager for audible alarm indications on the HMI. But, Alarm Logging (printing) is handled by TCI and MS-Windows. And, on <i>SOME</i> GE Speedtronic HMIs CIMPLICITY MODBUS is used--but not on all GE Speedtronic HMIs. Sometimes it's TCI MODBUS. And none of that is documented, either.

CIMPLICITY is a fine program--just not when used on GE Speedtronic HMIs. Were the GE Speedtronic HMI implementation of CIMPLICITY (and TCI) properly documented, well, then, this would be a completely different discussion. If one can understand how things work and are to be configured--then even if it's kludgey then usually one can work his way through issues to resolution. But, when it's kludgey and NOT documented, well, then, this is what we get.

There are now literally tens of GEHs and GEIs and such about individual features of GE Speedtronic HMIs, but they are usually far behind the initial implementations--and they are incomplete and are not usually updated and procedures and configurations change. If you know the current version of the publication is applicable to your site, that's great--but how does one know this? And, inevitably, there is some little tweak or configuration setting or other "minor" piece of information missing or implied which is not fully documented in the publications which causes the user to be unable to make the feature work properly.

And I take exception with GE's willingness to help. There are very few field service personnel who are knowledgeable enough even to be able to properly write a PAC Case to get help from the PAC or GE Salem, VA USA. Most are just, "Screens are black," or "Alarms don't display," or, the most common, "It's not working." And these same field service personnel complain most about the quality of the responses they get from the PAC, most of which are, "Provide more data." And, when you don't know where to start (is it TCI or CIMPLICITY or the UDH or the AMV Object(s)) that's a pretty tall order.

GE field service people typically don't stay in the field for more than 3 years, maximum. It's hard, and when you're constantly learning because you didn't get good training--well it's even harder. So, the turnover is very high, and when they do get training--usually when they're new to the organization, it's only on the newest implementation, and when they get sent to site to work on older implementations they're just stuck and don' know what to do or where to start. If you've never seen a Frame Container implementation of CIMPLICITY displays, how do you know where to start? (I just saw a two-year "veteran" of GE field services encounter that for the first time and opened a PAC Case for help....)

Sure, the Service Managers are glad to send people to site--if they have them! Or to send a Granite Services contractor to site--if they can get one. But, can that individual help with a problem like this on an older implementation when all they've been working on is Mark VIe with CIMPLICITY HMI Viewers and WorkstationST? If they can write a good PAC Case--maybe.

It's just plain sad. That's why people turn to forums like this--because it's hard to get service on older implementations from the OEM. They just don't train people to support the older equipment, and many Service Managers think every HMI is just like every other HMI, so any field service person should be able to work on it.

So, if I was unclear--I apologize. It's the implementation of CIMPLICITY on GE Speedtronic HMIs that's poor and undocumented and kludgey. I'll try to be more specific when I whinge in the future....

 

Sometimes documenting screens can help resolve issues. This is an brief example of the output file. One can set the setup of local_project.<pre>
(Version 30)
(DocumentSummary)
(GmmiToplevelDocument
(GmmiDocumentObject
(GmmiContainerObject
(GmmiObject "" 0
(Help "" "" "")
(GmmiPointMap
(GmmiPoint "\\CRM1_SVR\SITE_NAME" 3 80 1)
(GmmiPoint "\\CRM1_SVR\$LOCAL.COMPUTER" 3 1 15))
(GmmiOptionTable
(GmmiVariables
(GmmiVariables "LAST_AUX_FRAME" "17" 0)
(GmmiVariables "LAST_CTRL_FRAME" "1" 0)
(GmmiVariables "LAST_MON_FRAME" "11" 0)
(GmmiVariables "TEST" "6TT" 0)
(GmmiVariables "UNIT" "T1_" 0)
(GmmiVariables "DATA_CTRL" "1" 0)
(GmmiVariables "LOCAL_PROJECT" "1" 0)
(GmmiVariables "GEN_CURVES" "0" 0)
(GmmiVariables "NAV_CTRL" "1" 0)
(GmmiVariables "LAST_TEST_FRAME" "23" 0)
(GmmiVariables "UNIT_NO" "1" 0))
(GmmiProcedureMap
(GmmiProcedure "ViewTripLog_GT1" "" 0 "" "" "" 0
(ExecCond "" "")
(GmmiActionList
(GmmiExecAction 0 0 "G:\EXEC\TRIPVWR.EXE /UNIT:T1" "" "" "")))
(GmmiProcedure "L2_Monitor" "" 0 "" "" "" 0
(ExecCond "" "")
(GmmiActionList
(GmmiVariableAssignAction 0 "NAV_CTRL" "2" 0)
(GmmiInvokeScriptAction 0 "" "SetLastFrame"
(GmmiParameterBlock 1 1
(GmmiExpr "{&h7B}LAST_MON_FRAME}")))))
(GmmiProcedure "L1_Gas_Turbine_1" "" 0 "" "" "" 0
(ExecCond "" "")
(GmmiActionList
(GmmiVariableAssignAction 0 "UNIT" "T1_" 0)
(GmmiVariableAssignAction 0 "UNIT_NO" "1" 0)
(GmmiVariableAssignAction 0 "LOCAL_PROJECT" "1" 0)))
(GmmiProcedure "L3_Wheelspace" "" 0 "" "" "" 0</pre>

 

Dear Mark6TA,

When we use Toolbox and click go on-line, it goes online and works properly (means all the data is showing and we can force/unforce the signals as well).

We have replaced the motherboard with exactly the same model and all the devices in device manager are recognized and working. But besides this as I already written in the thread that we did not mark the network cards and reinstalled them in an unknown order.

I just want to ask that what if we change the slots of our HMI (I mean what will be the consequences?

 

CSA,

I completely agree with you observation. I actually commented that you would find fault with the GE gas turbine distribution of the product.

I have been involved with the distribution of the "NEW TCI" and effects relating to Cimplicity. I have written GE Technical Support describing problems with point manager and TCI.

No response. as if I had offended them by discovering problems. Management told me to quit solving GE problems. They had paid GE.
problems stayed GE is now leaving our organization with new support for Emerson Ovation.

I have discovered and solved all of the problems since startup on our turbines regarding backup, download to MKV, etc.

I have Viewers that report all alarms from 15 different projects residing on Servers that span hundreds of miles as far as physical location.

The Cimplicity product is solid. Bad support has made the product intolerable for owners of a GE Industrial Gas Turbine.

Sorry you feel this way.

 

We found a picture of the CPU that we removed on day when this problem came. Based on that photo we changed the order of our network cards and verified connection as well. Means when we plugged the cable marked PDH Primary, PDH Backup, UDH Primary and UDH backup in the same connection activated that shows order is absolutely right. But still we are at the same stage where we were, no alarms are showing in alarm window.

We are going for the on-site support as well but I want to know the reason behind this issue.

 

Hello again,

Sorry for not replying for a long time. Is your problem solved?

As CSA suggested, if everything else is working, the problem might be the teaming of the UDH/PDH network cards. I don't know in detail how the teaming setup works internally, they might depend also on the MAC address. In this case, swapping two cards when you changed the motherboard would produce an error and somehow the alarms may be sensitive to that. It is difficult to say without seeing logs, configurations and the rest. Again, my best suggestion is to have somebody with good knowledge on Cimplicity and computers to try to fix it. Or even re-install everything from scratch.