Home AMX User Forum AMXForums Archive Threads AMX Hardware

NI-4000 slow boot-up

I have a system in a remote location that is taking 9-10 minutes to become fully functional after a reboot. This is an NI-4000 with Com2 cards in slots 1-3, so I have 13 RS232 devices, use relays 1-4 for plasma lifts, and no IR devices.

Telnet shows everything looking normal on boot up, some of the devices start up and can be controlled after a couple of minutes, but others such as the plasmas (ports 1&2), the cameras (ports 6 and 7) and the relays start working after about 7 minutes. After 10 minutes everything is great.

If I telnet in after it starts booting and do a MSG ON, everything appears normal. SHOW BUFFERS doesn't show anything abnormal either.

This system is using the latest non-Duet firmware and the NI-4000 and the touch panel (NXD1200VG) both have static addresses.

Has anyone ever had an issue like this?

Danny

Comments

  • The only time I seen a delay was when I didn't have a IP setup and the unit was hunting for one. I could see the panel taking a few minutes but the relays should be almost instant. Have you tried to pull the cards to see how long it takes to boot? I just setup 3 NI3000's with NXD-CV7's today and rebooted them several times for various reasons and none took more than a few minutes to boot.
  • Another possibility is threshold settings. See Tech Note 476. I had similar problem solved with changing certain of the thresholds.
  • DHawthorneDHawthorne Posts: 4,584
    "Show log" and "show log /all" will often tell you more than "msg on" will because they will report many system events that are not actual errors.

    I'm willing to go out on a limb here and guess you are having some sort of notifications queue issue. One of your devices is sending out a lot of data, or being sent a lot of data, and something else isn't quite ready to deal with it, so the queue is backing up. If they back up enough, you will get a message that stuff is pending, but only when they reach a certain threshold, and you can often see performance hits before that point.

    But even the log doesn't show everything. Use NetLinx Diagnostics and turn on notifications for all devices, then watch what goes through. If you have pages of stuff happening in the same second, you need to examine your code and find a way to curtail that. The message queue is the Achille's Heel of NetLinx; it can bring your saystem to it's knees if not optimized properly.
  • GSLogicGSLogic Posts: 562
    I'm with Dave on this one. I'll bet it's a queue issue. Try commenting out large pieces of code until it starts faster.
  • Thanks for the quick replies. I'll be going to the local site for this company this afternoon and will be able to connect through their network to the remote site for diagnostic purposes and to apply your suggestions.

    Danny
Sign In or Register to comment.