Dear Mr. Markvguy,
I have setup one trainer in Lab with the below configuration.
But the trainer shows the following status on C core in IO_STATUS of 186 MONITOR onLCC Display
DCC-00
LCC-A4
TCC-A4
IOMA-A3
Trainer is in A4 mode(both cores).

I just know that DCC-00 means it is unable to communicate with the card. I've checked the power cables also the ribbon cables are new(almost all the material i.e cards, proms, cables used are new). What could be the problem?Is there any parameter settings required?

We have been trying to solve this problem, but its not coming up. Your help would be highly appriciated.

Thanks.

 

Hello, and welcome to the forum.

This author's guess would be that something is amiss with the EEPROM chip, U9, on the DCC/SDCC card. Have you tried downloading FORMAT to the processor(s) (the processors will only go to A4/A5 after a FORMAT) and then re-booting, then downloading ALL to the processor(s) and then re-booting?

Remember, for <C> to reach I/O Status A7 <R> must go to I/O Status A7 first.

Write back and let us know how you fare! Feedback is out most important contribution here!

markvguy

 

Hi,

For R core,
DCC-00
LCC-A4
IOMA-A3

Since IOMA is A3 mode, we din't get arcwho also. So we couldn't do FORMAT.
The trainer shows Default system.

Since we are using the new cards, do you still think that there can be problem with the U9 EEPROM chip?

Let us know soon.
Thanks.

 

Ah, yes; it would be difficult to download if the DCC weren't communicating....

In the first post you said the <C> processor DCC was at 00; in this post you say the <R> processor DCC is at 00. Has the <C> processor DCC changed state?

Yes, the U9 EEPROM chips have been known to be DOA (Dead On Arrival)--it's not common, but it has happened.

The <I> (or HMI) doesn't communicate with <R>--it communicates with <C> (that's where the StageLink cable is connected). The <I> (or HMI) can communicate with <R>--but only through <C>. You have to establish StageLink communications with <C> (which has to have its StageLink ID set via the LCC/SLCC keypad).

