I am doing an upgrade of a Multiunit.There are 4 units in the plant,but 3 gas turbines have Mark VIe system to operate them,one has Mark VI operating it.I made it so I could put the Mark VI online but I could not see the alarms in the Workstation even although everything was configured perfectly.After this I did a Pack Alarms and so the controller went into a major difference.I turned it off then,and tried to turn it on to put in online but at this point I could not even ping the controller.By this point I formatted the compact flash drive but I could not ping it.I tried to go online but I could not.Then I turned it off again and turned it on,I could ping it but i cannot connect online as it says:"error connecting to target,the controller nees its runtime code loaded and started".I loaded the runtime once,do I need to do it again?
Is there any procedure to turn on Mark VI?
Also one the HMIs cannot connect through the network to the other HMIS,it can ping the other devices,it can connect to them through remote desktop,but if I go to Network it cannot connect to it even although I have enabled the File and Printer Sharing

 

@nikid.control,

I don't quite understand "...upgrade of a Multiunit...." What is it that you're upgrading?

Detail exactly the steps you are performing to "turn on" the Mark* VI--EXACTLY. When are you turning on the protective processors (<X>, <Y> and <Z>)? Are you waiting any time between closing the switches to each of the protective processors? Or r seconds between closing each of the second and third switches? Or 10 seconds? Or 1 minute?

When are you applying power to the three control processors (<R>, <S> and <T>)? How much time are you waiting between closing the second and third switches? Are you applying power by closing the switches on the rack-mounted power supplies or are those switches closed when you close the switches in the <PD>?

Are you seeing any diagnostic LEDs for the three IONETS on <R>, <S> and <T> on the three VCMIs once all six processors (three protective and three control) are power-up?

By default, a Mark* VI wants <R> to be the designated controller when all three controllers are powered-up. If <R> can't be the designated controller, then the Mark* VI wants <S> to be the designated controller. And, it never wants <T> to be the designated controller.

I've never really understood the whole terminology very well, but each control processor needs to have its "topology" downloaded to it. It's not a topic that is covered very well in any of the documentation/manuals that I've ever read, but it IS a thing. The VCMI needs to know which slot every I/O card is mounted in, including the protective processors--and which are TMR and which are SIMPLEX in the control processors. (That was kind of explained in one of other threads you are posting for help with this problem.)

Yes; sometimes the runtime and application code seem to have to be downloaded more than once. No; it's not documented when or why, or why not. Downloading should be done to one control processor at a time--trying to select downloading to all three processors--especially on a multi-unit site with LOTS of traffic on the UDH can be very problematic when selecting downloading to all three processors. (This is my personal experience, and many people I worked with shared the same experience. Be patient; these things take time. Unfortunately, there doesn't seem to be a lot of error-checking happening during downloads, and people usually forget to check the status window at the bottom of the Toolbox/ToolboxST displays when downloading for warnings and error messages that DO get annunciated. Yes; the messages are cryptic as hell. No; there is no secret decoder ring for understanding or troubleshooting them.

