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

NI-4100 Freezing on port 1319

ProdigalProdigal Posts: 90
in AMX Hardware
Well I have a project with a NI-4100 working since summer 2007, everything been ok till these last weeks.

He randomly stops accepting connections on port 1319, which is the port where we connect to with Netlinx.

When this happens, all Touch Pannels loose connections aswell (do they connect thru port 1319 aswell? ). All but 2 TP's that are older and still use AX-Link.

So the status (when this happens) is something like:

-Can't connect thru netlinx to the controller
-Ethernet based TouchPannels loose connection
-Controller continues working
-It's possible to connect thru Telnet to the controller. By quering the connected devices, everything is online, everything but the Ethernet Touch Pannels (around 9xMVP8400 and 2xCV5)
-By rebooting the controller everything comes up and running normally (Softboot, or Hardboot, both work fine).

I first thought it could be a misconfiguration on the router, but it can't be since after a reboot on the controller, everything starts working again. I'm still trying to figure out the time between each freeze.

Getting out of ideas here ^^ I'm thinking on maybe reseting all the memory from the controller maybe. Uploading a diferent project code, should eliminate everything from the last project right?

Comments

  • Marc ScheibeinMarc Scheibein Posts: 851
    First idea I have is the URL list. Please check if there is an entry to the NI4100 itself. If yes remove it. A loop in URL list can lockup a system sooner or later.

    This also may happen if you have connected 2 masters by URL list when on both master an entry is done to the other one.

    What firmware version has the NI4100? Please install v3.30.371, has several internal improvements.
  • ProdigalProdigal Posts: 90
    Well I've checked the URL Listing
    There are 5 controllers in environment, the one freezing is the main controller with IP: 192.168.1.50
    I'm attaching the URL listing of it.

    Regarding the Firmware version it's using v3.21.354, I'm normally a bit cautious when it takes firmware updates. I have that option always as being my last resort. They somewhat tend to not load very well sometimes.
    50.jpg 30.2K
  • ProdigalProdigal Posts: 90
    I've noticed that I had 1 thing on the URL listings tho.

    The master was trying to connect not to itself but to an IP that didn't existed (192.168.1.55) and not connecting to a controller that exists (192.168.1.51).

    Altho while inspecting the URL list of the .51 controller he did had the URL for the .50 so I'm not sure if this could cause any problem.

    Anyway I fixed that already. Not sure if this could cause anything I stated before.
  • Marc ScheibeinMarc Scheibein Posts: 851
    Check if these routes are entered in the .50 master (best verified with Studio, Diagnostics->URL List),they should be listed
    Check the other masters the same way. In these other masters, there MUST NOT be an entry to the 192.168.1.50 !!!
  • ProdigalProdigal Posts: 90
    Marc Scheibein wrote: »
    Check if these routes are entered in the .50 master (best verified with Studio, Diagnostics->URL List),they should be listed
    Check the other masters the same way. In these other masters, there MUST NOT be an entry to the 192.168.1.50 !!!

    Well with that one, you got me.

    I didn't had a clue about that. I though that the URL listings needed to be on every controller.

    For an instance if you have 3 controllers lets say .50 .51 and .52

    At the moment I'm using:

    .50 URL list:
    - .51 & .52


    .51 URL list:
    - .50 & .52


    .52 URL list:
    - .50 & .51


    This is wrong then?
  • DHawthorneDHawthorne Posts: 4,584
    You have a circular route. 50 connects to 51, which connects back to 50, which connects to 51 ... etc. You can't have a situation where a master connects back to itself, even via another master.

    Tech note 251 explains this in detail.
  • ProdigalProdigal Posts: 90
    DHawthorne wrote: »
    You have a circular route. 50 connects to 51, which connects back to 50, which connects to 51 ... etc. You can't have a situation where a master connects back to itself, even via another master.

    Tech note 251 explains this in detail.

    Oh this I honestly didn't knew. Thank you alot.

    So basicly URL listing works like RIP routing, even with the same metrics, and route poisonings. God, now this is a big mess I had in there. How did it worked for so long? :O

    Gonna change URL listing a bit then. Lets see what happens
Sign In or Register to comment.