Dears,

Recently one of our GE-9E unit gas flow totalized counter started reading negative while unit is running. Since historian was fetching correct data, we identified problem could be with HMI graphics. After we changed the particular counter properties as real from integer started reading normal as before, but reading negative if it is integer.

Formula used for totalized counter is (MSW SHL 16 + LSW) * 8.54.

If anyone pass the information, how real and integer play a role in HMI (PC) would be useful.

take care
g.rajesh

 

The most significant bit for both IEEE754 floating point and signed integer is the sign bit; a logic 1 is negative, a logic 0 is positive.

The IEEE 754 32 bit floating point format amounts to two 16 bit Modbus 'words'. The sign uses one bit, the exponent uses 8 bits, the mantissa uses 23 bits.

Depending on the word and byte formatting (most significant word vs least significant word, straight bytes or swapped bytes) it is highly likely that the totalizer is misinterpreting a 16 bit 'integer' word which is only a meaningless fractional part of a 32 bit floating point value.

Doing so can easily have a logic one in the most significant bit making the false 'integer' value appear negative, even though the original floating point value is positive. But the floating point value is the full 32 bits, not just a partial 16 bits of the whole 32 bit value.

You need to display and read the rate value, confirm that the rate value reads correctly, and then find out what format the rate value is - integer or floating point and use that for your totalizer.

You can see what floating point format looks like here:
http://www.h-schmidt.net/FloatConverter/IEEE754.html

 

Thank you very very much for your feedback. Though I am not clear about your information right now, we'll read it many times and get the point behind that.

thanks again

take care
g.rajesh

 

g.rajesh,

David_2 gave a great answer (as usual!).

My question is: If it was working and then suddenly started going negative, what caused the change?

What is the name of the signal which is associated with the counter which is having problems? (If the signal has a _LSW suffix, please post it and the associated signal with the _MSW suffix.)

I presume from another of your posts there are multiple GE Mark V HMIs per turbine. Is the other HMI on this particular turbine experiencing the same problem?

What happens when you open a Logic Forcing Display and enter the counter signal name? What value is displayed for the signal name?

Please go to the affected GE Mark V HMI and open UNITDATA.DAT (this and the other files below are in the F:\UNITn, directory--usually F:\UNIT1 for sites without multi-unit GE Mark V HMIs), and while at the top of the file note which column is for the SCALE CODE. Find the name of the signal that is being used by the counter on the CIMPLICITY display and note at the SCALE CODE number for the signal name. Exist UNITDATA.DAT <b>without</b> saving any changes (because you were just viewing the file so no changes should have been made!). Post this number in a response. Also, please post the file's date/time stamp for UNITDATA.DAT (you can get this by typing:<pre> DIR UNITDATA.DAT</pre> from the command prompt of the unit-specific directory (e.g., F:\UNIT1) and pressing ENTER, or from the MS-Windows File Explorer Details view of the unit-specific directory.)

Open SCLEDATA.DAT, and scroll down to the SCALE CODE type number, and that row will tell you what the scaling is for the signal. Post the row information from this file row in a response. Again, exit the file without saving any changes.

Then open TOTT_Q.DAT and find the signal name and note the information in the row for that signal. Post the row information from this file in a response, along with the file's date/time, also. Again, exit the file without saving any changes.

This should be enough information to help, but, again, if the counter was working properly before, what changed? And, is it also now working on the other GE Mark V HMI(s) for that unit?

Has anyone done any MK5MAKEs and downloaded USER or ALL to the Mark V with the "problem"?

Has someone been mucking with the CIMPLICITY Project for the GE Mark V HMI which is experiencing the problem?

Please write back with the requested information and answers.

 

Thanks again CSA for your supports, it's like person sitting next to us and giving instruction.

---If it was working and then suddenly started going negative, what caused the change?
* yes it was working normal, all of sudden started problem and reading negative

---What is the name of the signal which is associated with the counter which is having problems?
* ACCUM_24_MSW & ACCUM_24_LSW

---Is the other HMI on this particular turbine experiencing the same problem?
* Yes, two HMI's having negative counter (but historian is reading correctly)

---What happens when you open a Logic Forcing Display and enter the counter signal name? What value is displayed for the signal name?
MGT2B_ACCUM_24_MSW_AI 10/28/15 1:16:15 PM 3845
MGT2B_ACCUM_24_LSW_AI 10/28/15 4:54:08 PM 12203

---Scale code from unitdata.dat
ACCUM_24_LSW 6659 018 0270 0000 0000 0001 0060 2406
ACCUM_24_MSW 6660 002 0025 0000 0000 0001 0060 2408

---Also, please post the file's date/time stamp for UNITDATA.DAT
10/22/2015 08:35 (this could be due to we restarted all processors)

