I have a customer with a Frame 6B with Mk-V "B" panel. They need to add more 4-20 ma inputs to <Q> but have already used all the inputs on the <R> TBQC card. Is it possible to add in the field an additional TBQC (or maybe TBQF) card into <S> core?

I believe there will be hardware and software changes required. Is there any way to get a list of hardware required? Additional software files needed? Changes to existing software files? And lastly, how do you get the IO_Configurator to recognize the additional card for configuration?

Thanks for your help.
Walt Robinson
[email protected]

 

waltrobinson,

There are possible options, but it's not very easy. If there's an open I/O terminal board location on <S> (one of the four smaller terminal boards below the main section of the core), it's possible, but it may involve replacing three boards (one in each of <R>, <S> and <T>). If there's a spare location in <R>, <S> and <T> and a spare I/O terminal board location on <S>, it's also possible.

But, it's going to take an I/O terminal board (which will likely be mounted on <S>, as you've noted), and either a spare location in <R>, <S> and <T>, or the replacement of an existing card in each of <R>, <S> and <T>, a compatible PROMset for the cards to be installed in <R>, <S> and <T>, ribbon cables to connect the card to the I/O terminal board, and power cables to connect the card to the TCPS cards in each of <R>, <S> and <T>. There may also be a need for a new ribbon cable or cables to connect the new card in <R>, <S> and <T> to the SDCC/SLCC card in Loc. 1 of each of <R>, <S> and <T>.

The new PROMset would come with a card configuration file which would be installed in the UNITn/PROM subdirectoy, and after editing the I/O Configurator definition file the I/O Configurator would then be able to recognize and configure the new card and its I/O.

But, this is really a LOT of work and hardware.

<C> has the ability to handle some 4-20 mA inputs, and if the ones you're trying to add are not critical, could they be added to <C>? Even if a new card and I/O terminal board had to be added to <C>? Or, could some of the other existing 4-20 mA inputs which aren't critical be relocated to <C> to make room for the new inputs which are critical (if they are)?

This is really the Achilles heel of the Mark V--it has limited I/O update capabilities. Probably one of the best resources for Mark V cards and PROMs and cables and such is one of the control.com advertisers: GTC, www.gasturbinecontrols.com. I don't think GE would do anything other than force you to buy either a Mark V "Migration/Life Extension" (which is a waste of money), or a Mark VIe upgrade, which takes a lot of time when GE does it and can be a real waste of time (and money)--but you end up with current, state-of-the-art hardware which should be good for a couple of decades, if not longer.

So, the answer is: it's likely possible, but it would take a significant amount of review and gathering of cards, PROMs, cables, files and engineering and commissioning work.

Hope this helps!

 

Thanks for your wisdom. I had a strong feeling that, since the Mk-V is neither intuitive, obvious, straight forward or easy that things would not be any of those.

This turbine is what we used to call an MA (manufacturing associate) unit out of Europe and whomever did the Mk-V did not do me any favors. Virtually all the inputs that are normally handled by pressure switches (AC & DC LO pump start, inlet air filter dp alarms, etc) are done with transmitters and comparators in the Mk-V. All the inputs in both <C> and <Q> are used. Top that up with the fact that the LONGNAME.DAT file is virtually empty, the TC2K file is empty and it makes working on this unit a joy (sarcasm alert).

