hi all;

please i need your experience. i need to add event or i have signal for example L4DLNT;
i find the signal in toolbox so in pins i activate EVent

after that i will validate and build and download the application and before i put into data base; i will open the hmb file to put and get from data base; when i finish istop the tci and restart the cimplicity

please can you help me is correct these procedure or no?

other case: every trip i have ground alarm 1ALM BATTERY 125VDC GROUND AND other alarm is: ALM ALARM XMIT SUSPENDED. CPU SWITCHED. Our engineers check can not find what is the problem of the ground if the problem is in the PDM or in some card (truly....)

please can you help me

 

Dear Technical, your procedure sounds almost correct.

If you are making changes to logic only, that do not involve making new signals, alarms, or events that need to be declared to cimplicity or TCI then your procedure should be to:

Validate all
Build
Download application code
Save the .m6b file.

If you are making changes that introduce a new signal, event, alarm, or triplog signal then you should:

Validate all for the .m6b
Device->put into database full
Build
Download application code
save the .m6b file
open the .hmb file for the server you are at.
validate
put to database
get from database
build
save the .hmb
net stop tci
open cimplicity workbench project for server you are working at
perform configuration update of project
net start tci or reboot the work station.

You will need to perform this same procedure at each workstation individually so they all have the new alarm/event list etc.

This quick procedure assumes you have done this before, and understand the ramifications of a MKVI download, and stopping of TCI services and how that can affect other viewers and communications to other devices if so configured.

The two alarms you mention sound as if they could be due to some device that is partially grounded and is causing a problem during a trip or shutdown. Without looking at your application code one can only assume that your alarms are correctly configured. Assuming they are then I would suggest using a high speed trend of your DC voltage split during a run/shutdown and or trip. Is your DC split balanced during a normal run? Is it normal during a shutdown? When does it indicate a ground? If your voltage is low or unbalanced even when not in alarm then you must look at all devices that could be partially grounded, but not enough to cause the alarm all the time. There have been quite a few posts about battery grounds and ways to diagnose them. More information from you as to what you have done so far to investigate the problem would be helpful.

 

MIKEVI,

Quick question: Why is it necessary to 'Validate' the .hmb file and then 'Put to the Database' from the .hmb file, and then 'Get from the Database' from the .hmb file? Nothing has changed in the .hmb file--only in the .m6b file. It's always seemed to me to be an unnecessary step--and one that could, potentially, cause problems. The intent is to get the changes from the .m6b file into the Database, and then get them into the .hmb rile, and then into the CIMPLICITY project, and then into HMI RAM. I understand the ;Put' from the .m6b file, but I don't understand the 'Validat'-'Put-'Get' from the .hmb file.

And good on you, mate, for remembering to mention this!!!:

> You will need to perform this same procedure at each workstation
> individually so they all have the new alarm/event list etc.

I believe L4DLNT is a composite" of several DLN trips--each of which should be individually alarmed. So, when any of the individual DLN-related trips occurs, L4DLNT should go to a logic "1"--but the actual cause of the trip should be alarmed and time-tagged. L4DLNT may not change state until the next scan, and it really doesn't indicate WHICH specific condition caused L4DLNT to pick up.

If the individual conditions causing L4DLNT to pick up are NOT alarming, then they could be made into SOEs using the procedure above.

 

very thank's for your information.

for the second question i will investigate and i will reply you ok?

 

now i need your experience.
i have MARK VI and how i can find my cards of markvi types and versions?

it's for future spare parts.

 

CSA

my question is correct. every trip on my turbine ms7001EA i trip with:

ALM GAS XFER PURGE VALVE FAILURE TO OPEN

ALM XFER PURG VLV FAIL TO OPEN - LOWER LOAD

ALM DLN SYSTEM TROUBLE AUTO SHUTDOWN

so i need to activate some signal to more understand what is the real trip.

i have activate L4DLNT; and limit switch purge valve of DLN to event when i make all procedure (validate...build....and open hmb file to put and get into data base...stop and restart tci).

when i cheek alarm and event i look QXX000 SO THE EVENT IS NOT CORRECT WHEN I HAVE ACTIVATE

SO CSA PLEASE CAN YOU HELP ME?

 

Dear CSA, I shall endeavor to answer your questions correctly.

Why is it necessary to 'Validate' the .hmb file?

I typically perform a "validate" of any file I open, prior to making any changes. I don't want to assume that the file was ok prior to me making changes, so a validate at least tells me toolbox is ok with the file and if a validate fails after I make changes it is something I did incorrectly and not a problem that was there prior.

