Home› AMX User Forum› AMXForums Archive Threads› AMX Hardware

NI-4100 Losing connection

mushmush Posts: 287
in AMX Hardware
G'day,

I'm having a strange problem with a NI-4100.
The unit has been working without issue for 12 months.
Yesterday the unit went offline in so much as I could not connect to it with Netlinx Studio, Telnet or FTP.
I could ping the unit and connect to it via the programming port using RS232.
The unit is set up with a static IP address but no DNS addresses.
Yesterday I had the client re-power the master which rectified the problem.
Today the same thing has happened.

Checking the messaging I am constantly receiving a message that I have not seen before...
Line 1898 (10:48:19):: Look up IP for URL[0]=192.168.83.102
Line 1899 (10:48:19):: hostGetByName succeeded with IP=192.168.83.102..Attempting connection
Line 1900 (10:48:20):: IP Connector index 0 had save socket 0 (deleted URL?). URL=192.168.83.102 IP=192.168.83.102

Does anyone know what this message means?
The 192.168.83.102 IP address is the IP address of the master in question. Is this a DNS query perhaps?
Any ideas on where to go or what more to look for?

Any help much appreciated.

Cheers

Mush

Comments

  • ericmedleyericmedley Posts: 4,177
    I've noticed some incompatablility with the Netlinx's (is that a word???) NIC card and some network routers and/or switches. I've mainly seen it with the lower level Linksys stuff. However, I've also seen it on other high-end stuff too.

    The basic failure seems to be that the Router drops the connection or ignores anything that comes from the Netlinx Master. It's still there, will respoind to pings but no other network traffic gets through. The master itself is working fine. AxLink and ICSNet stuff is chugging along nicely. The only fix is to reboot the master.

    I have a couple installations where the client is just unwilling to deal with the problem and the only reliable fix I've been able to create is to reboot the master each night at about 4AM from the program.

    Since doing this, the problem has almost completely gone away.

    It's a strange problem and I'm not entirely sure it's AMX's fault. While other devices don't seem to suffer from this, they also are the kinds of things that are frequently rebooted or restored like laptops or PDAs. And people are used to having to reboot those kinds of things. It's just part of the territory.
  • Jimweir192Jimweir192 Posts: 502
    What do you have on 192.168.83.102? What is the IP Address for the master?

    Do you have anything in the URL list in the master?
    Do you have a gateway IP set on the NI4100?

    Both of these are common issues that can kill the NIC port on the master...
  • mushmush Posts: 287
    G'day Jim,
    Jimweir192 wrote: »
    What do you have on 192.168.83.102? What is the IP Address for the master?

    Do you have anything in the URL list in the master?

    Do you have a gateway IP set on the NI4100?
    192.168.83.102 is the master's IP address.

    No, but this master is listed in the master master's URL list.

    Yes, please explain how this is can be a problem. Especially since this system has been in and operational for a year.

    Cheers

    Mush
  • [Deleted User][Deleted User] Posts: 0
    Common mistake you only make once
    mush wrote: »
    G'day Jim,

    192.168.83.102 is the master's IP address.

    No, but this master is listed in the master master's URL list.

    Yes, please explain how this is can be a problem. Especially since this system has been in and operational for a year.

    Cheers

    Mush

    See tech note 508.

    http://www.amx.com/techsupport/techNote.asp?id=508
  • mushmush Posts: 287
    B_Clements wrote: »
    See tech note 508.

    http://www.amx.com/techsupport/techNote.asp?id=508

    Thanks for your reply Brian but I was already aware of this.
    The problem masters IP is in a different masters URL list not it's own.
    ie: there are currently 8 masters in this system. The main master, which has the problem masters IP address in it's URL, is 192.168.83.101.
    Also this system has been running for a year and has suddenly started misbehaving and I can ping the problem master.
  • ericmedleyericmedley Posts: 4,177
    mush wrote: »
    Thanks for your reply Brian but I was already aware of this.
    The problem masters IP is in a different masters URL list not it's own.
    ie: there are currently 8 masters in this system. The main master, which has the problem masters IP address in it's URL, is 192.168.83.101.
    Also this system has been running for a year and has suddenly started misbehaving and I can ping the problem master.

    Just to be clear.

    Do you have
    1) the Main Master's URL in the sub-master's URL List?

    and/or

    2) The sub-master's URL in the Main Master's URL List?


    If you answered both 1 and 2 Yes, then that's the problem.

    It should only be in one of the masters and preferrably the sub-master.
  • mushmush Posts: 287
    ericmedley wrote: »
    Just to be clear.

    Do you have
    1) the Main Master's URL in the sub-master's URL List?

    and/or

    2) The sub-master's URL in the Main Master's URL List?


    If you answered both 1 and 2 Yes, then that's the problem.

    It should only be in one of the masters and preferrably the sub-master.

    G'day Eric,

    Thanks for your reply.
    There are 8 masters in the system.
    One master and only one master has all other masters in it's URL list.
    This is the way AMX have recommend it be done and is indeed the way we have done it successfully in many installations.
    Also don't forget, this has been working for a year and only started playing up this week.
    Please see my main thread.
    What do those messages mean?
  • ColinColin Posts: 51
    IP Address

    Hi Mush,

    could there possibly be another device that has a static IP address sitting on the same network ie 192.168.83.102?

    I was just thinking maybe someone has added a static device on the network and assigned this address.

    I would take this device offline and ping the address - this should tell you

    Just a thought...

    Cheers

    Colin

    PS: Happy New Year to all
  • ColzieColzie Posts: 470
    Have you tried this?

    http://amxforums.com/showthread.php?t=3595
    Colzie wrote:
    I do these two commands on pretty much all masters I work on:

    set ethernet mode 10 half
    set udp bc mode 0

    I've found they are not always necessary (tremendously helpful when they are!), but it definitely does not hurt and it can eliminate a service call down the road.

    (Only use "set udp bc mode 0" if you are not using the "Auto" feature to connect the TP to the master (who uses this anyway??))

    Perhaps some hardware upstream from you has changed??
  • [Deleted User][Deleted User] Posts: 0
    mush wrote: »
    Thanks for your reply Brian but I was already aware of this.
    The problem masters IP is in a different masters URL list not it's own.
    ie: there are currently 8 masters in this system. The main master, which has the problem masters IP address in it's URL, is 192.168.83.101.
    Also this system has been running for a year and has suddenly started misbehaving and I can ping the problem master.

    Sorry, misunderstood your issue. I have seen strange connection issues when a master is expecting to communicate to an Ethernet device and that device is not reachable on the network. Pending messages then fill up the outbound Ethernet queue and lock the Ethernet port.

    Have you used the commands show buffers and show max buffers from a telnet session? If there are excessive pending items, that could be a clue.
  • DHawthorneDHawthorne Posts: 4,584
    It may have worked for a year, but that doesn't mean network traffic hasn't increased enough outside your control network to start causing issues. I had a very similar problem that only showed up when a customer was streaming audio on his network (which of course never happened when I was there since he only did this during non-work hours). In that case, the code on the master had a problem that kicked it over the edge, and fixing that fixed the issue, but the bottom line was simply too much network traffic.

    A few possibilities ... not sure which are feasible for your application ... are:

    1) Create an independent network just for your control equipment (best but least practical).
    2) Use a managed switch and put the control equipment on it's own partition (fairly easy to retrofit if the distribution is centralized).
    3) If it's impossible to partition or separate networks, again use a managed switch to at least prioritize traffic to your control ports.

    Also, make sure everything in your control network, touch panels and all, have a static IP - then if the router stops talking to them, they will at least still find each other.
  • mushmush Posts: 287
    DHawthorne wrote: »
    It may have worked for a year, but that doesn't mean network traffic hasn't increased enough outside your control network to start causing issues. I had a very similar problem that only showed up when a customer was streaming audio on his network (which of course never happened when I was there since he only did this during non-work hours). In that case, the code on the master had a problem that kicked it over the edge, and fixing that fixed the issue, but the bottom line was simply too much network traffic.

    A few possibilities ... not sure which are feasible for your application ... are:

    1) Create an independent network just for your control equipment (best but least practical).
    2) Use a managed switch and put the control equipment on it's own partition (fairly easy to retrofit if the distribution is centralized).
    3) If it's impossible to partition or separate networks, again use a managed switch to at least prioritize traffic to your control ports.

    Also, make sure everything in your control network, touch panels and all, have a static IP - then if the router stops talking to them, they will at least still find each other.

    Thanks for your time and ideas.
    1) Completely separate network is not possible. The AMX system is already on it's own subnet.
    2) Already on a Linksys managed switch.
    3) Already set-up correctly.

    Everything already has static addresses.

    Cheers

    Mush
  • mushmush Posts: 287
    Oops!

    I was finally allowed back onsite today.
    Embarrassingly, the problem was that this Master had it's own IP address in it's URL list.
    It looks like it kept connecting to itself and ran out of ports.
    Thanks to everyone who supplied suggestions and feedback.
  • a_riot42a_riot42 Posts: 1,624
    mush wrote: »
    I was finally allowed back onsite today.
    Embarrassingly, the problem was that this Master had it's own IP address in it's URL list.
    It looks like it kept connecting to itself and ran out of ports.
    Thanks to everyone who supplied suggestions and feedback.

    How on Earth did it run for a year like this???
    Paul
Sign In or Register to comment.