MARK VIe Controllers TMR & I/O Pack

Dear All.

Hope you are good.
I have two questions regarding MARK VIe Controllers TMR & I/O Pack
Version UCSB and UCSC can be function together. I mean in same application, R can be version UCSB and S can be USCC and T UCSB. or all RST should be same version.

I/O pack IS230PCAAH1A can be replaced by IS230PCAAH1B. Control ST version 4.3

Best Regards
 
Djafer-QP,

I would estimate the best people who frequent Control.com to answer this question would be Demigrog or ME42.

Personally, I would attempt it--AFTER making full back-ups of the hard drives on ALL the HMIs being used at the site, and only presuming the current version of ToolboxST has the appropriate drop-downs to select the controller/card you are trying to replace. If the drop-downs were there, I would STILL do a LOT of testing prior to actually starting a turbine. I would check each and every Diagnostic Alarm to see why they are active, clear them as best as possible, and absolutely NOT try to run a turbine with any dangerous Diagnostic Alarms. (What's a "dangerous Diagnostic Alarm" you ask? One that is more than just the run-of-the-mill (routine) problem with an input (that is/has failed or is known to be suspect; or one that indicates serious inability to communicate with other packs/controllers; etc.) I would test all the critical analog outputs (servo-valves; etc.), and critical inputs (P2 pressure transmitters; CPD pressure transmitters; etc.). I would use a frequency generator to simulate a turbine overspeed and check to make sure the fuel stop valves closed (I might try this during a unit START attempt by reducing the overspeed trip setpoint.

But, I wouldn't attempt this (because of the time required to re-configure software--if it could even be re-configured), and because I believe it most like isn't possible. It would most likely involve two unit ToolboxST files, and could cause IMMENSE confusion and work later on if not fully documented. I would ONLY attempt this IF there was absolutely no other choice for obtaining the proper controller/card, and I would certainly make management and ownership aware of the potential time involved in trying to make this work--which may well end in an inability to make this work. Yes; you make make a lot of changes and still this would not work. AND, unless you wrote down every single change you made and had excellent back-ups you would probably have a very difficult time recovering from this attempt.

As I stand and write this, I probably would only do this under duress--meaning the need for power was critical to human life, AND everyone understood the risks (it might work; it might not; and if it didn't work recovery might be difficult and require even more time. In my personal opinion, this is just not a good idea, and could lead to even bigger problems. It might even be possible to start the unit successfully, and then some "unusual" and "dangerous" Diagnostic Alarms might appear--and probably ignored--and the unit could experience serious mechanical failure and someone in the vicinity could be seriously hurt, or worse.

Best of luck. There is no way I could write a procedure for something like this. I have outlined what I might do, but to list each and every step (including backing-up everything along the way) would take days, probably, and still--if I wasn't there doing the work or directing the work to see an unexpected issue/alarm pop up, well, there could be lots of blame and that's not a good thing.

Write back to let us know what you decide. Hopefully, Demigrog or ME42 will see this post and have a more detailed response. I could be very wrong in my thought process and recommendations above--it would not be the first time. But, I haven't cratered a machine yet. (One does realize though, that the longer one is in this business, the danger is that it will happen sometime as familiarity breeds contempt, they say, and people will try many things believing they are experienced enough to recognize--and deal with--the risks. I am not one of those people, especially via a World Wide Web forum such as this one.)
 
All,

These are great questions. And very pertinent today since the H1A IO packs and UCSBs are becoming harder to find. I would first point you to the GEH-6721 Vol II and Vol III that comes with your ControlST install software. Make sure that you only use that version! they make lots of edits for each new release of ControlST that may not apply to your site.

I agree with CSA's hesitancy on changing hardware and the need for backing up the system. However, in the Mark VIe world. the upgrading of I/O packs is quite easy. I would never recommend doing this online, but an offline modification of H1A-->H1B I/O can be done quickly. If you are not comfortable doing this on your own, you can always hire out some experts...i.e. use GE field engineers, CSE engineering, SISO engineering or another system integrator.

To answer your specific questions above:
IS230PCAAH1B - You need ControlST version 4.04 or later
Using the UCSC controller (I am assuming we are talking for the GT controllers not the EX2100e) - this is a bit more complicated. The TMR UCSC did not become available until V07.01.01, In v07.04.00C, controller interoperability was added, but only for the UCSCH2A and the UCSBH1A/H4A. However, I would make sure you are using V07.04.05C w/ SP 07. For more information, on 'Controller Interoperability', go to GEH-6700 section 7.4.2 (depends on what version). If you cannot find it, then your version does not support it.
 
Dear CSA & ME 42.

I would like to thank you for your response.

After checking GEH-6700, now its clear :
FOR I/O PACKS
The H1A and H2A I/O PACKS contain a BPPB processor. These processors are reaching end of life. With ControlST* software

V04.04 and later, BPPB-based I/O packs can be migrated to BPPC-based I/O packs.

FOR CONTROLLERS

Beginning with ControlST V07.04, Mark VIe redundant configurations can support interoperable controllers, with different platform types interoperating in a redundant set. Each controller in the redundant set displays as a separate Platform entry in the Property Editor. If the <R> controller Platform is set to a controller type that is not interoperable then only a single

platform entry is provided for all controllers. If one controller in an interoperable set fails, operators can replace it with the same or a different supported controller type while the process being controlled is still running, without losing plant control.

(ToolboxST supports online replacement.)

Examples of interoperable controllers are:

• UCSBH1A, UCSCH2A

• UCSBH4A, UCSCH2A

just additional one equation regarding terminal board, there is in diff in version or only to update firmware during installation.

Regards
 
Djafer-QP

The Terminal Boards do not have to be modified. They can stay the same version And the I/O pack can be updated to H1B.

Note: your comment about 'V04.04 and later, BPPB-based I/O packs can be migrated to BPPC-based I/O packs' This ONLY applies to the PCAA module. Different ControlST versions are needed for different I/O packs. i.e. the PSCA I/O pack needs V04.07.01C. Or the PSVO I/O pack needs V05.04.00C. The PVIB I/O pack needs V06.01.00C.
 
Dear ME42.

I THINK NOT ONLY PCAA.

All I/O PACK version H1A/H2A contain a BPPB processor. These processors are reaching end of life. With ControlST* software V04.04 and later, these I/O packs can be replaced with H1B or H2B.

My be you are talking about Firmware included in BPPC I/O upgrade V05.01.XXC
Please see attached GE doc.

 

Attachments

You are correct that all H1A/H2A packs contain the BPPB processor and that the BPPB processor is going end of life. However, not all of the new I/O Packs with BPPC processors (H1B/H2B IO Packs) will work on controlST v04.04. Please do not make that mistake. The document says that BPPCs are introduced in v04.04. Not that all IO Packs with BPPCs work with that version. The commond ones like PCAA, PDOA, PDIA are in that version. As I said before "Different ControlST versions are needed for different I/O packs. i.e. the PSCA I/O pack needs V04.07.01C. Or the PSVO I/O pack needs V05.04.00C. The PVIB I/O pack needs V06.01.00C. " NO, I am not thinking of the Firmware version.
 
Dear ME42;

Many thanks for this detail.

As per my understood, that for different I/O pack H1B/H2B we have to install different version of ControlST (V04.07.01C, V05.04.00C, V06.01.00C) whereas In same TMR application only one version can be installed.

Maybe I can ask the question in a different way : to upgrade some I/O pack in same TMR application, required to install different ControlST version corresponding for each I/O pack!! or latest ControlST version can be worked with all type new I/O pack H1B /H2B

Regards
 
I apologies for the confusion. Let me try to explain it this way:
If you wish to install the PCAAH1B I/O pack, you need v04.04 or later (otherwise you must use the PCAAH1A)
If you wish to install the PSCAH1B I/O pack, you need v04.07 or later (otherwise you must use the PSCAH1A)
If you wish to install the PSVOH1B I/O pack, you need v05.04 or later (otherwise you must use the PSVOH1A)
If you wish to install the PVIBH1B I/O pack, you need V06.01 or later (otherwise you must use the PVIBH1A)

For example, There is nothing wrong with operating your system on Version V04.07, but you will not be compatible with the PSVOH1B & the PVIBH1B I/O packs. You will have to use the PSVOH1A and PVIBH1A packs. (there might be another I/O pack that isnt available until later versions too)
 
Top