ERROR OPENING TOOLBOXST

K

Thread Starter

Kwaku

Hello everyone

I would be very glad if anyone can clarify the following issues for me:

1) Can the GT1_SVR which has the dongle be rebooted whiles the unit is online?

2) Lately,whenever i open the toolboxST and i try to open the G1 to see the logic for troubleshooting,an error message appears which reads : " error creating window handler" and mostly the toolboxST closes by itself.What can cause this problem and what can be done?.Can rebooting the GT1_SVR solve this issue?

3) Does one need to install a controlST software on a computer before he can use it as an HMI viewer? Does the computer has to come from GE or you can buy your own computer from the market.

Thank you.
 
Kwaku,

Greetings!

1) Yes. GE HMIs do not participate in or perform any critical control and protection functions; that's all done by the Speedtronic turbine control panel independently of the HMI. Think of the HMI as a "window" into what's going on in the turbine control panel, and, of course, as the alarm annunciator for the Speedtronic. While software on the HMI can be used to configure and trend and force values in the Speedtronic turbine control panel rebooting it will have no effect on turbine control or protection.

2) GE turbine control software is not the best-behaved Windows software; it's unfortunate, but true. The most likely cause of problems like this are errant bits of code ("remanants") still running after an unexpected- or improper shutdown (don't ask what an improper shutdown is, because the definition GE will give you is, "Whatever you did to cause this problem"; there is no definition of a proper shutdown so anything that causes a "problem" is therefore improper). So, yes; rebooting will likely help the problem.

If this is a panel-mounted HMI (usually manufactured by Advantech), unexpected- or improper shutdowns of GE software applications usually occur because there is insufficient memory installed (capacity) and when CIMPLICITY is running and someone has ToolboxST open, with logic forcing and Trending, well, the panel-mounted HMI just gets overwhelmed. Well-written software would be able to shutdown all operations when something like this occurs, but, well, 'nuff said about that.

3) I believe these days that ControlST requires a dongle.... So, I don't believe one can just load it on a PC and have it run. I know CIMPLICITY requires a license, and newer versions (beginning with 7.n, I believe) require a dongle, also.

As for using a non-GE-supplied PC, do so at your own peril. All PCs are not created equally, and GE has a habit of writing applications for specific versions of BIOS routines that are only provided on certain PCs. So, it may--or may not--work. You just can't count on GE to support you if it doesn't. And, in all fairness, one shouldn't. It would be prohibitively expensive for GE to test their software to work on every Wintel (MS Windows OS running on Intel microprocessors) PC out there. If you think their stuff is expensive, just think about the cost if they had to procure and test their software on every PC, or support every PC. (There's a scary thought!)
 
Dear CSA,

Thanks a million for helping me clear my confused mind. However am still not very clear about my third question so let me put it this way:

Does an hmi viewer has both controlST and cimplicity installed on it?

If yes then what is the difference between an hmi server and an hmi viewer in terms of the softwares installed on them and the scope of their functionality?

Thank you.
 
Kwaku,

YOU asked about a viewer with ControlST. You haven't provide a lot of details about the exact type of Speedtronic and HMI you are working on....

Previous versions of CIMPLICITY used a special AMV object to display alarms. Newer versions of CIMPLICITY don't; they use the AlarmST Alarm Viewer, which requires ControlST.

To be perfectly honest, I don't try to keep up with all the (per)versions of software on all the GE HIMs. They don't document them and why should I--or anyone for that matter. It's GE's job to document the software, and if they did it wouldn't be such a kludge because they would quickly realize what a kludge it is if they had to document it. (I used to try to document the software, but the horror stories I could tell you are just not believable. So I won't--tell you, or try to document their HMIs ever again.)

That leaves you without much of an answer, though.

Sorry. Two out three questions answered ain't bad though where I come from.

Perhaps if you post more details some other responder can be of more help.

Best of luck.

