Dear CSA and others,

Ours is a frame5 mk6 speedtronic system. M6b file status is shown a minor difference between Mk6b and P code.
In Mk6b, how to find, and where to search for this difference? and which causes the difference? before we make it equal by uploading thru DEVICE menu.

kindly give the details about it.

Thanks..

 

Eskay,

Funny you should post this question today, as I have spent several hours by telephone and email helping a site with this very same problem today.

GE, in their usual (undocumented) manner, wrote some versions of Toolbox to warn the user of a Minor Difference when a new Watch Window was created, or, in some older versions of Toolbox, if additions or deletions were made to existing Watch Windows.

Technically, since the Watch Windows were part of the .m6b file, this was true--even though their existence or their content did NOT affect turbine operation, control or protection. They were saved in the .6b file in early versions of Toolbox, and so did, in fact, represent a difference from the .m6b file which had been previously downloaded to the Mark VI controller(s).

If I recall correctly, some very early versions of Toolbox would also warn of a Minor Difference if an operator forced a logic signal, and leaving the force active, tried to close the .m6b file. And, some versions of Toolbox would also annunciate a Minor Difference if the "running" value of a Control Constant was changed without changing and saving the Initial Control Constant Value, also.

Because even early versions of Toolbox didn't have any information about what cause Minor (or even Major) Differences, it was a trial-and-error experience discovering what caused these Differences--sometimes without even discovering the reason(s)! And, when GE did change Toolbox to not warn for such trivial issues that didn't directly affect control and protection it was never understood when the changes were made.

So, troubleshooting this kind of warning can be very difficult indeed. If you are <b>certain</b> that no changes to application code, or I/O configuration, or Control Constants, were made that would affect unit control and protection, <b>AND</b> you have done a Compare with the last known good back-up (you do have back-ups of the last known good .m6b file, correct?), <b>AND</b> you have looked at the Control Constants display to understand any 'not equal' indications (which can sometimes be the result of different numbers of decimal places in the "running" and Initial Values), and you have <b>NOT</b> enabled any Privileges above level "0", then it's likely safe to close Toolbox without saving the "changes".

If, however, you don't have a known, good, recent back-up file to compare (using the Toolbox File - Compare... utility) <b>AND</b> haven't manually looked at the Control Constants to resolve any 'not equal' indications to your satisfaction, then it's a personal call about how to handle the warning. If you have enabled Privelege Level 1 or 2 or above, and weren't extremely vigilant while performing whatever the Privilege Level required, then you most likely would want to either, (1) exit .m6b file without saving any changes, or, (2) upload the running .m6b file if you're absolutely certain it is unmodified, then save and exit, re-open the .m6b file and re-connect to check the Difference status.

But, in a nutshell, it's a site/personal call based on how long Toolbox has been open, what it was used for when it was open, what the current Privilege Level is or was while the file was open, and the experience level of the person(s) recently using the .m6b file.

In the case I was assisting with today, Toolbox had been open for weeks as near as anyone could tell. The Privilege Level was found at 2. The File - Compare... did not reveal any application code/configuration differences, and a check of the Control Constants revealed one that had been changed "temporarily". It was not possible for anyone at the site to say when the Minor Difference warning was first annunciated, nor if any Watch Windows had been added or modified (though it was thought that a new Watch Window had been added). The Mark VI was a SIMPLEX control panel, and after a few hours of back and forth it was decided to upload and do a File - Compare... and check for any differences, and again none were found.

So, Toolbox was closed after saving the "open" .m6b file to a back-up for safe-keeping, and <R> was re-booted and the unit was started and run to about 50% load without any problems or new alarms (Process or Diagnostic).

That's about all I can say; best of luck. Write back to let us know what you decide and how you fare!

 

Dear CSA,

Controller showing "minor difference" in m6b file. During our turbine running in Distillate fuel mode, we had the problem of "servo current suicided "alarm appeard for Regulator# 3.("T" controller.)Though the turbine was running with "R' and "S" controller values,and to get rid of the alarm, we have "disabled" the servo current suicide at the configuration page.Now the turbine is running in "Gas fuel"mode and we set the configuration of the distillate servo current suicide , back to "enable" and uploaded the configuration. Now we notice that the controller state changed to "equal" and file- compare action did not show any discrepancy for the VSVO / TSVO.

Thanks for the valuable information on this subject.

Best wishes & regards

 

ESKAY,

This is information which was not provided in the original post.

If you changed the configuration for the VSVO card, did you download the new configuration to the VSVO? While the turbine was running?

Because the configuration change was not effective unless the change was downloaded to the card.

A three-coil servo-valve does NOT require three currents to operate properly. Three currents are used for redundancy, but aren't required for proper turbine operation. The turbine was running without the current from <T>, but the VSVO was trying to tell someone that there was a problem with the circuit or the feedback and someone chose to not investigate that problem, but to make the alarm go away--which did not resolve the underlying problem.

The proper course of action would have been to understand <b>WHY</b> the current had been suicided, and solve that problem. Now, the next time the turbine runs on liquid fuel it's highly likely the current from <T> will again be suicided.

Treating the symptom does not cure the disease. It just masks the disease.

 

Dear CSA,

For the servo suicide in distillate fuel mode, we have noticed that the servo coil ohmic value for the <T> controller was abnormal compared to the other servo coil for <R> and <S>. We have removed the fuel servo 65FP and replaced with NEW one, checked and the regulator suicide was "enabled" and the servo configuration "down loaded". Then the "servo current suicide" alarm disappeared and the Controller was shown the status "equal".

Thanks for the valuable advice and prompt reply. Regards...