Few days ago our GT CCR HMI was responding very slow, we tried to restart the computer but "Error Occurred" alarm appeared on both RAID configured physical disks while restarting. We checked the computer and found motherboard faulty. We used both the hard disks in another but with same specification computer and started the HMI. All the process variables were showing normal only alarms are not showing. Just to inform you all the we use Mark Vi controller and Cimplicity HMI version 6.10 server. We tried to start and stop TCI services but this did not solve the issue. We replaced the project file as well but still problem is persisting. Also we put get build and validated .hmb file.

Please guide us through to the solution of this issue. All other process variables are normal but alarms window is blank.

 

Dear Wajid29, when you moved the disks over to the other PC did you also move the hardware license dongle to the new machine? Depending on the age of the machine there will usually be a USB dongle inserted in a USB port on the back of the machine or a USB cable internal to the machine with the dongle attached. This dongle is needed for the TCI service to run properly. If you did not move the dongle you should also see an error when the machine boots indicating TCI encountered an error and needs to close. I would suggest checking the TCI log file located in G:\Log\TCI.log to see if there are any errors associated with the service. This is usually the only reason why Cimplicity would be operating normally, but no alarms are displayed in the alarm window, since the TCI service handles the alarms and events separate from Cimplicity.

Please write back and let us know how you proceed.

 

Thank you for the reply and yes we moved hardware dongle license as well. We started and stopped TCI services as well but that did not work as well. When we open Alarms and Event logger it shows the error "unable to link to turbine control interface". We checked the alarms in database and found all alarms present there.

 

Have you checked the TCI Log file that I suggested in the previous post? This log file can be opened with a text editor like notepad. The log file should provide information as the status of the TCI services and let you know if there is a problem with TCI that is preventing it from starting properly, which could account for why you are not seeing any alarms or events displayed in the alarm screen.

 

Thanks for the reply. Sorry to say i did not check the TCI log file, but i will soon write back to you regarding this. And we tried to recover our image file in spare computer but that computer has also the same issue. Unable to create TCI link alarm is displayed when we open Alarms and event logger.

Please give me a solution to this problem.

 

TCI.log file says this:
TCI is starting.
...Windows UTC Time: 2015-06-18 10:29:24
...Windows Local Time: 2015-06-18 10:29:24
Defined G: as C:\PROGRA~1\GECONT~1\TCI.
Defined F: as E:\Site
Version Information:
...This is TCI Product Code Version V03.05.10C
...Packaged for CD-ROM distributions.
...Running under Hardware License Key Serial Number 8857.
TCI is loading the Site Configuration File F:\CONFIG.DAT.
TCI is converting Data Dictionaries.
..Converting unit 1 (G1 in F:\UNITG1)
....XS has determined that the unit is in the Mark VI family of products.
..Not loading CONST_Q.SRC, the file was not found.
TCI is loading Data Dictionaries.
..Loading unit 1 (G1 in F:\UNITG1)
TCI is launching application tasks.
TCI startup complete.
TCI has been notified of a system shutdown.
TCI is stopping.

 

Dear Wajid29,

I guess I am a little confused at it looks like the last time TCI successfully started was 6/18/2015 which is over a month ago. I assume it has not been that long since you booted the PC. But is appears that when it did boot at that time TCI was operating properly.

 

Yeah you are right that TCI was working properly up to 18/07/2015. After that GT HMI was responding very slow which is why we tried to restart the computer but during restart we got physical hard disks fail error. When we reset the hard disk from RAID configuration then our HMI started normally and all the process values were showing as before, but alarms were still not showing. We tried to spare computer with backup image but the same issue is repeating itself on the spare as well.

 

Dear MEIKI

I am waiting for answer. Please get me to the solution of this issue.

 

Wajid29.

While we're waiting for <b>MIKEVI</b> to respond, have you confirmed that the Alarm Window setup is correct for new HMI? Could someone have fiddled with the default setup for the Alarm Window causing it not so show alarms and events from the unit?