---Open SCLEDATA.DAT, and scroll down to the SCALE CODE <pre>
#scale_data 25 32768.000000 0.000000 0 CNT15 CNT15
#scale_data 270 65536.000000 0.000000 0 CNTS LSW</pre>
---Then open TOTT_Q.DAT
* There is no TOTT_Q.DAT file, we are having TOTT_Q(B).AP1/BAK/SRC

---Has anyone done any MK5MAKEs and downloaded USER or ALL to the Mark V with the "problem"?
Has someone been mucking with the CIMPLICITY Project for the GE Mark V HMI which is experiencing the problem?
* There is no work done on the HMI in the recent 8 months.

thanks again for your supports and give further feedback as you directed.

take care
g.rajesh

 

We are waiting for your further direction and feedback.

take care
g.rajesh

 

g.rajesh,

I have limited time at this writing, and I didn't see your reply above. (Thanks for the complete information!)

UNITDATA.DAT's file date/time stamp only get changed when MK5MAKE.BAT is run (or when someone runs the executables called by the batch file to create a new UNITDATA.DAT). So, the fact that the date/time stamp for UNITDATA.DAT is very recent means, indeed, that someone--or something (???)--has run MK5MAKE.BAT or one of the executable in the batch file. Why? No one seems to know.

TOTT_Q.SRC is the file I meant to ask for; the ASCII text file that defines the CDB signals for which values are being "totalized"/accumulated. So, please provide the contents of TOTT_Q.SRC; sorry for the confusion. (TOTT_Q.AP1 is the hex format, compiled version of the file that's also created by MK5MAKE.BAT and is downloaded to the Mark V control processors.)

Also please provide the date/time stamp for TOTT_Q.SRC and TOTT_Q.AP1.

Which prompts the question, has anyone been downloading to the Mark V control processors lately? And, if so, why? And which EEPROM "partition" was used for the download (ALL, USER, [some other partition(s)])?

 

Thanks again CSA,

---UNITDATA.DAT's file date/time stamp only get changed when MK5MAKE.BAT is run

*yes understood, but problem started on 10/21/15 at 12:05 PM, UNITDATA.DAT stamp date is 10/22/15 08:35 AM. We restarted all processors on 22/10/15 0835 hrs.

---please provide the date/time stamp for TOTT_Q.SRC and TOTT_Q.AP1

Remote HMI date and time stamp as follows<pre>
UNITDATA.DAT 10/22/2015 08:35 AM
TOTT_Q.SRC 10/22/2015 08:35 AM
TOTT_Q.AP1 10/22/2015 08:35 AM</pre>
Local HMI too reading negative from 10/21/2015.
Local HMI date and time stamp as follows<pre>
UNITDATA.DAT 5/6/2015 11:47 PM
TOTT_Q.SRC 4/29/2000 4:06 PM
TOTT_Q.AP1 5/6/2015 11:47 PM</pre>
---please provide the contents of TOTT_Q.SRC (same in local and remote)<pre>
*;-----------------------------------------------------------------------------
;
; Totalizer Data file - Q
;
;-----------------------------------------------------------------------------
;
; MANAH_2
; OMAN
;
;
;
;
; 01/01/00
;
;-----------------------------------------------------------------------------
; Specify 1,2,3, or 4.
; types 1 (=counter)
; 2 (=timer)
; 3 (=analog accumulator)
; 4 (=accumulated logic) ;adds a constant value to an accumulator when
; pickup of a trigger logic is detected.
; Must keep signals in order.
;
; Signal Trigger level for
;Type Name analog type (opt)
;---- ------------ -----------------
;
1 L30CMIS ;1
1 L30CTS ;2
1 L30CFLS ;3
1 L30CFS ;4
1 L30CES ;5
1 L30CCT ;6
1 L30CEO ;7
1 L30CRL1X ;8
1 L30CRL2X ;9
1 LFALSE ;10
2 L30GXLX ;11
2 L30FT_T ;12
2 L30FT_P ;13
2 L30FT_G ;14
2 L30FT_L ;15
2 L30FT_L2 ;16
2 L30FT_G2 ;17
2 L30FT_I ;18
2 L30FT_ML ;19
2 L30FT_MH ;20
2 L30FT_IGV ;21
2 LFALSE ;22
4 L77FL 10 ;23
3 FQG 128 ;24</pre>
As informed, both local and remote HMI's are reading well after we changed the parameter to real from integer.

take care
g.rajesh

 

g.rajesh,

By way of explanation and detail, the CDB signal FQG is assigned to accumulator 24 in TOTT_Q.SRC; that's how the gas fuel flow-rate gets "accumulated" to represent total flow from flow-rate. The integer 24 in the comment column after the semicolon at the far right of the TOTT_Q.SRC file is what tells the reader of the file the CDB signal (FQG) in the second column is assigned to the 24th available totalizer/accumulator location in Mark V memory (EEPROM). (Actually, it's the placement of FQG on the 24th line of the TOTT_Q.SRC that IS the assignment to the 24th available totalizer/accumulator memory location.)

