Mark V Run hours

Hello Team,
How can I get the gas turbine run hours directly from the Mark V control system?. The HMI PC and Cimplicity software was changed so the values on the counter page are wrong. It's a Mark V TMR control system.
 
Hello Team,
How can I get the gas turbine run hours directly from the Mark V control system?. The HMI PC and Cimplicity software was changed so the values on the counter page are wrong. It's a Mark V TMR control system.
Hello Cheede and the team.

When you sayin that the counter page are wrong... Do you know the reason...

I don't have Mark V/Hmi documents with right now... But will have a look on how can I add some notes and try to support..

Cheers
James
 
Hello Team,
How can I get the gas turbine run hours directly from the Mark V control system?. The HMI PC and Cimplicity software was changed so the values on the counter page are wrong. It's a Mark V TMR control system.
That is a pretty broad statement from above. If you have downloaded from your new HMI PC without backing up the totalizers files, you are done.

ALWAYS DO A EEPROM UP and save those totalizer files before installing new HMI.

This is a topic that has been covered many times on Control.com
 
If you want to check the number directly in the markv, look in the file TOTT_Q.src and count down to the timer you want. For example our total fired timer is L30FT_T, and it is the twelfth one down the list. Now go to demand display and look up ACCUM_12_MSW and ACCUM_12_LSW. Math equation (ACCUM_12_LSW+(ACCUM_12_MSW*65535))x0.1
This should be what the hmi displays. The LSW can only count up to 65535 then rolls MSW up one and LSW resets to zero and there is one decimal place. Cimplicity uses a different equation to calculate this by bit shifting the MSW left 16 and adding it that way, I don’t completely understand well enough to explain. There is another thread on here from 2005 that explains the cimpicity method better. If all you’ve done is changed to a different HMI then likely this equation is just not done properly. Hopefully this makes sense as I’m typing on phone
 
Y’all are speculating because we don’t know what happened BEFORE the timers and counters were found to be wrong.

It’s probably likely that someone downloaded ALL to the Mark V. But we don’t know that.

This is just another person who thinks that the issue they are experiencing is simple to fix and that no explanation is required because someone (many people in their estimation!) has experienced precisely the same issue and can tell precisely what to do to fix the (self-inflicted) problem.

I have seen a couple of occasions—freaky series of steps and mis-steps—that resulted in the EEPROM timer and counter values being erased. Someone could even have downloaded FORMAT for some inexplicable reason and overwritten the EEPROM timer and counter data with zeroes. Probably because they (mistakenly) believed that some other (perceived) problem required FORMATting the EEPROM and downloading ALL (which actually includes FORMAT!) to resolve. (NEWSFLASH: There isn’t a single >>problem<< that requires this to solve.)

Anyway, speculating is a waste of time that can cause other readers to make similar mistakes. Or worse.

If the original poster can’t be bothered to provide more information or feedback, ControlsGuy25 will prod him at least once. But if he doesn’t provide more information, there’s nothing more we can offer. Speculation is not helpful.

And it’s a waste of time for just about everyone.

Blessed day.
 
Y’all are speculating because we don’t know what happened BEFORE the timers and counters were found to be wrong.

It’s probably likely that someone downloaded ALL to the Mark V. But we don’t know that.

This is just another person who thinks that the issue they are experiencing is simple to fix and that no explanation is required because someone (many people in their estimation!) has experienced precisely the same issue and can tell precisely what to do to fix the (self-inflicted) problem.

I have seen a couple of occasions—freaky series of steps and mis-steps—that resulted in the EEPROM timer and counter values being erased. Someone could even have downloaded FORMAT for some inexplicable reason and overwritten the EEPROM timer and counter data with zeroes. Probably because they (mistakenly) believed that some other (perceived) problem required FORMATting the EEPROM and downloading ALL (which actually includes FORMAT!) to resolve. (NEWSFLASH: There isn’t a single >>problem<< that requires this to solve.)

Anyway, speculating is a waste of time that can cause other readers to make similar mistakes. Or worse.

If the original poster can’t be bothered to provide more information or feedback, ControlsGuy25 will prod him at least once. But if he doesn’t provide more information, there’s nothing more we can offer. Speculation is not helpful.

And it’s a waste of time for just about everyone.

Blessed day.
CSA,

The dreaded EEPROM .....ALL can be a good tool. I have used it to correct core checksum errors in the past.

However, I always had a good backup of the totalizer files first.

Cheedee,

There is a way to rebuild the totalizer data, if you have an idea what the values should be. I used the written data from manually maintained run reports to recreate the data.

If you have such data, I may be able to help you.

Best regards
 
Yes, GE Salem did invent a way to fix these kinds of … mis-steps. BUT, they only a couple copies of the software tool to make the changes to the Totalizer data file out of the factory.

