Hi Friends

I need guidance to resolve the problem occurred at node communication of PCU, which caused the loss of redundancy and give alarms (yellow) frequently and reset itself after few seconds, alarms given below

PCU13Node00 status PCU#13.00 AL

PCU13Node01 status PCU#13.01 AL

I have observed from local LED’s on NIS and NPM there is no any change at the time of alarm set or reset but standby NIS LED’s changes after certain time

Primary NPM LED 7 and 8 ON and NIS LED’s 1 to 8 blinking continuously other 1 to 8 ON and OFF instantly

Secondary/ Redundant Pair has been observed following change in LED display

Secondary NPM LED 8 is ON and NIS LED’s 2, 4 5, 6 and 8 ON continuously other 1 to 8 LED’s OFF

Secondary NPM LED 8 is ON and NIS LED’s 1, 3,4,5,6 and 8 ON continuously other 1 to 8 LED’s OFF

Secondary NPM LED 8 is ON and NIS LED’s 1, 5, 6, 7 and 8 ON continuously other 1 to 8 LED’s only 2 is ON.

I hope your assistance will help to know that either this alarm appears due to NTCL01, Cables, MMU or any other cause for this alarm.

While from EWS we click report ---status and we don't get GOOD status of NIS(Loop) relay transistor#2..

Now one thing other observed in PCU Power Entry panel (NPEP0) status LED started changing color from green to yellow and Red (blinking) but behind the PCU Supply 1&2 status is OK and no any alarm appeared on HMI..but in past if we get red status we receive an alarm.

Thanks in advance

 

Ashiq,

Your NIS/NPM's are not the problem - all are working as they should, however you have a problem somewhere in your power system, possibly a fan or a cabinet temperature alarm, or even an intermittent power supply module.

You see all as good (in your status report from Composer) because the problem is only intermittent; those reports are like an instant 'snapshot' so it's unlikely it would capture it if the fault is only there for a few milliseconds.

Listen to your fans - are they noisy?

I don't know what kind of power system you're using there, but it seems that you have either a very early Network 90 power supply (It would have two NPSM0x) or maybe you have the early Infi90 supply where you have several IEPAS02 modules mounted either at the top of the cabinet, or if an older rev, they will be distributed in the same MMU's as the other modules (and this arrangement was VERY unreliable, thus I'd say its unlikely you would have that type).

If you DO have the old Network90 style (you mention 'NPEP0'), you could find there is an intermittent fault in the NPEP0x itself (normally NPEP02).

To fix that, you will need some offline time and remove the NPEP0x. With a screwdriver, tighten all of the connections, also make sure that the 'spade' lugs are all nice and tight.

With those old PEP0x's, the connections can work loose after a few years with vibration and you will see errors like those you've described.

Once you've tightened all of the connections, you'll find it will be ok.

Hope this helps?

 

Dear Mr. Anthony

Thanks a lot for your guidance..yes it is true we have very old power supplies installed and i am in process of replacing them with new MPS-III.

One thing i have observed may give better idea about the issue when i insert the NPM or NIS in MMU PEP LED turns to red, does it means that some thing is wrong with MMU slot, because supply voltages i have checked and tighten the connection every thing looks normal
can i go for replacement of MMU?

Plz advise thanks

 

Hi Ashiq,

I wouldn't go quite that far yet, unless you have no spare slots in another MMU above or below the MMU you suspect is faulty. First of all, have you tried replacing the NIS and NPM modules with ones that you know are OK?

If you have tried replacing both with known good ones and your PEP Status still goes red, the modules are not the culprits.
Also you haven't mentioned whether or not you have redundant NIS/NPM's. If you do have redundancy, you would have 2 x NIS & 2 x NPM, thus 4 MMU slots; but only 2 slots if you don't have redundancy.
Remove the NIS/NPM's and remove the NKLS01 cable(s) at the rear of MMU and insert the cable into a spare MMU slot above or below the suspect MMU.