Why is it necessary to 'Put to the Database' from the .hmb file, and then 'Get from the Database' from the .hmb file?

Technically the "put" step of the .hmb is not necessary in the case that the poster "technical" made a signal from the .m6b an event. To only do the absolute necessary steps in his case, a put to the database from the .m6b file and doing a get from the database of the .hmb file should have been all that was needed to make this change "seen" by the .hmb file, besides building etc.

I wish I had the time and place to post a correct and full procedure for each of these situations. But unfortunately it is tough to answer all questions to the full degree.

For you technical, it seems that you have more alarms every time you trip? Your post began saying that:

"every trip i have ground alarm 1ALM BATTERY 125VDC GROUND AND other alarm is: ALM ALARM XMIT SUSPENDED. CPU SWITCHED. Our engineers check can not find what is the problem of the ground if the problem is in the PDM or in some card (truly....)"

And now you say:
"my question is correct. every trip on my turbine ms7001EA i trip with:

ALM GAS XFER PURGE VALVE FAILURE TO OPEN

ALM XFER PURG VLV FAIL TO OPEN - LOWER LOAD

ALM DLN SYSTEM TROUBLE AUTO SHUTDOWN"

So it seems you have several problems that may have existed for some time.

My suggestion is that you examine each, one at a time. I suggest you use all documentation, control spec, device summary, prints etc. to best understand what is occurring and why.

In the case of the purge valves do you understand the proper operation of these valves?

Have you read the control spec and device summary to understand what devices are needed to make this system operate properly?

Have you tested the purge valves to see what the opening time is? What the closing time is?

When the alarms occur what is the unit doing?

I can "assume" that you are operating a 7EA DLN 1 machine, possibly dual fuel, but maybe single fuel. This alarm "typically" occurs during a DLN transfer from lean-lean mode into premix mode. During a DLN transfer, the transfer purge valves that are purging the transfer nozzles with CDP air, close to allow the transfer fuel valve to open. Once the unit has transferred into pre-mix mode, the transfer purge valves SLOWLY open to begin purging the nozzles again.
Do you know why this has to be SLOW?

IF both of the purge valves do not open after a certain time delay then typically you will get an alarm, and after a further time delay you may get a trip or a load runback.
I think if you study the operation of the valves, and look closely at the logic, you will find your problem. And you will gain a lot more knowledge than at least myself can offer here.
Many of us can suggest things and ideas here, but you understanding your system and asking "key" questions has more value for you and your company.

Please write back, give us more information about this problem with the purge valves. How long has this been happening? When? What have you done? What things could cause this? I look forward to your further posts.

 

MIKEVI,