It was reported several years ago that someone had done something similar, but it was also reported that it wasn’t reliable. GE does do these fixes, but I don’t know what the process is for getting it done these days. There was a website called GE Controls Connect, I think it was, that would do it. The vaunted GE PAC (Power Answer Center) would sometimes do it; but I don’t know if it’s even still around anymore or what it might have morphed into.

But, that’s about it. Again, we don’t know what happened to cause this problem (real or perceived). If you have a method or software tool for modifying Totalizer data files, you could probably make a few dollars performing the service for sites that still use Mark V and shoot themselves in the foot from time to time.

But, this is STILL speculation. That only the original poster can clarify.
 
Yes, GE Salem did invent a way to fix these kinds of … mis-steps. BUT, they only a couple copies of the software tool to make the changes to the Totalizer data file out of the factory.

It was reported several years ago that someone had done something similar, but it was also reported that it wasn’t reliable. GE does do these fixes, but I don’t know what the process is for getting it done these days. There was a website called GE Controls Connect, I think it was, that would do it. The vaunted GE PAC (Power Answer Center) would sometimes do it; but I don’t know if it’s even still around anymore or what it might have morphed into.

But, that’s about it. Again, we don’t know what happened to cause this problem (real or perceived). If you have a method or software tool for modifying Totalizer data files, you could probably make a few dollars performing the service for sites that still use Mark V and shoot themselves in the foot from time to time.

But, this is STILL speculation. That only the original poster can clarify.
CSA,

You are correct as usual.

MY METHOD that I showed GE in Salem during training blew their minds.

GE had a solution for the damaged TOTD file which they would SELL to the client as a service. Basically, GE would say ...what do you want it be. We will send you a new TOTD file for a price.

If Cheedee has the data, I will publish my method. The cool thing is it is published in the GE manual regarding ones complement math.
 
Curious_One,

You are curious; that’s for certain,

I never recall GE charging for this service. (Most people who commit the mis-steps leading to over-writing Totalizer data do so with good intentions, but are poorly informed and most are just flailing, to be perfectly honest. Compiling and downloading and re-booting are almost NEVER necessary, but people are convinced that the Mark V is like an IBM-compatible PC, and it needs to be reloaded and rebooted sometimes, and no one is going to convince them otherwise.) GE Salem personnel recognized this, and in fact many of the occurrences were committed by field service people. So, after a little “questioning” they usually asked for the data you are requesting and created the new Totalizer data file and sent it via email with instructions for properly getting all three control processors synched after the downloads.

I hope cheedee writes back with the information (methinks he will require some instruction how to look up what signals are totalized) because I am curious now. I have heard of two’s complement numbers and I know GE published a section on floating point math in the Mark V Application Manual, GEH-6195. But I don’t recall reading anything about one’s complement numbers in any Mark V-related documents. But, I didn’t read the latter stuff that was published when the GE Mark V HMIs were being produced. It was fast and furious back in those days and by the time I read any of those manuals I soon realized that GE Salem had changed the way several things were being done and I had to call the factory to get the latest information. So, I basically just gave up reading those Mark V documents pretty quickly. But it’s entirely possible I overlooked something.
 
Y’all are speculating because we don’t know what happened BEFORE the timers and counters were found to be wrong.

It’s probably likely that someone downloaded ALL to the Mark V. But we don’t know that.

This is just another person who thinks that the issue they are experiencing is simple to fix and that no explanation is required because someone (many people in their estimation!) has experienced precisely the same issue and can tell precisely what to do to fix the (self-inflicted) problem.

I have seen a couple of occasions—freaky series of steps and mis-steps—that resulted in the EEPROM timer and counter values being erased. Someone could even have downloaded FORMAT for some inexplicable reason and overwritten the EEPROM timer and counter data with zeroes. Probably because they (mistakenly) believed that some other (perceived) problem required FORMATting the EEPROM and downloading ALL (which actually includes FORMAT!) to resolve. (NEWSFLASH: There isn’t a single >>problem<< that requires this to solve.)

Anyway, speculating is a waste of time that can cause other readers to make similar mistakes. Or worse.

If the original poster can’t be bothered to provide more information or feedback, ControlsGuy25 will prod him at least once. But if he doesn’t provide more information, there’s nothing more we can offer. Speculation is not helpful.

And it’s a waste of time for just about everyone.

Blessed day.
I asked Cheede if they at least know why they got totalizers values reading wrong.. He did not tell us why..
So Cheede can you provide at least such information so we can try to support...
Just tell us even if you don't know why...
 
Cheedees question was how to get the numbers directly from the MarkV as they went with a different hmi and not Cimplicity. I provides an explaination that I currently use to get the numbers into our PI system, I just figured it out reading this forum form using the search feature and looking at the equation for the points in Cimplicity.
The first couple of responses he got look to be from MarkVi as they talk about sdb files, I’ve never seen these files in our MarkV system.

It is possible they installed a new HMI system and did a download all, we may never know.
 
Top