When compiled into TOTT_Q.AP1 (for GE Mark V HMIs running MS-Windows and CIMPLICITY) and downloaded to the control processors and the control processors are re-booted, the gas fuel flow-rate value, FQG, is used to determine how much gas fuel has been flowing into the machine.

CIMPLICITY, via the addition of the ACCUM_24_MSW and ACCUM_24_LSW and uses the formula created in CIMVIEW using math functions and values in the formula to display the data in usable engineering units.

When you say you changed the "...particular counter properties..." I at first thought someone changed something in the TOTT_Q.SRC or SCLEDATA.DAT file(s), compiled, downloaded to the Mark V, re-booted the Mark V control processors (one at a time) and then re-booted the GE Mark V HMI.

But now I believe what was done was that the CIMPLICITY display properties for the 24th accumulator value(s) (after the maths were done by CIMPLICITY on the value(s)) was changed from REAL to INTEGER. I believe when this was done that any decimal places in the gas fuel flow-rate value being displayed on the CIMPLICITY display were lost--there is now only the integer value with no tenths or hundredths.

I also presume, trying to work David_2's information into the answer, that what happened is that the value in the 24th available accumulator memory locations grew so large they caused the sign bit to change, which caused CIMPLICITY to think the value had gone negative. That's about the only think I can think of.

However, when a GE Mark V operator interface is re-booted the site-specific configuration files (such as UNITDATA.DAT, TOTT_Q.SRC, TOTT_Q.AP1, etc.) <i><b>should NOT</i></b> be modified, causing the file data/time stamps to change. That's the part I can't understand or explain. Something else was done, such as loading from a CD, to cause the file data/time stamps to all be the same.

When one changes a .SRC file, the file's date/time stamp changes to date/time when the changes to the file were saved (either during the SAVE prior to the closure of the file, or when the person making the changes exited the file and answered 'Yes' to being asked to save the changes. Then, when MK5MAKE.BAT is run (or the Table Compiler, or Master Sequence Compiler, depending on which .SRC file(s) were edited and saved with the changes) the newly created UNITDATA.DAT and .AP1 files will have the time/date stamp <i>when the compiler created the new .AP1 files from the .SRC files.</i> And, unless the person making the change(s) to the .SRC files was VERY FAST and executed the batch file in the same minute as the changed .SRC file(s) was(were) changed, the UNITDATA.DAT and .AP1 file date/time stamps are going to be at least one minute different from the file date/time stamps of the .SRC files.

Now, it's possible that someone wrote a "script" or batch file to execute MK5MAKE.BAT when the GE Mark V HMI is re-booted. That would definitely be a totally custom and highly discouraged practice. For one reason, if UNITDATA.DAT changes then the CIMPLICITY Project has to be updated and the new information from the new UNITDATA.DAT has to get loaded into the GE Mark V HMIs RAM to be effective--which effectively means one has to re-boot the HMI (after it was re-booted). It just wouldn't make any sense, on a lot of levels to execute MK5MAKE.BAT during a GE Mark V HMI re-boot.

So, something else happened that we don't know about.

However, if you're satisfied with the way the accumulator value is being displayed now, that's good! The values in the Mark V EEPROM haven't changed; if you monitor them with Logic Forcing you will see them incrementing as gas fuel flows into the turbine--and it's only CIMPLICITY that turns those digits from the Mark V memory locations into understandable engineering units--and if they weren't properly configured on the CIMPLICITY display from commissioning (which wouldn't be a surprise for GE Mark V HMI CIMPLICITY displays) that could explain what happened when you re-configured the CIMPLICITY display (and lost the decimal places for the gas fuel flow).

(In reality, I would refer to the gas fuel flow-rate as a totalizer, not an accumulator. I think of logic signals (like the number of starts or trips as values that are "accumulated" and total flow values derived from flow-rates as "totalizers." Just a small semantic thing; not really critical in this case.)

Hope this helps! I can't offer anything else in the way of explanation, and as long as no one has changed TOTT_Q.SRC and compiled it to TOTT_Q.AP1 and downloaded the change to the control processors and re-booted the control processors, then the actual values of the totalized gas fuel flow haven't been lost--even if the way they are displayed by CIMPLICITY has changed or is changed.

 

Thank you very much for your explanation,

"I also presume, trying to work David_2's information into the answer, that what happened is that the value in the 24th available accumulator memory locations grew so large they caused the sign bit to change, which caused CIMPLICITY to think the value had gone negative. That's about the only think I can think of."

*Yes we too think the same, is there any way to increase the memory to adopt for huge number?

For reminder, local HMI which is having old time stamp for UNITDATA.DAT, TOTT_Q.SRC also were reading negative.

As informed, both machines reading well in real format (cimplicity properties), if integer showing negative.

take care
g.rajesh