MARK V IDOS not able to edit rungs and prom files

V

Thread Starter

VK

Not able to edit certain sequence of Mark V rungs in IDOS <I>, and it gives error as heap error. Same sequence segment rungs can be edited in another <I>. Why this is happening?

Also Is there any method/procedure to edit the BBL by editing the PROM files. Though a test case of PROM file modification was done and was verified in rungs, after downloading and rebooting, the rungs were not showing them(!). Any update in this.
 
You say the same segment can be edited on another <I>. Are the two <I>s using the same CPU (Central Processing Unit) with the same amount of RAM?

Sometimes, when a segment is very large (nebulous term, but this is Mark V) it can't be opened when IDOS is running, and sometimes when older <I>s have lesser amounts of RAM they can't open large CSP segments. The CSP Editor does not need IDOS to be running. You can exit IDOS, and then run the CSP Editor from the command line to open the segment, and it will usually work.

Now, as for editing BBLs. That can't be done. The information that's in the PROM subdirectory is only <b>ASCII text representations of what is coded in PROM</b>. Therefore, editing ASCII text files will have no effect on the PROMs coded into RAM, and can even cause serious operational problems. One should <b>NEVER</b> edit any file in the PROM subdirectory without instructions and/or assistance from GE to do so.

<b>Editing files in the PROM subdirectory without explicit instructions from GE to do so is not recommended, and can lead to catastrophic results.</b>

If you would describe the change you are trying to make, perhaps we could make a recommendation.
 
Thankyou CSA.

The <I>s mentioned are different, but on same stage link network for multiunit operation. As the old <I> have become obsolete mainly due to ISA slot for arcnet card, what we are using is PIV computer with ISA slot. RAM is same for all <I> like 256 MB, which I think is fair enough for similar old DOS applications. The segment is however editable in another <I>, but not in a particular <I>. An interesting fact is that when you delete some of the unwanted rungs (like text information, or unused rungs), the segment is getting opened in that particular <I> using MSE command.

You were mentioning CSP editor. Can you put some more on this. Can this be opened using f:\unitX directory? What is the command? Can it be useful for editing and be effective in later compilation for downloading. Another related question is how the CSP.prn is made? What command is required? Can it be done when unit is running?

The BBL mentioned has rungs related to TK fan cooling. If an additional fan is added for reliability and availability, these rungs are to be modified, but that was not working on trials.
We have tried in a spare system not connected to running units, and as it was not worked, reverted to old sequences. If GE not recommends it, we will not attempt them and will take the GE in loop.
 
Whether or not the <I>s are on the same StageLink or different StageLinks makes no difference at all.

IDOS was written for specific BIOSes, and different BIOSes use RAM in different ways. And, as was said before, when a segment is "too large" the CSP Editor, also known as the Master Sequence Editor can't load it because there's not enough RAM. You are very fortunate, very fortunate, indeed, that IDOS runs on a non-GE "certified" CPU.

EVERY application on an <I> can be executed from the command prompt (the "DOS prompt"). The Main Menu is nothing more than a "graphical" user interface for IDOS. You can exit to the command prompt of the unit-specific directory and type MSE at the prompt and press ENTER and the Master Sequence Editor will open, just like clicking on a "pick" on the Main Menu.

The Main Menu takes some RAM, and sometimes just exiting to the command prompt and opening the Master Sequence Editor will allow a "large" segment to be opened without an error message.

You can even open a specific segment from the command prompt. For example, let's say that you want to open segment LOAD.SRC. Exit to the command prompt, change to the unit-specific directory, and type MSE LOAD and the Master Sequence Editor will open and load the segment LOAD.SRC (note that it's not necessary to specify the .SRV filename extension).

And I'll say it again, the ASCII text files in the PROM subdirectory are only there to represent the operation of the BBLs that are coded into PROM in the Mark V. They are necessary for the CSP Documentor and Dynamic Rung Display to depict the operation of the BBLs. Changing the ASCII text files will not have any effect on the operation of the BBLs.

If there is only one sub-rung in a sequencing BBL that you need to change, you can insert a new rung immediately after the BBL, written as needed, and it will "overwrite" the BBL in the rung. (And saving the segment, compiling the CSP, downloading it, and re-booting the processors is still required!) You can actually do this for one or two or more sub-rungs in a sequencing BBL. However, if you need to rewrite several sub-rungs, it's best to just delete the entire sub-rung and re-write in individual rungs as needed.
 
I'm concerned that you might think that when you are opening a CSP segment with the Master Sequence Editor (CSP Editor) that you are opening the segment which resides in the Mark V turbine control panel. You are not.

