PLK-DMS Craziness

JDaggitt

Folks --

I'm working with an NI-4000 and crazy stuff is happening. Here's a summary:

I installed one DMS and it came up fine. I got the Master Found, Wire is Good Message and then the menu loaded.

When I installed a second DMS, it originally booted up fine, but now it only gets to the "Waiting For Master" screen.

I've been having this problem for several weeks now.

I've tried every combination of cables, ports, ICSNet Hub and I can't get the second DMS to boot past the Waiting for Master Screen.

I went so far as to send the DMS back to AMX for testing. They tested it and it worked fine for them. After getting the DMS back I tried it with the same result. It wouldn't boot past the Waiting for Master Screen.

I returned the DMS to AMX for a replacement and now the replacement is showing the same behavior. It booted up the first time and now sticks at the Waiting for Master screen.

I've unplugged everything, let all the equipment sit over nite and then reconnected with the same result. It doesn't matter the order in which I reconnect things, I get the same result. The original DMS always works, the 2nd DMS doesn't work.

Any ideas would be much appreciated and the person who solves this will get a box of four ribeye steaks from Omaha Steaks.

-- Jack Daggitt

Dries Kaspers

Are you sure both panels have different device numbers? (i never worked with dms pads but that's the only thing that could explain that type of behaviour)
check out AMX Tech Note - TN397 for adressing the pads

Now bring on the steaks!!!

pauld

What happens if you leave the Non-working DMS plugged in and Unplug the working DMS?

JDaggitt

PaulD & Dries

Dries --

The DMS should connect to the NI-4000 without having to assign a device number.

Paul --

Unplugging the DMS's doesn't help. The order in which they are plugged in doesn't change/resolve the issue.


And to deepen the mystery, I've flipped dip switch 1 to stop the code from running to eliminate that as an issue and rebooted. No change.

I've swapped the terminators on the DMS's. No change.

I've changed the power supply on the NI-4000. No change.

DHawthorne

DMS keypads have a unique ID internally (like a MAC number) that the system "learns" when you assign them. You can't duplicate adresses.

I've had some trouble like this before, and in at least one case, it came down to non-compliant CAT-5 wiring. Not the cable itself, but the installer stripped back huge amounts of jacketing (it's supposed to be within 1/4" of the connector), strapped the wire in folds (3" radius on wire bends), and several other glaring infractions. Clearing these up fixed my issues. You could also have RFI problems, or the cabling is too close to power harnesses. It wasn't a DMS keypad, but I once had a serial port dropping off line regularly because it ran too close to a set of speaker relays. Most of the time it was OK, but if all those relays fired at once (All Off function), the coil fields generated enough RFI to knock out the serial port - even with a molded standard cable. Re-routing it 3" fixed it (and I don't think I need to tell anyone what a bear it was to isolate that problem). DMS keypads, at least the ones I have worked with, are very sensitive, and cabling has to be precisely and properly done.

It's even possible your location has an issue. I once had an audio-sensing device (back when I did security) which had a front panel LED that flickered all the time. Any unit of the same make did the same thing, so it wasn't defective; it wasn't picking up audio, nor was it triggering, just the LED flickered. I found that if I held my hand in a particular spot on the wall shadowing it, the flicker would stop. It was entirely independent of room light, and I could only conclude there was some kind of radio signal of unknown origins tickling that circuit. I had to just disable the LED. There's a chance you have something of that nature going on as well...but I'm more inclined to think it's the cabling.

pauld

How about your modules, do you have a seperate module defined for each DMS? Do you have a seperate KPD file for each DMS?

And Did you spell the filename right in your program? ( Thats my biggest problem).

I have had issues with DMSs in the past and have found them to be a pain to code for, but very nice interfaces for the end user.

JDaggitt

Cabling Problem

Dave --

I've used a couple of different cables that the good DMS works on. The bad DMS never boots on any of the cables. Perhaps these two that I've had problems with are overly sensitive...but I'm sort of doubt that.

The first DMS works on any of the cables in the same environment without fail.

I've reloaded the firmware on the NI-4000 and still have the problem with the "bad" DMS.

