NI-4000 slow boot-up
Danny Campbell
Posts: 311
in AMX Hardware
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
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
0
Comments
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.
Danny