The 3PL cable connects the LCC to the DCC to the TCCA (in <C>) and to the TCQA in <C> (the trainer needs the TCQA in <C>, doesn't it?) At any rate, the 3PL cable is pretty important, and it has been known to be problematic; sometimes all it takes is just to press firmly across the plastic strip of the ribbon cable connector while it is plugged into the receptacle on the card. If the LCC can't communicate with the DCC, this could well be the problem.

When you install a new DCC/SDCC card with a new EEPROM, you have to use the LCC/SLCC display and keypad to tell the DCC/SDCC which core it is. Have you done that? Does <C> LCC display show <C> or <B> when you press the NORM key on the LCC keypad?? Does the <R> processor display <R> or <Q> when you press the NORM key on the LCC keypad? (If <B> and/or <Q> is displayed, then the DENET Voter IDs haven't been set, and it's asafe bet the StageLink ID of <C> hasn't been set either.)

Press the DCC key in the upper left-most corner of the LCC keypad on <C> (186 Monitor should be displayed) and then press the INC key at the bottom of the keypad until 'Stage Link ID' is displayed and then press ENTER. Then key in the Stage Link ID of the <C> core (usually FE for trainers--but it must match the value in F:\CONFIG.DAT) and then press ENTER (the display should respond with 'OK FINE'--isn't that just too cute?)

Press the DCC key again, and press INC until 'Voter ID' is displayed, then press enter. Press the C key and then press enter (the display will flash 'OK FINE' again--isn't this fun?) Then reboot <C> FROM THE SWITCH IN THE <PD> CORE.

Next, press the DCC key on the LCC of the <R> core ('186 Monitor' should be displayed) and press INC until 'Voter ID' is displayed and press ENTER. Press R and then press ENTER (the LCC display will flash 'OK FINE'--those design engineers are just so clever!). Then re-boot <R> FROM THE SWITCH IN THE <PD> CORE.

When you said in your posts the <C> and <R> processors, it was presumed you had set the DENET Voter IDs of the DCC cards and you were seeing <C> and <R> in the LCC displays of the respective cores...but presumptions can be misleading. Just putting a DCC in the space for <R> and putting a <Q> PROMs on the card doesn't tell it which processor it is; it has to be told via the LCC keypad. Same for <C>.

If the above doesn't work and you have other trainers or Mk V panels, can you try exchanging parts/cards, one at a time, until you either have a non-communicating trainer that was working or a working trainer that wasn't communicating? Just be very careful when unplugging the 3PL cables! They have no pull tabs, so you must use a finger under the loop and pull gently up with pressure all along the length of the cable connector--or the connector can be easily separated from the ribbon cable's conductors. Those cable-connector connections are just press-fit.

Please be patient--we will solve this problem; just write back and let us know how the troubleshooting is progressing.

markvguy

 

Dear Markvguy,

We got the solution of our problem! It is with the U9 chip on DCC card. We replaced all the components one by one with the older working trainer. When we changed the U9 chip from the older trainer, the new trainer started working. But now the old trainer has the dead U9 chip.

Now our problem is to get the old trainer work. How can we get the U9 chip active? Because now, at a time we can use either the new trainer or the old trainer.

Regards,
Ki

 

Good news! Any chip can fail at any time, and the U9 chips have been known to fail on power-up on occasion.

They are nothing special, a standard EEPROM chip. You could take the information from the chip (manufacturer, part number, etc.) and purchase a new chip from some on-line source, or perhaps you have shops in your location which sell components.

Thanks for the feedback--it's the most important contribution here on control.com! It lets other readers, now and those who use the very powerful search feature of control.com to know what has worked when troubleshooting and what has not.

Don't be a stranger to control.com! There are lots of people here with tons of experience in many areas of control and automation--and we're always looking for more people with Speedtronic turbine control experience.

markvguy

 

Might you know where I could view a MKV Trainer manual?

 

TheGingerbeer,

There are Mark V trainers, and there are Mark V trainers. Most people refer to a "spare" Mark V panel in a lab or building as a "trainer" because, if it can be powered-up it can be used for testing purposes, and even some training.

GE did manufacture a Mark V "suitcase" trainer--which was housed in an aluminium attaché case, and consisted of a minimal <R> and <C> processor, and was usually provided with some kind of operator interface (an <I> or a GE Mark V HMI). Those sometimes did have a specific manual provided with them, but it was only about how to properly power-up the suitcase trainer and establish communications with it using the provided operator interface.

Something GE didn't do--as a product option--was provide Mark V software (primarily the CSP (Control Sequence Program)) that would simulate the site's turbine operations. Yes; they did have a couple of CSP simulators (a Frame 6B I think, and a 7F if I recall correctly)--but they were very generic in nature. All they allowed a user to do was initiate a START, which would result in a sync (of a generator drive unit), and loading and unloading and shutdown to COOLDOWN operation.

They had a real opportunity to have made a simulation that would simulate things like high exhaust temperature spreads or wheelspace temperature issues or high atomizing air temperature--real-world problems--so that the use could experience what it might look like and learn what actions to take. But, alas; that opportunity was squandered and lost. The software GE provided was useful in observing what would happen during a "normal" START, and during normal loading and unloading, and during a normal fired shutdown--good things to observe and become familiar with, but boring and not very instructive when it comes to learning how to respond to alarms and how to troubleshoot alarms and improper operation.

I don't recall what the GE publication number was for the suitcase trainer. For the times when that software I mentioned was provided (for typical STARTs, loading/unloading, and fired shutdowns) I never saw any document or publication for how to use it.

Most "trainer" panels just become parts sources--when a card seems to need to be replaced in a working Mark* it is "borrowed" from the "trainer" rendering the "trainer" useless. Rarely, does the borrowed card get replaced, so a working "trainer" is usually rendered pretty useless--except for spare parts--fairly quickly when this starts happening (borrowing cards from the "trainer" to try to repair a Mark* running a turbine).

If you can be alittle more specific about what you're looking for, we might be able to help. Again, I don't recall the GE publication number for the suitcase trainer, but I do know it wasn't very useful or informative.

Hope this helps!!!

 

Many thanks CSA. I've used the suitcase trainer many times and did write a number of simulations for frame 5 type start and operations. That was a good few years ago and not working with MKV on a daily basis most of the "tricks" are loat or exceedingly rusty. The trainer manual was GEI -100157A I believe. Main use was to establish the minimum card set in a Q processor to help fault finding on a remote site. On this site the <S> processor had developed a fault and my colleague an I were challenged with best remedy. Based on the description form the client, the fault was considered to be power supply or comms. The panel is around 20 years old now and could be having card component issues. We have replaced all cards on <S> in doing so the U9 RAM chip was moved across from old card to new (might be a contributor)
Synopsis of history
About 6 weeks ago <S> processor raised some alarms (sketchy report from site), manually rebooted and ended at A4. Client replaced TCPS and was OK for 2 days, then an auto reboot occurred itself and A4 achieved. Old power supply card re-fitted and A7 achieved.
We are now on site and have replaced the following - mainly because most expedient and addresses some communications alarms

• all <S> cards replaced with remanufactured (U9) moved from old to new

On first boot <S> stalled at DCC Stall Test. Three further reboots were attempted and a7 was achieved. After 5 minutes the processor self rebooted and stalled at DCC test

New ARCPL cable installed and NYOGEL applied all connections in the processor.

<S> Processor switched on and booted to A7 first time and remained at A7 for 12 hours when several successful soft and hard reboots were performed without any issues.
<S> Processor switched on and booted to A7 first time and remained at A7 for a further 14 hours.

<S> Processor switched off to install new JGT cable from TBQB to TCQC card.

Switched on <S> Processor - Boot-up stalled at DCC Stall Test
<S> Processor switched off and DCC cables disconnected and reconnected
<S> Processor switched on and booted to A7.

After 2 hours the processor generated errors displayed on the LCC display with several cards dropping to A2 status although the processor remained at A7.
TCD1, TCD2, IOMA and TCE1 dropped to A2 while TCQA, LCCq, DCCq, stayed at A7

We cant replicate the fault by wiggling cables, so are beginneig to think that the U9 RAM chip may be to blame. There is another one available so we may change it out.

Other things we are thinking about to see if we can gat the fault to move and thus become identifiable is
swap power supply cables over at <PDM>
swap local processor cables
7PL SDCC to TCQC
6PL SDCC to TCQC
8PL SDCC to TCQC
1PL SDCC to TCQC
JC TCPS to TCQC

We do not suspect the replacement cards or power supplies as they have been replaced and the faults we are seeing seem somewhat similar to those described by the client

Is there any history of this happening before?

My question - although still pertinent was to establish the minimum card set needed on a <Q>, cable that up, declare the configuration in IOCONFIG, only cable up those cards and watch for stability. I'm puzzled though as TCD1, TCD2, IOMA and TCE1 all dropped to A2. But perhaps the answer lies in moving cables from processor to processor now and observing.

Any assistance gratefully received -

 

The GingerBeer,

I don't really understand the attachment....

The thing that jumps out at me is that the cards which dropped to A2 are all on <S>'s IONET (well, except the IOMA, which may well have gone to A2 because it deals with the external processor I/O card--I don't recall, and the IOMA is really not a card, but the i80196 chip on the DCC/SDCC card--if I recall correctly). The <S> IONET passes from the TCQC (if I recall correctly), to the TCEA in Loc. 3 of <P>, and then to the TCDA in Loc. 2 of <QD1> and to the TCDA in Loc. 2 of <QD2>. I have seen some unusual problems caused by incorrect placement of Berg jumpers for the IONET termination resistors on the TCDA cards, and if I recall correctly there are possibly IONET termination resistors on the TCEA cards as well. I went to a site once where the report was that <T> had just started "throwing" Diag. Alarms and wouldn't re-boot properly (similar to what you are describing), and it came out after four days of troubleshooting that site personnel had replaced the TCDA card in Loc. 3 of <QD1> and hadn't put all the Berg jumpers in the correct positions; they thought all they had to do was swap the PROMs from the old card to the new card and all would be okay. It worked sometimes, and not others--similar to what you are describing.

I also had a VERY ODD problem with a <P> core once, Diag. Alarms associated with a TCEA card, and it turned out the problem was the IONET cable connections were bad on BOTH the TCEA and the next TCDA in the string.

As you say, there's been a lot of water under the Mark V bridge since 1991, and even a few droughts, and I don't have access to the App. Manual right now so I can't check to see what Berg jumpers do on the TCEA card.

Unless the EEPROM chip (U9)has been downloaded 100's or 1000's of times and/or the panel has had serious ground problems over the years and/or has been the victim of serious electrical storms/lightning strikes it's not likely--but not impossible--that it's the U9 chip. And, every DCC/SDCC card should have its own U9 chip also. When replacing DCC/SDCC cards, if I don't swap the U9 chip when doing so, I usually FORMAT the EEPROM chip (U9) using the EEPROM Downloader, and then immediately reboot the processor (HARD reboot from the <PD> core). Then I download USER using the EEPROM Downloader, and again perform a hard reboot of the processor from <PD>. I know--USER does not include the Totalizer data--but, in about an hour the Totalizer data from the other processors will be used to populate the Totalizer data partition in the newly formatted EEPROM (U9) chip and all will be good. (The only reason for swapping the EEPROM (U9) chip is to prevent having to do any uploads or downloads; and I try to do that as much as possible.)

As for the minimum complement of cards for a control processor, I think that's an LCC/SLCC and DCC/SDCC combo, and if I recall correctly a TCQA and possibly a TCQC (some early versions of Mark V panels/PROMsets didn't require the TCQC, but I think the later ones did, or maybe that's vice versa.... Long time....).

Remember, not all of a processor's cards are in the processor--and for a control processor, that means its TCEA is located in <P>, and its TCDA(s) are located in the <QDn> core(s), and are connected to the processor via the IONET cable. (I have also seen an IONET cable that was pinched in the <P> core and had exposed wire strands and that was the source of one problem. I have been told stories of IONET cables that were nearly cut in two, with only a couple of stands of wire performing the comm's. I have also seen the pin receptacles in the IONET cable end connectors have really poor crimps and cause problems--that was a tough one to find.)

You might consider trying to swap cards from <S> to <T> one at a time and seeing if the problem followed the card.... Time-consuming and a lot of work, but it might be useful. And, I wouldn't limit that to just the cards in the <S> processor (again, the problem could be in the TCEA or TCDAs if the problem is along the IONET.)

A lot of people seem to be having problems these days with TCPS cards--and it's probably just component age at this point.

Also, if the panel hasn't had good housekeeping and the room where the Mark V is located hasn't had its air conditioners properly adjusted or not working for extended periods of time, it could be a good cleaning is in order.

Finally, I had one odd problem many years ago where <S> processor would do some very odd things.... The problem was ultimately traced to cold air from an A/C vent blowing through the vent openings on the top of the Mark V panel door onto the <S> processor (primarily) and causing very strange things to happen. I put a piece of cardboard over the vent openings for a couple of days and the weird problems stopped. I/WE had replaced several cards, some several times (suspecting the spares were bad), and still we would get odd, and different problems at odd times. Turns out it was usually during the heat of the day when the A/C was running fast and furious and blowing really cold air into the Mark V. (I found that problem by looking at the T/C Cold Junction Temperatures of the individual control processors and noting that <S>s was about 15-20 degrees colder than <R>'s or <T>'s. I don't know why I checked, but in hindsight it was a good thing!)

Hope this helps!!!

 

While it may be time-consuming, if you swap individual cards one at a time for 24 hours between, say, <S> and <T>, and the problem stays in <S>--then that tells you it's something in <S> or on the DENET or IONET connected to <S>. On the other hand, if the problem moves to another processor, well, then likely says it's a particular card, or maybe the ribbon cables connected to the card.

So, now we have one poster named glemorangie (a Scotch whiskey), and another named TheGingerbeer....

 

Sorry for the attachment - it should not have been there and I have removed it. Many thanks for your response. Ill discuss it with my colleague who is on site and we will try to produce a planned approach. I will of course let you know the outcomes, whic I trust will be positive. Interestingly though the site is in an area which can produce some prolonged and occasionally violent electrical storms. I would not be surprised if this has softened a number of components there.

 

Glenmorangie I can understand - being Scottish. theGingerbeer - Engineer- comes from my days in the middle east as a TA many moons ago - even in the times of MKI and even some old LA work with the beautiful electro hydraulic / pneumatic governors

 

Perhaps our paths have crossed - I was frequently in Salem and Schenectady, latterly once or twice in Greenville and Atlanta and Loveland. Most of my years on Gas Frames 3 to 9, most varieties, most fuels. Wsa in the field, and latterly in design then Plant Assessment.

 

Good Day CSA,
Apologies for the delay in providing a solution to the issue. We were faced with swapping cards / cables one at a time, or replacing with new and monitoring, probably over many days, which was not a timely solution. We opted to replace all cards and cables on the misbehaving processor. This was a fast turn round type solution which resulted in curing the original problem. Now there is a DCC/LCC issue, however that is manageable in time. Thanks for your help.