Again, I--and probably many others reading this thread (and all the other ones you're posting to with this problem--which should be its own separate thread)--don't really understand what you're upgrading. If you're doing this for GE, are you getting any support from them? If so, what are they telling you? And, you should always remember: The Mark* VI is technically not a supported product any longer; hasn't been for years. And, the ranks of people with Mark* VI experience even in the field service support team(s) are well depleted.

In my personal experience, I apply power to the protective processors first of a Mark* VI panel that has all of its processors powered down, waiting about 5 seconds before closing each of the second and third switches (so, <X> first; then <Y> five seconds later; then <Z> five seconds later). I try to wait until I get "good" LEDs on the faces of the three protective processors before applying power to any of the control processors. While waiting for that to happen (usually takes several minutes), I make sure the switches of the control processor rack-mounted power supplies are all off and make sure the control processor power supply switches in <PD> are ON. Then I switch on <R> first, waitied by a few seconds before switching on <S> (if I recall correctly it's possible to hear a faint beep soon after each control processor rack has had power applied to it--and I wait to hear that beep before applying power to the next control processor). I switch on <S> second (and wait to hear that faint beep) and then switch on <T>. I watch the diagnostic LEDs on the VCMIs (the ones with the coaxial cables of the IONETs plugged into them)--there shouldn't be any red LEDs lit. If there are, that needs to get resolved pretty quick (and this is assuming all three IONETs are working properly and the processor cards are booting or have booted up properly.

I developed this process after lots of problems in the field, and with one Mark* VI panel in particular that was never powered-up in the field and made two trips across the pond after sitting in a hot desert for several years. It was a real bear of a panel just to get powered-up and at 106, and then it needed to be converted to a gas fuel only panel from a liquid fuel only panel. The topography thing was rough going, and I don't have my notes anymore and I've gladly stopped thinking about it after about 10 years. Anyway, I sort of feel your pain. But you're not helping yourself by not explaining what is being upgraded. Were you upgrading the Mark* VIe's? Or Toolbox or ToolboxST? I gotta believe the control room HMIs (and engineering workstations) are all running ControlST and WorkstationST Alarm Viewer. So, why has WorkstationST Alarm Viewer stopped "accepting" alarms/events from the Mark* VI? Alarms and most events are broadcast by the designated controller of each Mark* control system onto the UDH and are read by WorkstationST Alarm Viewer. So, what's changed?

"That's your job, nikid.control, should you choose to accept it. As always if you or any member of your team fail we will disavow your existence." [That was from the opening sequence of just about every Mission Impossible TV series episode. And we never really knew who "they" were--the ones who would be doing the disavowing.] Again, the Mark* VI is technically no longer a supported product....Yes, there are a few people around who might be able to help but finding them is going to be difficult.

Sometimes, though, it does feel like it's one person against the whole world.

 

Hello WTF,I am doing an HMI Upgrade,just substituting the software of the controllers and not the controller itself in a plant in Germany

Firstly I searche the forum to see if anyone else had had this problems with the Mark VI systems and apparently a lot of people had had problems.

I saw a post of yours in which was written to turn on the VPRO cards before and then after some minutes,when the VPRO cards were synchronized to turn on the controllers but that did not resolve the issue,I guess now I just have to do the runtime and everything should run I guess.An ex GE guy told me that it did not matter to wait,just turn on the VPRO cards and in less than 20 seconds to turn on the controller,but other people say otherwise.I don’t know the fame MARK VI has,but to do such a system that needs to synchronize does not seem like a good design to me.

I will go to the plant,and try to do the runtime,then I will try to put the controller in Control Mode,but the problem that we had,and the reason why I turned off the controller is that we could not see the alarms displayed in GeWorkstation,that’s what we are trying to resolve.I will let you know

Thanks a lot for your detailed response and the dedication to help other people here

Also lol at the movie reference

 

@nikid.control,

I don't quite understand "...upgrade of a Multiunit...." What is it that you're upgrading?

Detail exactly the steps you are performing to "turn on" the Mark* VI--EXACTLY. When are you turning on the protective processors (<X>, <Y> and <Z>)? Are you waiting any time between closing the switches to each of the protective processors? Or r seconds between closing each of the second and third switches? Or 10 seconds? Or 1 minute?

When are you applying power to the three control processors (<R>, <S> and <T>)? How much time are you waiting between closing the second and third switches? Are you applying power by closing the switches on the rack-mounted power supplies or are those switches closed when you close the switches in the <PD>?

Are you seeing any diagnostic LEDs for the three IONETS on <R>, <S> and <T> on the three VCMIs once all six processors (three protective and three control) are power-up?

By default, a Mark* VI wants <R> to be the designated controller when all three controllers are powered-up. If <R> can't be the designated controller, then the Mark* VI wants <S> to be the designated controller. And, it never wants <T> to be the designated controller.

I've never really understood the whole terminology very well, but each control processor needs to have its "topology" downloaded to it. It's not a topic that is covered very well in any of the documentation/manuals that I've ever read, but it IS a thing. The VCMI needs to know which slot every I/O card is mounted in, including the protective processors--and which are TMR and which are SIMPLEX in the control processors. (That was kind of explained in one of other threads you are posting for help with this problem.)

Yes; sometimes the runtime and application code seem to have to be downloaded more than once. No; it's not documented when or why, or why not. Downloading should be done to one control processor at a time--trying to select downloading to all three processors--especially on a multi-unit site with LOTS of traffic on the UDH can be very problematic when selecting downloading to all three processors. (This is my personal experience, and many people I worked with shared the same experience. Be patient; these things take time. Unfortunately, there doesn't seem to be a lot of error-checking happening during downloads, and people usually forget to check the status window at the bottom of the Toolbox/ToolboxST displays when downloading for warnings and error messages that DO get annunciated. Yes; the messages are cryptic as hell. No; there is no secret decoder ring for understanding or troubleshooting them.

Again, I--and probably many others reading this thread (and all the other ones you're posting to with this problem--which should be its own separate thread)--don't really understand what you're upgrading. If you're doing this for GE, are you getting any support from them? If so, what are they telling you? And, you should always remember: The Mark* VI is technically not a supported product any longer; hasn't been for years. And, the ranks of people with Mark* VI experience even in the field service support team(s) are well depleted.

In my personal experience, I apply power to the protective processors first of a Mark* VI panel that has all of its processors powered down, waiting about 5 seconds before closing each of the second and third switches (so, <X> first; then <Y> five seconds later; then <Z> five seconds later). I try to wait until I get "good" LEDs on the faces of the three protective processors before applying power to any of the control processors. While waiting for that to happen (usually takes several minutes), I make sure the switches of the control processor rack-mounted power supplies are all off and make sure the control processor power supply switches in <PD> are ON. Then I switch on <R> first, waitied by a few seconds before switching on <S> (if I recall correctly it's possible to hear a faint beep soon after each control processor rack has had power applied to it--and I wait to hear that beep before applying power to the next control processor). I switch on <S> second (and wait to hear that faint beep) and then switch on <T>. I watch the diagnostic LEDs on the VCMIs (the ones with the coaxial cables of the IONETs plugged into them)--there shouldn't be any red LEDs lit. If there are, that needs to get resolved pretty quick (and this is assuming all three IONETs are working properly and the processor cards are booting or have booted up properly.

I developed this process after lots of problems in the field, and with one Mark* VI panel in particular that was never powered-up in the field and made two trips across the pond after sitting in a hot desert for several years. It was a real bear of a panel just to get powered-up and at 106, and then it needed to be converted to a gas fuel only panel from a liquid fuel only panel. The topography thing was rough going, and I don't have my notes anymore and I've gladly stopped thinking about it after about 10 years. Anyway, I sort of feel your pain. But you're not helping yourself by not explaining what is being upgraded. Were you upgrading the Mark* VIe's? Or Toolbox or ToolboxST? I gotta believe the control room HMIs (and engineering workstations) are all running ControlST and WorkstationST Alarm Viewer. So, why has WorkstationST Alarm Viewer stopped "accepting" alarms/events from the Mark* VI? Alarms and most events are broadcast by the designated controller of each Mark* control system onto the UDH and are read by WorkstationST Alarm Viewer. So, what's changed?

"That's your job, nikid.control, should you choose to accept it. As always if you or any member of your team fail we will disavow your existence." [That was from the opening sequence of just about every Mission Impossible TV series episode. And we never really knew who "they" were--the ones who would be doing the disavowing.] Again, the Mark* VI is technically no longer a supported product....Yes, there are a few people around who might be able to help but finding them is going to be difficult.

Sometimes, though, it does feel like it's one person against the whole world.

Hello WTF,I am doing an HMI Upgrade,just substituting the software of the controllers and not the controller itself in a plant in Germany

Firstly I searche the forum to see if anyone else had had this problems with the Mark VI systems and apparently a lot of people had had problems.

I saw a post of yours in which was written to turn on the VPRO cards before and then after some minutes,when the VPRO cards were synchronized to turn on the controllers but that did not resolve the issue,I guess now I just have to do the runtime and everything should run I guess.An ex GE guy told me that it did not matter to wait,just turn on the VPRO cards and in less than 20 seconds to turn on the controller,but other people say otherwise.I don’t know the fame MARK VI has,but to do such a system that needs to synchronize does not seem like a good design to me.

I will go to the plant,and try to do the runtime,then I will try to put the controller in Control Mode,but the problem that we had,and the reason why I turned off the controller is that we could not see the alarms displayed in GeWorkstation,that’s what we are trying to resolve.I will let you know
As a FSE,yes it is you against the world and the turbines in particular

Thanks a lot for your detailed response and the dedication to help other people here

Also lol at the movie reference