One of my paths (and I think my best one) is to convince the customer to allow us to replace pressure transmitters with switches to be used in sequencing. (This should not be an issue as the unit has a <QD2> core. I think the hard part will be convincing the customer to "give up" readings that he has had available to him for years.

I can do limited moving of <Q> inputs to <C> but only a couple of points. I do plan to use the two inputs VDC3 & VDC4 with the berg jumpers to handle two of my field powered 4-20 inputs. Other than that, it's either talk my way into more points or start looking at cards per your comments.

Again, Thanks for your help.

 

waltrobinson,

You're most welcome, and thank you for the feedback. Yes; there is a very strong movement towards replacing pressure switches with transmitters--and unless there are multiple transmitters with proper sequencing this can lead to a very false sense of security. (I know of one site that removed all the L.O. pressure switches from the system--at the Acc. Gage Cabinet and at the collector end of the generator) and replaced them all with a single pressure transmitter and comparator. Yep; and was VERY upset when the unit tripped and couldn't be started when the pressure transmitter failed and they didn't have a spare to replace it. In fact, they even forced the logic to start and run the unit (it was out of warranty when they did this, and yet complained that it was the Mark V that was preventing the unit from starting).

Another problem with having all pressures input to the control system by transmitter is that it usually means no one ever does rounds any more, which means leaks (oil leaks; fuel leaks; cooling water leaks; etc.) are not usually found before it's too late (and the unit tripped or worse).

I've even run across field service personnel who intentionally deleted TC2KREPT.TXT because they couldn't be bothered with editing it to make it correct. And, incomplete LONGNAME.DAT files are the rule rather than the exception, though from the sounds of it yours is woefully inadequate.

I don't have access to GEH-6195 at this writing, and you should look for the TCQF option (if I recall correctly) to see what additional I/O capability it might provide. I think it offered some additional T/C and mA inputs, but it's going to require cards and cables and the card configuration file.

Is there any chance that some non-critical I/O could be relocated to a "RTU" type set-up connected to the HMI, and then put into the CDB via MODBUS? There are some very inexpensive MODBUS RTU sensors/systems which could be very useful--as long as the I/O is non-critical.

Best of luck--and hope this helps!

As for being the Mark V being non-intuitive, I'm reminded of a story a colleague told me about the designers of the Mark V responding to similar criticisms by saying, "Any idiot can edit an ASCII text file!" (Most of them were C/C+ programmers, by the way--not field service people--and the implication was that everything one needed to know about the Mark V could be gleaned from the ASCII text files provided with it.) And those same programmers and their leaders were reported to say (defensively), "The Mark V satisfies 95% of the people who use it!" To which I would have responded, "The Mark V is--at best--only 95% satisfying to those who use it."

 

Thanks again for your comments. Always good. One note, anytime I think of difficulties with the Mk-V my mind goes back to (early days of my career) trying to change sequencing in a fuel regulator unit and those Agastat timers. 2HR never worked worth a damn.

Back to my Mk-V issue, if I could ask just one more question . . .

One way I can help myself with this input shortage is to bring the (new) CEMs data (NOx, CO & O2) into the Mk-V via modbus. That would save considerable analog inputs but the unit has only one HMI and I understand that its modbus connection is being used to send Mk-V data to the plant DCS. Can a second modbus input be setup in an HMI to feed data (as a modbus slave) into the Mk-V? If so, how is it configured as the MODBUS.DAT file is used for the main modbus connection.

Thanks again and have a great New Year.
Walt

 

Walt,

Fuel regulator, eh? That brings back fond memories! I upgraded two two-shaft fuel regulator systems to Mark IVs "back in the day", and that was quite an experience. One unit had to continue to run while we upgraded the other unit--and disconnecting them without tripping the running unit was quite a challenge, and we succeeded at not tripping the running unit! I still remember how much "real estate" was consumed by the HGA relays, alone--and ALL the wiring (which was neatly tied into bundles with waxed string). There was <b>SO MUCH</b> wiring--and <b>SO MANY</b> relays! And we hand-traced almost every wire while demoing the first unit; I was on my belly for a couple of weeks reaching down into the morass of wiring and dead bugs. I do remember the plant technicians rejoicing about getting rid of the Agastat timers! They could care less about anything else--but they kept commenting on how happy they were to be getting rid of those timers!

Anyway, MODBUS would be the best option in this case--perhaps the only option, really. The original Mark V <I> operator interfaces all had the ability to have multiple MODBUS links, via serial ports in the CPU. The file F:\CONFIG.DAT and F:\IO_PORTS.DAT had to be properly modified (for even one MODBUS connection, or for multiple connections), if I recall correctly. I think even the GE Mark V HMIs still use those same files.

I'm not really a fan of GE Mark V HMIs (the ones which run MS-Windows and CIMPLICITY), and because they have changed how MODBUS works several times--literally--over the years I didn't bother trying to keep up with the various methods and configurations. So, while it may be possible--I'm not the one to be of much help in this case.

I know that in a couple of manuals--GE Speedtronic HMI manuals, I'm referring to; sorry I don't know their publication numbers)--they do detail pretty well how MODBUS works and can be configured. These aren't CIMPLICITY manuals--though some GE Mark V HMIs do use the MODBUS capability of CIMPLICITY.... (just to keep things "interesting"!). The manuals I'm referring to were produced by GE Salem (the packagers of the GE Mark V HMIs). I have to believe that multiple MODBUS connections would be possible, maybe an easy way would be to have one be a serial connection and the other Ethernet (MODBUS TCP, I think they call it?).

Again, I hope someone else with some experience with GE Mark V HMIs and MODBUS can ask some relevant questions about the configuration at your site (HMI configuration--MS-Windows version; CIMPLICITY version and service pack; TCI version; CIMBRIDGE version; PDH Ethernet card; etc.) and then provide some help. Or maybe even just the GE Speedtronic HMI Manual publication numbers you can refer to. Perhaps if you provide some information someone will have an idea or suggestion. (Usually GE Mark V HMIs all have an option from the Start|Programs|GE Control System Solutions folder to report all the versions of the various programs/applications running on the CPU; it's called, VERSIONS, and when you click on it a window opens with all the various software and versions and service packs listed.

Many times, there is a Documents folder/directory on GE Mark V HMIs with lots of .pdf files of GE publications/manuals in them. Unfortunately, the file names are the publication numbers, forcing you to have open every single one to find out what information/topic that file contains--but that may be a good place to start.

Wish I could be more help! Please let us know how you fare! There are a few people left who know GE Mark V HMIs and MODBUS, but I think they're disappearing fast. Hopefully one or more of them will see this post and help!

 

Thanks. I am also beginning to think modbus might be the best way. Better than adding cards.

I'll keep you posted on how things go.

Regards,
Walt

PS: The only fuel regulator units I work on for commissioning (in training) was in Rockford, Ill in 1970. Fun times. I've worked on a couple since and it's funny how it comes back.

 

Just an update on my situation. I reviewed all the analog inputs and found many of them coming into the Mk-V were not being used in either sequencing or on the displays.

Since the customer was non-responsive to my questions of whether or not I could reuse these inputs, I took it on my self to take the number of inputs I need for my project. They are due to load the new software next month so we'll see if they miss any of those inputs. So I dodged both bullets, the adding a card one and the Modbus one.

Thanks for all you help and lending me an ear to bounce things off of.

Regards,
Walt Robinson