You haven't told us if there is another working HMI communicating with--and receiving alarms/events from--the Mark VI. I presume there is, otherwise it wouldn't be possible to safely operate the turbine and auxiliaries.

Also, have you used the command prompt programs, ALMDUMP1 and ALMDUMP2, to see if alarms are being broadcast by the Mark VI on to the UDH?

If the Mark VI is broadcasting alarms/events to the UDH but this particular HMI isn't displaying them in the Alarm Window (which is a CIMPLICITY AMV object created by GE specifically for Speedtronic turbine control system alarms and events and embedded in CIMPLICITY displays) then there's something amiss with the configuration of the AMV object or the default Alarm Window settings. If you're able to see data values and send commands to the Mark VI from this HMI which isn't displaying alarm/events in the Alarm Window, and the HMI can read alarms using ALMDUMP1 and ALMDUMP2 (which are run from a Command Prompt/"DOS" window), then something's wrong with either the AMV object configuration and/or the Alarm Window settings have been mucked-up and the alarms aren't being displayed.

Based on the information provided, it would seem these are the best two possible issues for resolving the problem--ensuring the Mark VI is actually broadcasting alarms/events to the UDH by using the two ALMDUMP programs, and then ensuring the configuration of the Alarm Windows and the CIMPLITICY AMV object is correct.

Hope this helps!

 

This is nothing new with alarm manager snap-in. You must re-establish the connection within alarm manager. It must be done within Cimplicity in edit mode. The snap-in has special properties which must be accessed with Cimplicity in edit mode.

 

Dear CSA thanks for your reply!

We have checked the alarm setup in HMI (installed in CCR) which is not showing the alarms and found normal. We are able to see the data values and send commands to the Mark VI from this HMI.

Yes, we have another HMI in local control room, which is working normal (alarms and events are showing normal).

We have used the command prompt programs, ALMDUMP1 and ALMDUMP2, but "unable to connect to server task" and "unable to map to system global section" errors appeared. Same errors are appearing when we open alarm/event logger from explorer.

We have checked the configuration of CIMPLICITY AMV CONTROL OBJECT in alarm.cim screen and found "connect to local project" already checked.

can you please contact us on below email so that we can provide you more detail/screenshots?

[email protected]

 

Dear Wajid29,

I am sorry for not replying sooner. I am still convinced that the issue with this HMI is something to do with the TCI service not running, or not running properly. I base this on the fact that you say: "no alarms are displaying in the embedded alarm object that is part of your cimplicity screen."

When you attempt to use the TCI alarm & Event viewer it is unable to connect to the TCI interface. And lastly the TCI log file does not show the service running.

First I would access the computer services from my computer\manage\services and applications\services.

Verify that the TCI service is "started" and set to automatic.

Next from control panel select TCI and verify that the TCI Site tab is referencing the correct path for the site file. Depending on the vintage of the HMI it will either be E:\Site or C:\Site.

Make sure that the path is correct and then make sure that the file Config.dat exists in that folder file path.

For some reason I think the TCI service is either not starting or is being stopped. If we can figure that out then everything should start working properly.

When you open a command prompt and enter "net start tci" What happens? Does it return a message saying The TCI service is starting, and then a second line saying the TCI service was started successfully? If not what message is returned?

The last question I have is regarding the TCI license dongle. IF you were to shutdown the PC. Then remove the dongle and restart the PC, and verify that a message comes up when booting that indicates that TCCI encountered and error and needs to close. This would verify to me that the PC is correctly recognizing that the TCI dongle is missing.

This is a strange problem since none of your files or configuration should have changed since you are using the original disks, but hopefully in time we can figure out the problem and all learn something.

 

Wajid29,

This is odd. I would suspect something is amiss in the TCI Control Panel Applet. Alarms/Events are special classes of communication, and TCI has to establish a connection to the Mark VI in order to be able to receive alarms/events and then pass them to the CIMPLICITY AMV Alarm object to be displayed in the alarm window. It seems that for some odd reason TCI isn't re-establishing this connection--which is also odd for another reason: the Mark VI broadcasts alarms/events onto the UDH, I don't believe they're specifically directed to any particular HMI. TCI just needs to know that it needs to get alarms from a Mark VI and to do that I think it needs to know the proper IP address of the Mark VI, which I believe is defined in the TCI Control Panel applet. (Open Control Panel, and double-click on the TCI Control Panel applet, and check all of the tabs. NOTE: Some of the tabs are for Mark <b>V</b> communication (ARCnet stuff) and are NOT applicable to Mark VI. (TCI is used for both Mark V and Mark VI turbine control systems.))

