We have an NEC2400 system. Lately been getting frequent minor alarms. Alarm display print out states "PLO Failure" on both the standby and active units. Does anyone know what is causing this and what should be done?

I would double check the punch down x-connect from the PRI/T1 card to the Clock card.

D

Have you checked the details rather than just the summary? All that hex can help point you to the right card/s

Will check x-connect. This is the code from one of the failures: 04 00 04 0E 00 00 00. Can you tell me how this code relates to the card position in the stack? Also, some back story info on this, these errors started after Verizons cable got wet and caused lots of outages. Would you suspect this problem is being caused by shorts in the cable or is this likely to be a problem in the our pbx?

Sorry

Don't have a manual available at this time and I have never tried to memorise the way of decyphering it. If I can get to the office I will see what I can do. I will get back to this even if you resolve the issue in the meantime as it would be a good exercise anyway. Assuming I can find it in the manual!

Ok so two digit hex numbers......

If we number them 1 to 7 from left to right, we are interested in the 4th 5th and 7th groups.

7th =00 which points us to PLO1

4th = scan data 1 and we have to convert it to binary = 00001110

This time bit 0 is on the right and 7 on the left.

b0: Clock status at time of detection
0/1 = STBY/ACT
b1: Circuit card at time of detection
0/1 = PLO synchronizing/PLO Self running or drifting
b2: 0/1 = -/Input clock down
b3, b4:Route of Input clock

b4. b3. DCS INPUT ROUTE. ROUTE OF INPUT CLOCK
0...0..........0..................0
0...1..........1..................1
1...0..........-..................2
1...1..........-..................3

Next another convert to binary for the scan 2 info in hex group 5 but as it 00 the binary will be 00000000

As with the scan 1 binary, left to right

b0: 0/1 = -/Five millisecond Burst Clock down
b1: 0/1 = -/Frame Synchronization from SYNC card is down
b4: 0/1 = -/Internal OSC clock down

So we don't get anything from that!

And that's about as much as I can help, hope it's enough!

Note

Edited as when posted all the spaces that I used to make the table work disappeared so I used full stops instead!

Thank you, that is an impressive piece of decoding. These errors are occuring along with a "ccs link failure" which appears to be a protocol for reporting load status info between switches. Spoke with Verizon who states that their switch is reporting the "time is slipping" on the connection between our stack and their switch. Their switch then locks our trunks out. My question is, if this is a hardware issue with our stack, what would it be? Is it a clock card or something that handles the timing? Problems like this used to be handled by a service contract which had to be cut due to budget constraints. We are very limited in our tecnical ability with this equipment. It is probably time to bring someone in on a time and materials contract, but I'm hoping to be armed with some info for discussing this with those who hold the purse strings.
Thanks for your help.

Just a note,

I got right and left mixed up in the scan 2 section. Binary always counts from right to left as it is a number!

The cancellation of your maintenance contract may be about to bite you back. The card cost may well be thousands and then there is the labour! It may be worth negotiating with a company to give you a discount if you take out a new contract!

Plo in the telephony industry usually stands for Plant Lock Out this usually occurs when there is a cableing short or a short on the equipment from the telecom provider. It also occurs when a telephone does not have a cut off on disconect feature either in the dms programing from the telecom or in the end user key system. In your case I am going to go with the water getting into the plant lines creating a short causing the lines to go into a PLO state.

phase loop oscillator

I'll say no more!

Card position, i.e. which card goes to which pair, is slightly insane.

It should have -- trying to remember here -- a six-digit number. First digit pair is F/W processor, which is half of a cabinet (i.e. 2 shelves, 1 door). Second 1 digit is half of a shelf (0-3), next two are half of a card (00-32), and the next digit is the circuit (1-8) on that half-card.

So 001153 (a made up example)(if I haven't completely screwed this up) would be the lowest left unit (00xxxx), which, when the door is opened, reveals 2 shelves, then the right half of the top shelf (xx1xxx), then the bottom half of the right-most card (xxx15x), then the third light below center (xxxxx3) (or eleventh light down from the top: 8+3=11).

But that can't be right, because I seem to recall that part of the card location was in Hexidecimal.

Yeah, you'll need to call out a technician.

telephoneguy

I think he will have worked it out by now... Look at the date of the original post.

Also no hex addressing and you are correct for newer higher density systems but for older systems there was none of the "halves" (sp?)

I first trained on the IPX. I do remember that the IMX and IMS were different... I think I recall an IMS in the lab that split cables for 16-port cards, so some cards were shared across two cables...

Come to think of it, I think that the hex portion came in with certain commands... Georg, the instructor, liked to make it complicated... But it's now fairly easy for me to convert hex to binary, thanks to Georg...

Yeah, sorry, I read your post and thought it was a new thread. My bad.

Hex is used in programming in certain areas such as ASYD.

Hex is used in programming in certain areas such as ASYD.