Thanks very much for the information. Your practice of 'Validate'ing a file before making any changes to make sure Toolbox has no issue(s) with the file is a good idea. And, 'Validate'ing again after making the changes before 'Build'ing is also a good idea. (Actually, I think some versions of Toolbox won't 'Build' until a 'Validate' is performed without errors; some even prompt to 'Validate' first if trying to 'Build' without a 'Validate'ion without errors.)

I agree--it's extremely difficult to list only the required steps for every different type of modification--and because there are so many types of modifications, and so many different versions of Toolbox, CIMPLICITY and TCI it's even harder and more difficult than it should be.

It seems that "technical" didn't perform the steps properly, or didn't resolve all errors/warnings. Or, possibly he did it one HMI but not on all HMIs, which might explain the erroneous alarm message (if I understand what he's trying to say about that).

I think there's a problem with the understanding of the word 'trip' as used by GE heavy duty gas turbine control systems. 'Trip' means an emergency shutdown--by closing the fuel stop valve(s) VERY quickly and causing a loss of flame and an opening of the generator breaker. The alarms "technical" is listing are <b><i>shutdowns</b></i>--not trips. A shutdown is an orderly reduction in load that results in a breaker opening and then a normal fired shutdown/deceleration to Cooldown (ratchet). So, while he keeps writing 'trip' it seems he means 'shutdown.' (I hope he means shutdown.)

The adjustment of the limit switches on the gas transfer purge valves can be problematic. I've seen them work properly during cold checks (when the purge piping is at ambient temperature), but not when the purge piping is hot when the turbine is running and axial compressor discharge air is or has been flowing through the piping/purge valves. They can 'bind' and either the valves don't fully open or the adjustment of the open limit switches isn't correct for the hot valve condition. Sometimes all that's necessary is to adjust the open limit switches so that they close when the valve is about 97-99% open--instead of when they're 99-100% open. It's a small--but significant--difference in limit switch adjustment, but it has virtually no change in air flow through the valves.

Also, sometimes the adjustment of the needle valve(s) in the purge valve actuator exhaust can be just a little too closed for a hot condition, so opening them slightly (very slightly) will let the valves open a little faster--but as MIKEVI says it's important that they not open too quickly, because the sudden increase in air flowing through the transfer nozzles will cause problems with the secondary diffusion flame which can result in a loss of flame trip.

Thanks, again, to MIKEVI for taking the time to answer my questions--it's very much appreciated. Again, I agree--it's very difficult to try to list every step for every type of possible modification and version of Toolbox, CIMPLICITY and TCI--it's just virtually impossible.

And, to "technical" please confirm whether or not the turbine is "tripping" or "shutting down." If the turbine is shutting down--and NOT tripping--then L4DLNT will not change state when you receive the alarms.

As for the ground alarms on "shutdown", you're going to have to tell us exactly when the battery ground alarm occurs. At the instant the "STOP" is initiated and accepted and becomes active, or when the generator breaker opens, or when the unit loses flame or when the unit reaches zero speed? How long does the battery ground alarm remain a logic "1" (active) before it resets? When does it reset (turn to logic "0")--precisely? As MIKEVI suggested you need to be monitoring the positive and negative voltages during the shutdown with Trender and let us know what the voltage levels are before, during and after the alarm.

 

To get a list of boards, open Toolbox and click on View > Reports > I/O Module Report.

 

hi,

> To get a list of boards, open Toolbox and click on View > Reports > I/O Module Report.

yes i m with you but you cannot now the hardware catalog of card for example: IS200VTURH1BAC

because in this case you now only the Device Firmware Revision

so my question is how to now the last 2 letters of each card?

for this procedure is good but not complete. to know what is the version of the card is there other procedure?

 

Dear Technical,

the major revision, for the VTUR example below is a "H1B" which can be seen from the toolbox application, or by looking at the front of the card, or by looking at the edge of the card with it removed. The last 2 digits are the "minor" revision and to my knowledge can only be seen by removing the card from the rack and looking at the edge of the card.

I am not sure why you are concerned with the minor revision. When replacing a card you only need to be concerned with the "major" revision of the card. The card numbers do not indicate what level of "firmware" is in the card. Firmware is only viewable from the toolbox application that I am aware of.

 

Dear MIKEVI;

i have give you example for VTUR. but for last my investigation, i have change VCMI card. for this turbine all VCMi firmware is VCMI-040300C. but for my card i have install VCMI-040200C.

so my VCMI card version is IS200VCMIH2CBA. and to find the two last letter (BA) it's from TELNET and TSM command. so when you enter you can get all ROM SERIAL, BARCODE, HARDWARE CATALOG for all CARD installed on MARKVI but except UCV card, without removing the card from the rack and looking at the edge of the card.

this all action and intervention for MARKVI is because in our plant there was 10 turbines and for part list there is in stock zero and to make order for all card ok?

 

Dear Technical,

I guess maybe I am a little confused. I am not aware of why you would need to identify the last 2 letters of the part number of any card as it does not really help in identifying firmware versions. If you are trying to purchase spare cards that will work in all machines then you really just need to be aware of the "MAJOR" revision.

Now lets take the case of your VCMI card. Most of your machines are using a major revision of H2B I will bet. Due to a particular component being obsoleted by a certain electronics manufacturer GE stopped producing the H2B and began producing the H2C. This occurred in 2006 and was covered in service bulletin #TB25036

"The obsolescence of a key hardware component by all it's manufacturers has halted production of IS215VCMIH#A and IS215VCMIH#B Bus Master Controller cards used in various quantities in Mark VI systems for all applications. A replacement, the IS215VCMIH#C (where "#" denotes either the group 1 or group 2 versions of the card), has been designed, tested, and validated for use as a direct replacement for either the H#A or H#B types. Because of the differences in the internal hardware interface, new firmware is required when installing the IS215VCMIH#C, including a new .tre file containing its configuration. A single product CD DS221VCMI V04.01.00 and instructions are included with the new card."

So you should have received a CD with the updated firmware to be installed when installing a new VCMI card with a newer MAJOR revision.

The controller card is another card that has progressed from what I suspect you are using a UCVE which is now obsolete and replaced by the UCVG or UCVH. Lastly the VPRO assemblies have also recently(within the last few years) changed revision and the older units are not available from the OEM as NEW.

Anyway if you are trying to purchase cards for spare stock then you really just need to pay attention to the MAJOR revision. And in some cases you will not be able to purchase a card that is identical to what you have installed, at least not new from the OEM. You may be able to purchase a remanufactured card either from the OEM or an aftermarket supplier that has the same MAJOR revision of what you have installed in your 10 machines.

I hope this helps.

 

hi All

i need to synchronise MARK6 with DCS (Time Clock; NTP).

is there a procedure to do it?????

 

rauofelect,

Your question is not clear. Is the DCS already connected to a time signal (GPS; IRIG-B; ???)? Or is the GE Mark VI HMI already connected to a time signal (GPS; IRIG-B; ???)?

Have you looked in the HMI manual provided with the HMI? It's usually a .pdf file on the HMI in a Documentation directory. Unfortunately, GE puts all the manuals in there by GE publication number--and unless you know what publication you're looking for you have to open every one to find the one you want. (HINT: Do this once for every file, writing down the publication's name; close the publication, then right-click on the file name and click on 'Change' and you can then change the file name to the name of the publication--and you'll never have to open every file again! Just once is all it takes!)

Time synchronization for Mark VI is done via a GE Mark VI HMI. A time card is installed in the HMI, connected to a time source, and then NTP is enabled. If there are multiple HMIs, one is chosen to the be the NTP Server, and the other HMIs are set to be HMI Clients. The NPT Server broadcasts the time onto the UDH and then any Mark VI on the UDH--and the other HMIs (which are also on the UDH) get their time signals from the NTP Server. The Mark VIs must be configured to accept a time signal from a NTP Server (that's likely described briefly in the Mark VI System Guide, GEH-6421). The Mark VI configuration is done via Toolbox, so you can look in the Toolbox Help for more information, also.

I think at some time there was also a publication dedicated solely to Time Synchronization, but I can't recall.

If the DCS or one of the GE Mark VI HMIs already has a time card connected to a time source (usually with a coaxial cable), you can put a tee connector on the BNC connector and run another coaxial cable over to the time synch card/module/input of the DCS and set up the DCS to match the time signal being used as the source for the Mark VIs/HMIs.

Some GE Mark VI HMIs use a time server connected to Ethernet to get the time signal into the HMI, and then NTP Server works as above. If the DCS can accept a Ethernet-based time signal you can then connect it to the time server and set up the DCS to match the time signal coming from the time server.

Or, if the DCS already has a time source it probably comes from a time source or time server which could be connected to a GE Mark VI HMI (Ethernet or BNC as appropriate) and the GE Mark VI Ntp Server can be configured and the Mark VI can then be configured using Toolbox.

It's really not very difficult. The thing to remember to do is: MAKE BACK-UPS OF ANY GE MARK VI HMI OR MARK VI TOOLBOX CONFIGURATION THAT YOU CHANGE <b> >>>BEFORE<< </b> YOU CHANGE ANY FILE/CONFIGURATION. So, you can recover. (You already have back-ups, right. Right? RIGHT??? That's okay; make new ones anyway!)

It's logical procedure, that's not documented by GE anywhere in any list or step-by-step procedure the publicly published. (Sad, but true.) You just need to research both "ends" (the DCS and the Mark VI/HMI) and the time signal you'll be using (existing or new) and then develop your own procedure, and then use your procedure <i><b>after making back-ups.</i></b> If you have questions about your procedure or the equipment or configuration, we're here to help.

But you need to be clearer about what is existing and what's not.

(By the way, it's also possible to just use a single GE Mark VI HMI without a time source as an NTP Server for the Mark VI(s), and then connect it to the DCS (using the PDH) and if the DCS is capable of being an NTP Client configure it to follow the NTP Server. The NTP Server will just get the time from the HMI's CPU clock, which are usually pretty reliable, but may require adjustment from time to time. So, it's not even technically required to have a time source for an NTP Server--it can just get it's time signal from the PC CPU clock. At least the DCS and the GE Mark VI HMI(s) and the Mark VI(s) would all be synchronized.)

Hope this helps!

 

Dear Raoufelect,

May I suggest that you start a new thread for your question? That way when someone like me replies to your post it will be searchable later to others who might have the same type of question. When you try and post a new question to an old thread like this it makes the search feature less useful to others at a later date.

So please start a new thread in the power generation topic area, with something like "Please help with time synchronization or NTP for a MKVI HMI server to DCS?"

I will do my best to post an answer to your question then.