I don't recall exactly, but I think a GE proprietary application/service called CIMBRIDGE is how the HMI passes information between CIMPLICITY and the Mark VI (via the UDH and EGD). TCI is primarily responsible for alarms/events. So, this would explain how CIMPLICITY is able to display data/values and send commands when the Alarm Display/Window isn't working. But, again, the documentation for GE HMIs is poor, and I don't know if my recollection is fully correct, or not.

There's something fundamentally amiss; have you checked F:\CONFIG.DAT to see if it's correct? Did you try to use a back-up from another HMI to get this new one running?

Troubleshooting and resolving issues like this are difficult, at best, and sometimes very nearly impossible to solve via World Wide Web forums. We don't know precisely what was done and what the results were, and quite often when I visit sites I find that what was told in emails/phone calls was not what was done (usually more frantic attempts were not mentioned in emails/phone calls). When troubleshooting a problem like this, it's critical that every step taken--and the results of each step--be written down so that when you get to a point where you need to get other people involved you have a written list of actions and results which can be used. Too many times, things get forgotten, or when something is done that needs to be undone it gets forgotten--and it's simple things like this that can lead to lots of wasted hours.

GE Speedtronic HMIs are poorly documented, and there are many perversions of them, and each one requires some slightly different tweaks to make it work correctly.

I would also suggest that you have not posted the most recent TCI.LOG file, because if you've re-started the HMI, then I would expect to see more recent dates and either an indication of what failed or that something stopped TCI.

You can try opening the Control Panel Services Applet and making sure that the TCI Service is marked as START and is running, not stopped.

I have been told of some VLAN configurations that used MAC addresses of Ethernet NIC cards to display and monitor communications (yet another undocumented perversion). If you're using a different CPU, are you also using a different Ethernet NIC card/port for UDH communications? Does the HMI have VLAN communication displays showing the status of communications/ports?

In fact, I'm kind of confused about whether you're currently using the original HMI CPU, or if you're using a spare computer (which you've mentioned).

As for taking this discussion off-line via private emails, this is an open forum, and many people read and follow these threads, so it's important for everyone to know what is being said and done. Since we can't post images to control.com, what some have done in the past is to upload images to a free web-hosting service (tinypic.com is one of many) and then post the URL (link) to the image location. That way anyone can view the images and follow along in the troubleshooting/resolution.

But, failing these things it's time to consider getting a knowledgeable person to site to help resolve the issue. And, it would be really, Really, REALLY, <b>REALLY</b> nice if you would write back to let us know what the resolution to the problem was when it's finally resolved (either by support provided by respondents to this control.com posting, or by someone coming to site to help resolve the problem).

 

We have checked the configuration of CIMPLICITY AMV Object and found normal. We have also checked F:/Config.Config.Dat file, and found normal.

The TCI.log file which we shared with you is the most updated file because after the event occurrence it is not being updating even after restarting the HMI. And the TCI service is selected automatic and started as well.

Coming towards UDH communication we have found that UDH primary network connection is not sending and receiving the bytes. Going through the history of our issue when this event happened, we only replaced the mother board of the same HMI. we did not mark the NIC cards and their respective slots. So, after replacing motherboard we connected NIC cards as well in the board but with random order. UDH backup and UDH (virtual) network connections are working normal.

 

Thanks MIKEVI for the support.

We have checked the TCI service and it is selected automatic and started as well.

We have also checked TCI Site tab and it is referencing the correct path for the site file E:/Site and the the folder also contains the config.dat file.

In command prompt we have typed "net start tci" and it returned the message TCI service is starting, and then a second line saying the TCI service was started successfully.