(NOTE: it can be anywhere in the MMU - it doesn't have to be in slot 11 & 12 or 9,10, 11 & 12 if redundant. Wherever you can put the modules, just make sure there is a 12 pin dipshunt between the NIS & NPM pairs - look at the existing MMU backplane and make the trial slots the same. Also make sure that the last 12 pin dipshunt BEFORE the first NIS is removed to isolate the NPM from the slaves that are most likely in the MMU).

If / When you find 2 spare slots and the NKLS01 cable is attached to the backplane of the MMU in the corresponding slot for the NIS, insert the NIS /NPM modules. If the PEP status LED remains green, the MMU is for sure the culprit, if it again goes red, the MMU is not the problem.

Did you check the supply voltages when the PEP status LED is red?
If after trying the NIS/NPM's in spare MMU slots and PEP status still goes red, check all power supply voltages again - with PEP LED red.
If any are LOW, it could mean a faulty PSM0x or a faulty component in the PEP itself.

I suggested tightening all the connections in the PEP assembly as this was a common problem with them, but it wasn't always the solution!

You may still have a faulty component on that PC board inside the PEP...

Anyway, try what I suggested above regarding verifying whether or not the NIS or NPM modules are faulty and whether the MMU where they normally reside is faulty, by trying the same modules in a different MMU - if you can.

If you don't have any spare MMU slots in MMU's near the one you suspect: replacing the MMU would probably be your only option.
I suggest you try the NIS/NPM in a couple of spare slots just to save you time (and hard work)...

Good luck with it.

Cheers,
Anthony

 

Dear Anthony

Unlucky i have no any spare slot in the PCU while we have redundant NIS/NPM..one pair is working fine and installed in slot 3 and 4, slot 1 and 2 have problem.. i have shuffled NIS and NPM but in slot 1 and 2 both pair had same behavior that's why i diverted to MMU, Cables and Power supply.

when i will get opportunity because plant is operating now i will rectify this problem in the light of your guidance

so nice of you

thanks

Regards
Ashique Ali

 

Hi Ashique,
Hmmmm, interesting...

Maybe nothing though, could be a misunderstanding, of the slot numbering (positions).

It is most unusual to locate the NIS/NPM modules in slots 1&2 / 3&4. Normally those first two slots are where you situate your IMMFP0x, BRCx00, IMMFC0x or if your system is older: slots 1&2 / 3&4 could accommodate older NMFC01, NMFC02 or 03 modules. (NMFC01 /2 /3 are a 'double board', thus double slot module), therefore they would typically reside in slots 1&2 (N) and slot 3&4 (N+1) where N is the module address and N+1 is the redundant module address.

NOTE Slot 1 is the FIRST slot on the left of the MMU when viewed from the FRONT of the cabinet (front of MMU). The front being the side where you insert the modules (the rear is where the cables are).
Thus slot 12 is the last slot - at the right hand end of MMU. Numbering of slots is from left to right, when viewed from the front of MMU or front of cabinet.
[I hope this doesn't appear ridiculous, but I want to make sure we're on the SAME page here]

Normally the NIS/NPMs occupy slots 11&12 (NIS in slot 11, NPM in slot 12). If your system has redundancy as yours does, the NIS/NPM's would normally reside in slots 9&10 / 11&12. That is the last 4 slots at the right hand end of the MMU when viewed from the front.
Thus slot 9 should have a NIS and slot 11 should have a NIS and the NKLS01 cable of course should also be connected at the rear for the NIS's.

Slots 10 & 12 would each be occupied by NPM modules. Because your Infinet is redundant there must also be an NKMP01/002 (short) cable connecting the two NPM's in slots 10 & 12.

ALSO: check the MMU backplane: the 12 pin dipshunts (you can only see these from the front of the MMU therefore you must remove modules to access them). There must be a 12 pin dipshunt between each NIS and NPM. The NIS/NPM pairs use the expander bus to communicate.
There must be a dipshunt between slots 9&10 and a dipshunt between slots 11&12 but NO DIPSHUNT between slots 10&11 ! VERY important!
Also there should be no dipshunt between the LAST slave module's slot in the MMU the slots the NIS/NPMs occupy. I.e. if there is a slave module in slot 8, make sure there is NOT a dipshunt between slot 8 and 9! (9 being the slot position of the first NIS module of the redundant set of NIS/NPM's).

However in your case: (where you have the unusual arrangement with NIS/NPMs in the first 4 MMU slots, rather than the standard layout with them in the LAST 4), ensure there is NOT a dipshunt AFTER the second NPM. Or, simply: Make sure there is NO dipshunt between slot 4 & 5 in your MMU backplane, assuming any of slots 5, 6, 7...12 are occupied with slave or other modules.

Also: check that there IS a dipshunt between slot 1&2 and there IS a dipshunt between slots 3&4; but there IS NOT a dipshunt between slots 2&3!

You should have an NKLS01 plugged into slot 1 (first NIS) and an NKLS01 plugged into slot 3 (second NIS). You must also have an NKMP01/002 (short) cable connected between slots 2&4 to connect the two NPM's.

I shall assume at this stage that you have the correct dipswitch settings on all of your modules for redundancy. If any of those are incorrect (especially the NPM switches) you will experience behaviour similar to that you've described...

If all of this checks out correctly, continue with checking what I described in the previous post...
Please let me know when you have a win!

 

Dear Anthony

We win and resolve the problem in opportunity of plant outage i replaced older power supply with new MPS-III and communication of PCU is normal now.
while thanks a lot Anthony your information was very helpful and hope we will be touch.

cheers
Ashique Ali

 

Dear Anthony

I am experiencing almost same kind of problem in which loop communication of the cabinet is discontinued from other PCU's.

This situation arises after almost every 3 to 4 months. It causes a total black out of the said PCU. After some time(1 to 2 minutes) the communication is again established automatically between the problematic PCU and other PCU's.

The NIS and NPM show no error signal or indication of faulty loop. I cannot find the root cause of the situation i am dealing with. We have got Installed MPS-III which was upgraded from PAS in 2008.