add on module for 2400 IPX

[ankledeep]

This is a 2400 IPX, I have 5 DTerm series E stations with DCU-60-1 add on modules. 3 of them program & work just fine. Two of them give an error when you program the AKYD but seem to work. the error: "IMG Multi Line or PS appearance on Dterm data Invalidity(Package is not support). (Error 0x0249)" does anyone know what this Jinglish means??? All 5 stations are on the same type of card (16ELCJ-B) with the same software (SP3514 B7A)IPX is R-11. I would hate for this error to cause some other problem somewhere else. My cohort programmed a Dterm & add on module to wrong Lens pairs and it caused a station on the card to always go to voicemail. (I found that one) but these other two look OK.

 

[OzzieGeorge]

By the sound of it it is more likely a problem with one of the keys or rather the data you are trying to put on one of the keys. Laborious I know but the only way to be sure is to write one key at a time and see when the error happens.

 

[ethereal112]

This error usually appears when you try and assign a station that is located on another stack, what you might want to do is add the stations one by one in AKYD until you find the one that creates the error, usually this is what I do. After you can move the station to the correct stack so you can add it on the add on module.

 

[ankledeep]

Thanks for the suggestions.... I did not know there were "stack" issues with the IPX ....... I remember them well from the IMGs .... Since I did not do the original programming of the 2 stations & add on modules, I'll have to look closely at the lens assignments....

 

[OzzieGeorge]

There shouldn't be stack issues if it is an IPX!

 

[MercuryComm]

Ozzie is correct. We just upgraded an ICS to an IPX and had this exact issue. Luckly we did our homework ahead of the upgrade as we had to change out all of the 16ELC cards that were not at least 16ELCJ-B's or better. We did have to add chip kits to the existing 16ELCJ-B's we could use in the new switch so they would allow across stack apearances. At that point we thought we were done, but when we started adding phones we received the same error you are getting as we tried to add extensions to phones in different stacks. What we found was that SW10 element 1 (or dipswitch 1) on each card needs to be set correctly. If it is in the "on" position it is set for firmware SP-3419 and software "7300" or eariler. If it is in the "off" position it is set for firmware SP-3514 and software "7400" or newer. We found all of ours set to "on". Changed them to "off" and problem solved. If you have any older 16ELC's this switch setting is not valid so be careful. I believe that the older cards are labeled SW01 instead of SW10 so that should help you tell if you can change the switch. Hope this helps and good luck!!

 

[OzzieGeorge]

Mercurycomm

A much more concise answer than mine, I hadn't considered an upgrade situation. As for SW10 I still occasionally get caught out by that when doing Remote work.

 

[ankledeep]

Thanks for the Tips..... I've been too busy doing other stuff to deal with the PBX (and the add on modules are working OK) but the error message bothers me, so I hope I will have some time next year (Ha Ha) to pull cards and have a look. The thing is the switch was ALL NEW in 2002. (that does not really mean that the dip switches were set correctly) so I'll pull cars and look at it.... Thanks for the suggestion!!!!

 

[OzzieGeorge]

It has just occoured to me that only so many keys can be assigned as speed dial keys, so the error may be caused by you trying to assign a speed dial above that level. If you want speed dial keys over that you have to cheat and use virtuals hotlined to other virtuals which are then call forwarded. Can't remember the actual number of speeddials but it is something to do with the speed dial memories being stored on the card.

 

[ankledeep]

Ozzie, That's a good thought about the speed dials (kind of like the goofy memory allocation for speeds in a 2000 IPS - I never really understood that one, as we only have 2 IPSs (25 to 30 stations) at very small plants) we don't use individual speeds on the phones with the add on modules (don't want the users to be able to mess them up!!) what I am using is line appearances of analog brokerage hotlines (it just wastes the analog card's port). This is evolutionary from back when those positions had analog Plant Equipment "50 line panel phones". But I like your idea of a virtual cf'd to another virtual cf'd to the outside, saves on hardware!!! But alas, the users would undoubtedly mess up the initial speed key's number!! I've been covering lots of various incidents during "holiday light staffing" and a 2:00 AM call out for 4 hours to fix a problem with our SCADA system, I still hope to take a close look at the programming of the 2 positions that give the error.... Next year!!! Thanks for the response, and have a happy and safe New Year!!!

 

[OzzieGeorge]

The thing is you aren't using a speed dial the way we do it. You have a line appearance which is hotlined to a virtual which is set to call forward to the number you want. As the dss/addon key is a virtual line appearance the user can't screw around with it and the call forward is set by you on a virtual extension that doesn't appear anywhere it is user proof. and all of this doesn't use any equipment.

I am at the moment the on call tech (24 hrs a day) covering aproximately 1 millon square miles and have had the joy of being so, for both christmas and the new year celebrations. So I can really sympathise with the callouts

Just before christmas due to a lack of airline seats I drove to a fault with a round trip distance of about 2500 miles, took me 4 days.

 

[ankledeep]

Wow, that's one heck of a lot of driving for just one service call!!!! If I program the buttons as function 49, individual speed dial, (to another virtual that is cf'd outside), then the user could mess with the programming of the 49 key. I can't program a virtual (tec = 18) as a hot line, hot lines must be a tec = 14 and on an analog card (lens). So, if there is another goof proof way that I haven't thought please enlighten me!!! I only take care of these two IPX es and 2 IPS es, so I don't have worldly experience in PBXs. I'm more of a two-way radio and SCADA guy!!!

 

[OzzieGeorge]

You don't need physical equipment to assign a hotline. They can either be assigned as you would a virtual (to the lens you would normally use for a virtual that is) or as phantoms ie programmed on what would be a physical len but in a pim that doesn't exist. You would have to make sure the pim was allowed in aunt. There were some levels of software that wouldn't allow you to assign anything other that 18 to a virtual len but you should still be able to assign a phantom in those cases.

 

[ankledeep]

Hmmm..... I'll have to try a "real" lens that has no card in it.. (getting real scarce in our switch). In the old days with our IMG it would have said "package check", but I have never tried it in the IPX!!! We have up to len 021XXX as our last "real" hardware, but the assignment in AUNT and no hardware is an interesting thought!!! After I get done with a bunch of other stuff, I'll have to play!!! I did get a complaint that the third phone did not get customer calls even though it was logged on (These stations with the add on modules are ACD also) so a quick look at it before the start of the work day (before the calls go to our call center) proved that the users were right...I saw that in Position Data the ACD line tied to the PBX position was the add on module number!!!!! OOOPPPSSS, fixed that and all was good!! I can't wait to play with programming AHLS tec of 14 to either an empty slot, or a virtual slot.....it should be VERY interesting!!! I have tried AHLS with a tec of 18, but it said sorry Charlie, must be a 14!!!