We also removed the TCI license dongle and restarted the PC, "TCCI encountered error and needs to close" message appeared after booting.

 

Dear Wajid29,

unfortunately without being able to visit your site and have access the HMI, I think I am out of ideas at this point.

I am really at a loss to understand why your TCI service is not operating. Again just to go over what happened. The machine was running slow, and when rebooted some indication lead you to determine the motherboard had failed. You replaced the motherboard with another identical unit, using the same disk drives. I will assume then that all files that were on the original hard drives remained the same. You mentioned later that you found some of your Ethernet cables not installed properly. But if you have data displaying on the Cimplicity screens then we can assume the HMI is communicating with the MKVI controller.

But it still appears that something is wrong with the TCI service. If this service is not running properly then you will not see alarms displayed in the alarm window, and the TCI alarm and event viewer will not operate properly. The fact that no new TCI.log files are being created tells me that for some reason TCI is not running properly, or is not accessing the proper folders. But you say when you perform a "net start TCI" command that it returns a message that TCI is starting, then another message indicating it has started. What I do find interesting IS that if the service was starting normally on its own, then when you type the command "net start TCI", you should have seen a message that says "the requested service is already running". But you indicate that you "In command prompt we have typed "net start tci" and it returned the message TCI service is starting, and then a second line saying the TCI service was started
successfully." But if the service was already running normally as it should have been then you would not see the message you did.

But without being able to "see" what is happening on the machine I find it difficult to make any further suggestions that I feel would be helpful. As CSA has to say at times, it may be time to try getting a knowledgeable person to visit your site to assist. Let me know if you have any further information or comments that might be helpful.

 

CuriousOne,

>This is nothing new with alarm manager snap-in. You must
>re-establish the connection within alarm manager. It must be
>done within Cimplicity in edit mode. The snap-in has special
>properties which must be accessed with Cimplicity in edit
>mode.

Can you please provide some specific details about the "alarm manager snap-in" and how to access it CIMEDIT? We presume you're referring to the AMV Alarm Object which is only accessible via CIMEDIT, and Wajid29 assures us it's configured correctly--which we presume he's doing by checking the configuration of the CCR HMI using CIMEDIT.

Thanks!

 

MIKEVI & Wajid29,

It seems the teaming of the two NICs for the UDH is not working. My experience is that GE typically uses the on-board Ethernet NIC as the UDH Primary NIC. Could it be that the new motherboard's on-board NIC MAC address needs to be entered in the teaming application? I don't think the slot has anything to with the issue, but the UDH teaming application may be looking for the wrong NIC based on the MAC address of the old motherboard's on-board NIC.

Wajid29 has indicated the Primary UDH is not working. Maybe it's a NIC teaming issue and for some strange reason TCI needs to establish communication via the UDH Primary NIC first.?.?.?

That's the extent of my ability to contribute. I wish we were getting better TCI.log file feedback. A new TCI.log file should be created EVERY time TCI starts--manually or automatically. Meaning if the HMI (MS-Windows) is re-started OR the command line utility NET is used to start TCI a new TCI.log file should be created with the time/date it was started. Could the TCI.log file attribute be marked Read-Only and locked?

That's my last contribution; I'm flat out of ideas and suggestions. I still believe it's something fundamentally wrong--and simple. I just wish the .hmb file hadn't been mucked with, but that's just my personal preference and probably has nothing to do with this problem.

Looking forward to hearing the solution!!!

 

I will not go into the details of Cimplicity screen design and the use of variables. The problems with AMV is usually only revealed when one is designing screens for "Viewers" vs "Servers".

Since the "local_project" variable is only available to the "server", a "viewer" must establish a connection to the "server" with the proper project name.

However; When utilizing multiple project "servers" residing over multiple turbines sharing information to a Single "control room" the issue is the same.

I will not entertain the issues that GE TA personnel had with improper implementation of RAID configuration.

I can only suggest the following:

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!!

Cimplicity is very powerful. I set variables with Visual Basic code supported by Cimplicity. But I cannot troubleshoot a screen with the information provided in this thread.