My real answer was (and still is): Unless you have unlimited time (which means money), it's probably not worth it. Even if someone responds here that they were successful, don't hold your breath waiting for them to provide the details you would need--and the support--to be successful with your attempt. You will turn blue and die before you get what you need, and your supervisor will kill the project before you get it to work--and hell will freeze before he lets you try something similar again. Even if you are 100% positive you can successfully complete the task in the allotted time.

And your co-workers will forever snicker and talk about you behind your back.

You have been warned.
 
Dear CSA,
Thanks a lot for the reply. I rebooted the GT1_SVR HMI whiles the unit is online successfully without any trips and the toolboxST error problem have been resolved.

My next issue is:

Our generator protection system trip matrix is such that 87T (Main transformer differential protection) and 64TREF (Main transformer restricted earth protection) only opens the line breaker (52L), opens the generator breaker (52G) and gives an alarm without tripping the turbine.

However, whenever 87T or 64TREF operates, the turbine trips to cooldown which in actual fact should be at FSNL.

Interrogation of the trip log reveals that L2TV appears just before the trigger, and L4T just after the trigger. I have gone through every single rung and signal that feeds into L4T but none comes from the Generator control panel except 86TG.

A loop check from the TREG/PPRO card to the generator control panel confirms that the only trip signal comes from two lockouts that should in fact trip the turbine whenever there is a generator problem.

After all the loop checks, it was revealed that 87T and 64TREF should in fact not trip the turbine.

My question then is: could it be that FSR is driven so low after both breakers trip such that the unit looses flame?

Is it that the turbine cannot stand load rejection?

What can be done to rectify this problem?

Our unit is frame 9E and the controller is Mark VIe.

Thank you.
 
Kwaku,

This question is not directed simply at you:

Why do people ask why their turbine trips >>WITHOUT<< providing a chronological list of Process Alarms when the turbine trips?

Seriously. If one doesn't use the alarm list to troubleshoot a problem--especially a turbine trip--then one is really just guessing at what the problem may be. (Is the alarm printer at your site connected to the HMI, loaded with paper and a good ribbon, and on-line printing alarms as they occur? Or, can you retrieve a list of alarms at the time of the trip from the HMI alarm "log"?)

It's extremely sad that GE doesn't do a better job of blocking erroneous alarms after a trip, but that doesn't relieve people from learning to "read" an alarm list after a trip and determine what was the actual cause of the trip (even it was a true "loss of flame" due to lack of fuel) and ignore the erroneous alarms.

I suspect, Kwaku, from your post that the unit may be tripping on loss of flame (because without the chronological alarm list it's only a GUESS!). And, yes--the turbine should be able to withstand a load rejection (as it's called) and remain at FSNL without tripping on loss of flame.

Typically, during commissioning load rejection tests are done--especially if there is a contractual requirement for the unit to remain at FSNL on a breaker open event and be capable of resynchronization very quickly. (Though one has to wonder how quickly it can be determined that such an event was only a nuisance or erroneous so the breaker can be re-closed without damaging the generator or the transformer or the turbine????)

You also didn't say if the turbine has conventional or DLN combustors. Keeping a turbine with DLN combustors running at FSNL after a load rejection can be difficult, especially from high loads (i.e., from Premix Steady State).

So, to get more help provide a chronological list of alarms (including times to the millisecond) from a few seconds before the trip to approximately 30 seconds after the trip. And tell us what fuel(s) the turbine operates on, and what kind of combustors the turbine has.

I will caution you that if the problem is loss of flame because of lack of tuning of the Minimum FSR values you would do best to get someone knowledgeable to site to help with tuning--and be prepared for a few trips. From load.

And if the unit has DLN combustors the task will be more difficult.

And if the unit operates on both gas and liquid fuels, be prepared for even more tuning and tripping.

Sorry, but that's the truth. And again: We are just guessing because we don't have a chronological list of alarms. And there are some things which you haven't told us.

(By the way, this issue should really be opened in a separate post/thread....)
 
Top