How to Decompile "ap1" Files in MARK V
- Thread starter Isulamu
- Start date
Isulamu,
GE did provide reverse compilers with the early Mark V operator interfaces (the ones called <I>, which ran the IDOS operating system) for the Table Files and CSP files, but they were frequently misused and caused a LOT of problems. So, when the change was made to MS-Windows-based HMI operator interfaces it was decided not to provide reverse compilers.
Wish the news was better. Perhaps if you could describe the issue you are having we might be able to provide an alternative or work-around.
GE did provide reverse compilers with the early Mark V operator interfaces (the ones called <I>, which ran the IDOS operating system) for the Table Files and CSP files, but they were frequently misused and caused a LOT of problems. So, when the change was made to MS-Windows-based HMI operator interfaces it was decided not to provide reverse compilers.
Wish the news was better. Perhaps if you could describe the issue you are having we might be able to provide an alternative or work-around.
CSA
thank you very much for your reply, actualy i'm not having a serious issue. but i'm working at a compression station where there are no "back ups" and the source files in the 'Unitn' folder i'm not sure have the same configuration as the one running in the controller.
So i want to make an upload and a reverse compilation to recover the last good configuration the turbine is running with.
thank you very much for your reply, actualy i'm not having a serious issue. but i'm working at a compression station where there are no "back ups" and the source files in the 'Unitn' folder i'm not sure have the same configuration as the one running in the controller.
So i want to make an upload and a reverse compilation to recover the last good configuration the turbine is running with.
Isulamu,
Great idea--but there are no tools to do that with.
When you uploaded the .ap1 files, they probably overwrote the ones on the GE Mark V HMI. I hope you made a backup of the existing.AP1 files before you started uploading; the one set of files that don't have .SRC files are the I/O Configuration files. The I/O Confihurator opens and saves to .AP1 files.
If you have the as-found.AP1 files before you uploaded the .AP1 files, you can use the DIR option of the EEPROM Downloader to list the sizes and file date- and time stamps of the EEPROM files and compare those to the as-found .AP1 file sizes and date- and time stamps. If any match then you can be very confident the as-found .AP1 files match what's in the Mark V. But if they don't then you're going to have some choices to make.
I was going to suggest you compare the uploaded.AP1 files to the existing .AP1 files using the Microsoft FC command line utility, but the more I think about it I'm not sure that would work--but it might. It's worth a try
The reverse compilers that were supplied with <I>s could not recreate any of the comments in the .SRC files it created (because comments aren't saved to the compiled files). Also, the CSP .SRC files that were created were not broken up into the original CSP segment source files, and, again all comments were lost. The reverse compilers were for last ditch disaster recovery--and because most people didn't backup anything before they started uploading and reverse compiling--well you can imagine what happened. EVERYTHING was overwritten and subsequently lost. It caused some very serious problems at some sites--VERY serious.
The two files that are the most important are the Control Constants and the CSP. I think there's a command line utility on the GE Mark V HMIs that can be used to compare the .SRC files (CONST_Q.SRC CONST_C.SRC) to what's in RAM and EEPROM in the Mark V. I can't recall the name of the utility, but I've used it and it worked well.
But, unfortunately, there's nothing similar for the CSP.
I think your biggest problem is the CSP--and that's not a trivial problem. Unfortunately, unless the file comparison thing works and the files are equal--or the as-found .AP1 files and the EEPROM files have the same size and file date/time stamp--there's no way to reverse compile the files.
When you upload the IOCFG partitions, as long as they have the proper names they can be opened with the I/O Configurator. So, they will have the current as-running I/O Configuration Constants. This one is easy.
The other table files aren't really critical, except for maybe MAOUT_Q.SRC (which I think is the one that assigns the <C> mA outputs (isn't this fun?!?!?!!). Maybe the timers and counters, but probably not. The BOI_x.SRC files were never <i>usually</i> modified in the field (though they usually needed to be). The HIST_Q.SRC file was sometimes modified in the field, but you can compare a Trip History printout to the .SRC file and make any necessary modifications.
Sorry; I wish the news were better. Please write back to let us know what you find and how you proceed.
Great idea--but there are no tools to do that with.
When you uploaded the .ap1 files, they probably overwrote the ones on the GE Mark V HMI. I hope you made a backup of the existing.AP1 files before you started uploading; the one set of files that don't have .SRC files are the I/O Configuration files. The I/O Confihurator opens and saves to .AP1 files.
If you have the as-found.AP1 files before you uploaded the .AP1 files, you can use the DIR option of the EEPROM Downloader to list the sizes and file date- and time stamps of the EEPROM files and compare those to the as-found .AP1 file sizes and date- and time stamps. If any match then you can be very confident the as-found .AP1 files match what's in the Mark V. But if they don't then you're going to have some choices to make.
I was going to suggest you compare the uploaded.AP1 files to the existing .AP1 files using the Microsoft FC command line utility, but the more I think about it I'm not sure that would work--but it might. It's worth a try
The reverse compilers that were supplied with <I>s could not recreate any of the comments in the .SRC files it created (because comments aren't saved to the compiled files). Also, the CSP .SRC files that were created were not broken up into the original CSP segment source files, and, again all comments were lost. The reverse compilers were for last ditch disaster recovery--and because most people didn't backup anything before they started uploading and reverse compiling--well you can imagine what happened. EVERYTHING was overwritten and subsequently lost. It caused some very serious problems at some sites--VERY serious.
The two files that are the most important are the Control Constants and the CSP. I think there's a command line utility on the GE Mark V HMIs that can be used to compare the .SRC files (CONST_Q.SRC CONST_C.SRC) to what's in RAM and EEPROM in the Mark V. I can't recall the name of the utility, but I've used it and it worked well.
But, unfortunately, there's nothing similar for the CSP.
I think your biggest problem is the CSP--and that's not a trivial problem. Unfortunately, unless the file comparison thing works and the files are equal--or the as-found .AP1 files and the EEPROM files have the same size and file date/time stamp--there's no way to reverse compile the files.
When you upload the IOCFG partitions, as long as they have the proper names they can be opened with the I/O Configurator. So, they will have the current as-running I/O Configuration Constants. This one is easy.
The other table files aren't really critical, except for maybe MAOUT_Q.SRC (which I think is the one that assigns the <C> mA outputs (isn't this fun?!?!?!!). Maybe the timers and counters, but probably not. The BOI_x.SRC files were never <i>usually</i> modified in the field (though they usually needed to be). The HIST_Q.SRC file was sometimes modified in the field, but you can compare a Trip History printout to the .SRC file and make any necessary modifications.
Sorry; I wish the news were better. Please write back to let us know what you find and how you proceed.
CSA
I really appreciate your detailed answer thank you very much indeed. for the DIR command its actually what i will be using in addition of CHECKSUM which i really cant make difference between both? as if they give the same results.
And in the other hand the result NO DATA for "data status" when using the CHECKSUM command means that file section(exp: BBL) in the eeprom has been lost?
ps: really sorry for my delayed reply
I really appreciate your detailed answer thank you very much indeed. for the DIR command its actually what i will be using in addition of CHECKSUM which i really cant make difference between both? as if they give the same results.
And in the other hand the result NO DATA for "data status" when using the CHECKSUM command means that file section(exp: BBL) in the eeprom has been lost?
ps: really sorry for my delayed reply
Isulamu,
I don't know how you compare the CHECKSUM of the EEPROM partitions to the .AP1 files.... I have used the EEPROM partition file data/time and size information from the EEPROM DIR output to compare against the .AP1 file date/time and size, and found that useful. (I'm referring to the as-found .AP1 file date/time and size, not the uploaded .AP1 file data/time and size.)
UBBL is for "User-defined BBL"--a way of being able to create site-specific BBLs (Big Block Language blocks) and download them to EEPROM and then make a reference to the UBBL in the CSP to use the UBBL. They were RARELY used. I'll bet if you look at the UBBL_x.SRC files you will see they are empty. I only ever saw UBBLs used on F-class machines with dual fuel and lots of special, site-specific sequencing--and only one time. Some F-class units could exceed the amount of RAM available for the CSP, and so UBBLs were used, because instead of writing site-specific logic using primitives and rungs, a call in the CSP to a UBBL would reduce the number of rungs significantly. (Using a UBBL, or any BBL, is like referring to a subroutine in many computer programming languages--you write a "call" to the subroutine to use it.)
I would think most of the other EEPROM partitions should have checksums.... And, that is UBBL was empty that wouldn't be too bad--unless your review of the CSP indicates a UBBL or multiple UBBLs were used.
Hope this helps!
I don't know how you compare the CHECKSUM of the EEPROM partitions to the .AP1 files.... I have used the EEPROM partition file data/time and size information from the EEPROM DIR output to compare against the .AP1 file date/time and size, and found that useful. (I'm referring to the as-found .AP1 file date/time and size, not the uploaded .AP1 file data/time and size.)
UBBL is for "User-defined BBL"--a way of being able to create site-specific BBLs (Big Block Language blocks) and download them to EEPROM and then make a reference to the UBBL in the CSP to use the UBBL. They were RARELY used. I'll bet if you look at the UBBL_x.SRC files you will see they are empty. I only ever saw UBBLs used on F-class machines with dual fuel and lots of special, site-specific sequencing--and only one time. Some F-class units could exceed the amount of RAM available for the CSP, and so UBBLs were used, because instead of writing site-specific logic using primitives and rungs, a call in the CSP to a UBBL would reduce the number of rungs significantly. (Using a UBBL, or any BBL, is like referring to a subroutine in many computer programming languages--you write a "call" to the subroutine to use it.)
I would think most of the other EEPROM partitions should have checksums.... And, that is UBBL was empty that wouldn't be too bad--unless your review of the CSP indicates a UBBL or multiple UBBLs were used.
Hope this helps!
I think the utility you are referring to is CONSTCHK.EXE which will give you the current values of constants in RAM, PROMs & CONST_Q. Very handy to run before downloading new software.
