Home AMX User Forum AMXForums Archive Threads AMX Hardware

NI-700 lockup as standalone

FYI- If you drop code on a non-networked NI-700 without first changing the network connection to static. The controller will lock up for 3-5 minutes before the program becomes active. During the lockup the input light remains on and the controller is unresponsive to RS232 connections. I called tech-support with the problem yesterday and they didn't know what would cause this scenario. Now I know. - Set network connections first to static. Apparently the master locks up while waiting for a DHCP response that never occurs.

Comments

  • JillJill Posts: 44
    I too noticed this issue with the NI-700 and called tech support when I recieved my first NI-700 about a year ago. I thought that they would have a tech note about this enclosed in the box. :):)
  • shr00m-dewshr00m-dew Posts: 394
    Umm, surprised tech support didn't know, this happens with any of the NI series. There is a tech note, or it's in one of the online training classes..

    We had a home show we were doing where a spare NI-3000 was running a shade and intergrating lights,etc... I couldn't figure out why it took 3-4 minutes between reboots tweaking the timing. Later I did find out why from somewhere..

    Kevin D.
  • NI-700 lockup as standalone

    Kevin is correct - there is nothing unique about the NI-700 and this problem. I have see the problem with NI-2000 and NI-3000 controllers. As for the Tech Note, it is buried in Tech Note 362 (and perhaps others) where the various Master LED states are described. A fast blink Master status LED means that the IP address in the Master is not set or has not been acquired properly from DHCP.

    I could not find any Tech Notes on why it takes 3-4 minutes to give up :).
  • This just happens because in factory default, all NetLinx masters are set to DHCP network mode. The master tries to get an IP address by a DHCP service for about that 2-3 minutes. If it doesn't get an IP address within that time, it will do some "small" reboot and operate normal.

    So if your master hasn't to hookup into a network, just give it any static IP (by terminal or from Studio), to speed up the boottime.

    Regards,
  • Chip MoodyChip Moody Posts: 727
    This applies to ALL NetLinx controllers. I have ME and ME260 controllers in my shop that do the same thing. I leave 'em set to static, 'cos they also seem to have difficulty with our IT dept's DHCP server.

    - Chip
  • DHawthorneDHawthorne Posts: 4,584
    Chip Moody wrote:
    This applies to ALL NetLinx controllers. I have ME and ME260 controllers in my shop that do the same thing. I leave 'em set to static, 'cos they also seem to have difficulty with our IT dept's DHCP server.

    - Chip
    Funny you should mention that. I've had Modero panels randomly decide not to talk nice with the DHCP server. Sometimes they worked, sometimes not. I eventually just gave them static IP's too, out of sheer frustration. I always give my masters a static IP because I mainly do residential, and set up the customer's router to forward ports 21, 23, and 1319 to my master so I can remote it.

    One other funny thing I had happen once. I had a master that was manually configured from the start, but absolutely refused to connect properly to the customer's network. I could access it directly from a local connection using it's IP, but from the outside no amount of twiddling with forwards on the router would convince the router it even existed. Neither could it get out on the Internet to use i!-TimeManager or i!-EquipmentMonitor. I eventually went back to the site, set it to use a dynamic IP, saved and rebooted, then changed it back to exactly how it was set before with the static IP. All was fine after that. I can only assume there are some hidden data fields that get set on a DHCP connection that you can't fix manually...I can't imagine what they would be, except possibly an internal routing table of some sort, though you would expect putting in static values would clear that.
  • Chip MoodyChip Moody Posts: 727
    Oh gawd yes. I'm lucky enough to have a TPI4 living on my bench, but there have been numerous times that I've wanted to pitch it out the window because it wouldn't "take" a DHCP address. I've got it on a static address now, and I can't say why I keep trying DHCP from time to time. Guess I'm a masochist.

    Extremely frustrating. Fortunately I get along well with our IT folks, and they don't mind me using static IPs in a certain range... 99% of our installs are simply a master, switch/access point and a panel on their own private net, so I never have a reason to NOT use static addresses for those.

    - Chip

    DHawthorne wrote:
    Funny you should mention that. I've had Modero panels randomly decide not to talk nice with the DHCP server. Sometimes they worked, sometimes not. I eventually just gave them static IP's too, out of sheer frustration.
  • NI-700 Network Lock up

    I'm have random problems with several NI-700's where they intermittantly cease all Network functions, but if I plug into the RS232 port, it's still running the program.

    Seems to happen after I do any changes and down load it. After 5 - 15 minutes networking functions just cease with no warning. After a few reboots the problem dissappears - which tends to shake the confidence somewhat......

    Master IP is Static with gateway set to router address so I can access them remotely. Can't ping it and ports 1319, 23, 21donot resond, but the little beasty is still processing it's heart out - shame it can't talk to the lighting system though!

    Any ideas or suggestions guy's?
  • Ta, I did digest your comments before posting the query :-) This appears to be a different issue, but as it appears without warning - it's quite hard to pin point.

    I need to use Static IP's as several devices communicate with the master via TCP/IP which don't have the ability to resolve the IP address.

    Brent
  • What firmware are you running? I had the same thing happen with a NI-3100 running the latest Duet firmware. What I saw happening was the IP connectivity would drop and then when I did a SHOW BUFFERS the Interpreter RX count would be up and would never clear. First the web access would go, then the master trying to contact the database server, then telnet would drop off and finally the touch panel would show the green ball blinking but would not operate. After several days of playing with the old and new Queues&Thresholds.AXI we got AMX tech support involved. It appears that there are a couple of IP-related issues in the 3.21.343 version. They had me download a hot-fix that so far seems to have stopped my issues.
Sign In or Register to comment.