Paul D --

I'm not even to the point of loading the modules. I just trying to get the DMS connected show it shows up in the online tree.

But I know what you mean about keeping the kpd file names straight.

I appreciate the creative thoughts!! Ribeyes are awaiting.

-- Jack

frthomas

Have you tried replacing the NI-4000 or send it to AMX for a complete refurbish?

From your description, it looks like the master registers and keeps track off all DMS (or ICSNet devices) IDs it encounters during its lifetime, but only connects to the first on the list (the first one encountered) OR if it creates the entry on its list (during the first encounter with this particular DMS).
When it encounters a DMS again, it somehow fails because it is not the first one on the list.

Something like that. Why would the master keep track of DMS? Why would the inital one always work even if it is not the first one found on the network?

Wild thoughts only

Fred

Patrick

Try connecting the DMS directly to the NI 4000 (no hubs etc, just one good short cable). Let it try to initialize and when it hangs, reboot the NI 4000 while only the one DMS is connected to it.

If the DMS boots up ok and shows up in the online tree (regardless of how you get it to work), give it an address and load a kpd file into it - immediately.

I would suggest loading code with dms modules in it into the master too (you may want to do this before connecting the dms).

Good Luck.

DHawthorne

it's starting to sound to me like they weren't assigned in the ICS database. Telnet into the master and type "show database." How many entries say "Subnet/Node PL" with a set of numbers afterwards? These are your ICS devices. The NI frame will be one of them, and I believe hub devices show up with a number with 30/xx. DMS keypads show up as 4F/xx on the master I can check with right now. You should have more than one of these with two keypads connected, if not, the second wasn't assigned. PaulD is on to something too - each DMS needs it's own DMS module and two device numbers (one for the physical device, one for the virtual).

JDaggitt

No Luck

Patrick --

I tried doing a clean re-boot of the system with only the DMS attached directly to the ICS port. I removed the RS-232 cable, the other DMS and even switched power supplies and still it did not work.

Dave --

When reboot with just the "bad" dms and telnet to the ni-4000, and do a show database, the DMS does not show up. If I add the working DMS, it does show up as SubNet Node 57/4E.

I'm going to build a couple of new DMS cables and see if that makes any difference.

If not then I'm going to call AMX for return authorization on the NI-4000.

I appreciate all the advice.

-- JTD

Reese Jacobs

PLK-DMS Craziness

Jack,

I have been following this thread and giving some thought to your problem. Dave is correct in his earlier post that devices have a unique internal ID that is not assigned - this is the neuron ID associated with the network chip in each device. However, DMS keypads, like other devices that reside on the ICSNet bus, have an assigned ID and this is what you see in the Online tree.

I have seen this problem before when moving PLK-DMS or other Landmark devices to Netlinx systems and the problem has typically been that another device has the same ICSNet ID. It does not have to be another PLK-DMS keypad, it could be any device on the ICSNet bus. I have had PLB-AMP8 and PLB-AS8/16 devices conflict with keypads, etc. Most of the Landmark devices I have moved to a Netlinx system seemed to have ICSNet IDs assigned to them in the range of 10-100 - presumably this was automatically done by Landmark but it has caused me problems with duplicate addresses and conflicting addresses when those devices are placed on Netlinx systems.

You did not mention what other devices you have on your ICSNet bus but is it possible you have an NXI, NI, or some combination of NXC devices already on the bus and that the keypad you are having problems with has the same ICSNet ID? If you could eliminate all unnecessary devices on the ICSNet bus and perhaps change the IDs of the ones you must have on the bus, then connect the DMS and see if it shows up. You noted in an earlier message that the DMS did show up on the bus at one point so perhaps this is not the issue. However, it sounds like everyone is running out of ideas for you to try.

A final tip/question, have you tried using Netlinx Studio's Device Addressing function to see if the keypad will respond on the bus even though it does not appear in the Online Tree? You could use the IDENTIFY function and if the device is on the bus, the LED on the menu bar should flash when you are in identify mode. If this somehow worked, then you would be able to assign the device an ICSNet ID and perhaps this would get you over the hump.