You are opening the segment on the <I> which you are working at. And, when the "Total Job Compiler" is run, or when the CSP is compiled then all the CSP segments are 'combined' into a single downloadable Intel hex format file. The EEPROM Downloader is then used to transfer the file to the processors in the Mark V.

But, when you are opening CSP segments using the Master Sequence Editor, or using Dynamic Rung Display, you are *not* opening files on the Mark V via the StageLink. You are opening the ASCII text files on the <I> you are using at that time.

If the files on the <I> don't match what was downloaded to the Mark V you are monitoring/looking at/working on, then the information you will be seeing will be incorrect.

This is one of the problems with the Mark V turbine control system. If there are multiple operator interfaces (<I>s or GE Mark V HMIs) on a StageLink communicating with a Mark V turbine control panel, then if information is downloaded from one operator interface to the Mark V the files from that operator interface must be manually copied to other operator interfaces in order for all the operator interfaces to have the same information as was downloaded to the Mark V.

So, unless you are copying a CSP segment source file from one operator interface to another, you are not opening the *SAME* file on multiple operator interfaces, or not necessarily even the CSP segment file which was used to compile the CSP that was downloaded to the Mark V. There is *NO* automatic copying of files between operator interfaces via the StageLink, and even if the operator interface is connected to and communicating with a Mark V when you open a CSP segment source file with the Master Sequence Editor (or the CSP with Dynamic Rung Display) you are *NOT* opening any file on the Mark V, only the ASCII text files which are residing on the operator interface you are using.

It's seems confusing; but just remember: You can't see the CSP or CSP segment source files ON THE MARK V using the StageLink. And, files aren't automatically transferred/copied between multiple operator interfaces on a StageLink when they are modified; that has to be done manually. And, if you open a CSP segment source file on an <I> other than the one that was used to download the CSP most recently to the Mark V you may, or may not, be looking at the most recent CSP segment source file--unless you know that it was manually copied from the operator interface after it was used to create the download to the Mark V.

You can use an operator interface to see live values of Control Constants and live data values from a Mark V using the StageLink. But, when it comes to the CSP and CSP segment files, you can't use the StageLink to see the CSP that's running on the Mark V, or the CSP segment source files used to create the CSP that's running on the Mark V.
 
Thank you CSA.

We have a practice of updating all the multiunit <I>s, with the latest unit'x' files with zip, copy, transfer to other <I>s and unzip commands. Also we have a practice to take regular backup of Zip files (from unitx directory, runtime,). Also the eeprom download is executed only from that machine/unit dedicated <I> from where the modifications and compiling were taken. When we have problems, we copy the .src of seq file in other <I>, edit rungs, compile and then as a "better practice" copy the .src file to the original <I> before downloading from there. This is mainly done as a standard practice, and especially when new joinees are also being included in jobs.
 
Dear CSA,

I upgraded the DDRAM on the said <I>. It was 512 MB and another 128 MB was added. But same problem was happening while opening mse. One thing I noticed, is that when we delete some about 4-5 unwanted rungs (like user information header texts in the rungs), which occupy a whole ladder rung sheet), we were able to edit in mse.

Any further thoughts?
 
IDOS doesn't use extra RAM like other operating systems do. It's basically limited to the base 640K, and because you're probably running IDOS on a machine with a BIOS that doesn't use the base 640K the same way that the BIOS that IDOS was written for used it, then it's probably not going to work. (This is why one can't use memory managers with IDOS; IDOS doesn't use memory the way other operating systems do and can't make use of "extended" memory" like other operating systems can and do!)

That's why MSE works on one machine, and it doesn't on this one. The way the two machines use the base 640K of RAM is different.

You can also try this: Exit IDOS on the "<I>" which is giving problems by typing 'IDOSEXIT' (without the quotes) at any command prompt (and then press ENTER). Then try running MSE and see how that works. When you're finished, just type 'RUN_IDP' (without the quotes, and then press ENTER) to re-start IDOS. MSE doesn't need IDOS to be running to be used.

MSE doesn't have to run on a machine with IDOS on it. MSE doesn't even need IDOS to be running on the PC that it's being used on. You can copy the unit-specific directory (and PROM subdirectory) to any PC running a MS operating system and then copy MSE.EXE to the unit-specific directory, and you can run it without any problems to make any changes you want. Then copy the changed CSP segment source files back to the <I>s and you're done.
 
Hello ! We have a F6 mark V <I> TMR. Using the tool Sequence Editor on MKV, we edited a contact what it needed be changed (from NO to NC in the rung of PSS system) , after we performed the mkvmake and the eeprom downloader. All went smoothly till we realized we had an alarm of the 59B (on C core) . We checked the rung and surprisingly the coil of the alarm (L59B_alarm) it’s excited but its contact (L59B) it’s Not picked up! So far it’s the only anormal thing we saw after the downloading. We rebooted again the cores (Q and C), but no changes.. we forced both coil and contact .. still the same. Have you ever experienced something like that? Thanks in advance ! ( we have an additional interface TMOS apart from the <I>)2F726E12-B132-4FEF-8F30-B7912F51BAAE.jpeg
 
Hello !

My first question would be ...did you used /performed Sequence compiler ( by entering COMP_SEQ command...at teh command line ) of the unit specific directory ....

Thanks for clarifying..

James
 
Hello James! Thanks for replying, we didn’t create a new rung we just modified a contact on the rung PSS ( which works perfectly),, but it happened we got that inconsistency on the rung of 59B.. in which we never worked... thanks
 
Hello WalterCTPL2019

Hum you "modified a existing rung " right?

I am waiting for the input on that 59B functionnality/origin...to add comments..

Plz tell us origin of the contact and is relationship to PSS...

There could be mismatch somewhere in the loop! or other origin on this issue...

Do you know about Mask/invertion signal ... is that needed here...we dont knwo since we do not have enough datas togive notes...

Looking for your inputs,

James
 
WalterCTPL2019,

How many operator interfaces do you have on site, and which one did you use to make the change?

Which HMI did you use to observe the state of the rung L59B_ALM?

Have you looked at the state of L59B using the Logic Forcing display? If so, what was it when L59B_ALM was a logic "1"?

Is L59B used anywhere else in the CSP in addition to L59B_ALM?

Rung Display DOES NOT look at the actual CSP running in the Mark V. It looks at the CSP source segment files on the operator interface on which Rung Display is being used. So, if you used a different operator interface to look at the rung you modified on another operator interface, and you didn't copy the CSP segment source file you modified to the operator interface being used to view the L59B_ALM, it's not going to show the proper information.

This is a huge problem with Mark V operator interfaces--the files on ALL operator interfaces have to be the same after any files on one operator interface has been changed. That's difficult to describe in one sentence. And, it's difficult to implement on most sites.
 
Hello James! Thanks for replying, we didn’t create a new rung we just modified a contact on the rung PSS ( which works perfectly),, but it happened we got that inconsistency on the rung of 59B.. in which we never worked... thanks
WalterCTPL2019,

How many operator interfaces do you have on site, and which one did you use to make the change?

Which HMI did you use to observe the state of the rung L59B_ALM?

Have you looked at the state of L59B using the Logic Forcing display? If so, what was it when L59B_ALM was a logic "1"?

Is L59B used anywhere else in the CSP in addition to L59B_ALM?

Rung Display DOES NOT look at the actual CSP running in the Mark V. It looks at the CSP source segment files on the operator interface on which Rung Display is being used. So, if you used a different operator interface to look at the rung you modified on another operator interface, and you didn't copy the CSP segment source file you modified to the operator interface being used to view the L59B_ALM, it's not going to show the proper information.

This is a huge problem with Mark V operator interfaces--the files on ALL operator interfaces have to be the same after any files on one operator interface has been changed. That's difficult to describe in one sentence. And, it's difficult to implement on most sites.
CSA.

1-We have 2 interfaces on the TG1, the TMOS HMI (where we did the changed), and the original <I> DOS
2-we used the HMI TMOS to check the changed in the coil L59B_alm, but we verified on both interface all’s and it’s the same.
3-yes we used the logic forcing, L59B_alm is a logic 1 and L59B is logic 0. (On both interfaces )
4- no, L59B is only used in the rung of L59B_alm

Basically what we have done was the following:
1- we changed a contact of the PSS rung (power system stability) from NO to NC by the Sequence editor tool.
2-we performed a TMOSMAKE (MKmake equivalent)
3- then We did the EEPROM download from the TMOS interface
4- we rebooted the Q cores and verified that the contact (L83PSS) was responding to the change
5- then came the problem that we got the alarm L59B_alm, which we never tried to modified, it’s with the the L59B logic 0 and its coil excited (L59B_alm)logic 1
*We performed all that form the alternative interface TOMS, but never from the original <I> , could be this the problem ?* Thanks in advance
 
Well again you did not provide explicit datas on your first post.. But it's OK.!

You did not say that you changed existant contact from NO to NC..

Looks like in the screens hot that you shared the contact is NO..
Maybe control system still looking at 59B wrong contact assigned...
 
Top