Home AMX User Forum AMXForums Archive Threads AMX Hardware
Options

NI-3000 freeze

Hi

I have problem with NI-3000, it's freeze regularly. I have to reboot it to retreive all functions. In this system I have a MVP8400

Connected on master there are, V40 Vidikron, Rotel RSP1068 in RS232 all other components are IR

Somebody can help me ?

Comments

  • Options
    Try this.
    Denis wrote:
    Hi

    I have problem with NI-3000, it's freeze regularly. I have to reboot it to retreive all functions. In this system I have a MVP8400

    Connected on master there are, V400 Vidikron, Rotel RSP1068 in RS232 all other components are IR

    Somebody can help me ?

    I assume the system is properly programmed. Try reassigning your RS232 ports so that port 1 is empty and see what happens.

    Please report back if this works.
  • Options
    jjamesjjames Posts: 2,908
    Denis wrote:
    Connected on master there are, V40 Vidikron, Rotel RSP1068 in RS232 all other components are IR

    The great Vidikron 40 . . . :) I had one of those connected to a 2000 once, and it locked my system up regulary (pretty much every night.) I saw that it was sending me a string every sixy-seconds exactly, even when it was off. Out of curiosity, is yours doing the same?
  • Options
    banobano Posts: 173
    I've had problems with NI's locking up. I traced the problem to the ir ports.They would lock up when using the extended channel mode. Tech support sent me this firmware file to fix the problem, which it did. Good Luck!
  • Options
    DHawthorneDHawthorne Posts: 4,584
    bano wrote:
    I've had problems with NI's locking up. I traced the problem to the ir ports.They would lock up when using the extended channel mode. Tech support sent me this firmware file to fix the problem, which it did. Good Luck!
    I've posted about that IR problem recelntly myself. It messes up any IR function that uses the queue, all the channel commands and the SP command. Thanks for the link to the old firmware, it's made me very happy.

    That's said, that bug only locks the IR port, not the entire master. I would look carefully at the message queue traffic - telnet to your master and use the "msg on" command. Watch for any "message pending" notifications. While that's running, fire up a diagnostics session and turn on all messages for all devices (this is far more stable in NetLinx Diagnostics than in Studio). If you are getting any commands, channel events, feedback strings, whatever, more than a few times a second, you have too much traffic in the message queue. Any kind of demand on the system has the potential to spin it off into an overflow. You can bandage this with the Queue_And_Threshold.axi (or however that is named exactly :)), but in my opinion, that is not the ideal end solution for most systems. You need to look carefully at your feedback and system traffic, and cut it back wherever you can. Get rid of any feedback in mainline, and put it in a timeline event; only update data that has changed; only update pages on a panel that are visible at the time. The message queue is the Achilles Heal of the NetLinx system, and the most likely culprit for your lockups.

    Runaway channel events are something to look for too, or devices that are generating too many events (like a power sensor that is not set properly). All of this should be pretty obvious in a diagnostics session.
  • Options
    DenisDenis Posts: 163
    Bug report

    Hi Guys

    To BClement

    I will try what you said later this week, the system is in middle rack in the wall and it's not easy to get access. I will advise you when it will be done

    To JJames

    Yes I receive a string every sixty second too

    To Bano

    I download and tried your file, but system don't reconize the kit

    ouain...............
  • Options
    banobano Posts: 173
    When downloading this firmware upgrade, you need to set the target device address to the controller, not the master. Instead of 0:1:0, set to 5001:1:0 or the correct d:p:s of the controller.

    Good Luck!
  • Options
    DenisDenis Posts: 163
    Problem report

    Hi everybody

    Concerning the freezing master, I applied the patch submited by Bano, and the master worked well for 3 days.

    After, I reassigned the port. I placed the V40 on port 4 and port 1 is empty. The system works well and it's don't freeze since this time.

    Why........................
  • Options
    Denis wrote:
    Hi everybody

    Concerning the freezing master, I applied the patch submited by Bano, and the master worked well for 3 days.

    After, I reassigned the port. I placed the V40 on port 4 and port 1 is empty. The system works well and it's don't freeze since this time.

    Why........................

    What I've heared was that COM1 is the "slowest" COM port of all, because the chip processing that port is also doing some more things internally....

    What master firmware was/is installed in the NI3k? You should use v2.31.141 (non-DUET) or the latest v3 DUET firmware (3.11) which both have a fix against com ports locking up.
  • Options
    DenisDenis Posts: 163
    Firmware version
    What I've heared was that COM1 is the "slowest" COM port of all, because the chip processing that port is also doing some more things internally....

    What master firmware was/is installed in the NI3k? You should use v2.31.141 (non-DUET) or the latest v3 DUET firmware (3.11) which both have a fix against com ports locking up.

    I use v2.31.141
  • Options
    YuriyYuriy Posts: 20
    Hi!
    Excuse for my bad English.
    Whether guarantees usages of the file Queue_And_Threshold.axi against locking up of the controller?
    I have same problem with NI-2000. I have to reboot it to retreive all functions. In my system I have a AXT-CP4/a.
    Connected on master there are, ASK PROXIMA C420 (port 1), Kramer VP-723DS (port 2) in RS232 and APC SmartUPS in dry closure all other components are IR.
    I use standard modules from AMX for Kramer and system_calls for IR controlled devices. Proj I only turn on/off and trace a state of the fan after turn off.

    Dear sophisticated users may give precise guidelines how eliminate locking up of the controller?
  • Options
    DHawthorneDHawthorne Posts: 4,584
    Yuriy wrote:
    Hi!
    Excuse for my bad English.
    Whether guarantees usages of the file Queue_And_Threshold.axi against locking up of the controller?
    I have same problem with NI-2000. I have to reboot it to retreive all functions. In my system I have a AXT-CP4/a.
    Connected on master there are, ASK PROXIMA C420 (port 1), Kramer VP-723DS (port 2) in RS232 and APC SmartUPS in dry closure all other components are IR.
    I use standard modules from AMX for Kramer and system_calls for IR controlled devices. Proj I only turn on/off and trace a state of the fan after turn off.

    Dear sophisticated users may give precise guidelines how eliminate locking up of the controller?
    The Queue_And_Threshold.axi include file might help, but it's no guarantee. It may not do a thing, depending on what is causing your lockup.

    I'd be willing to be you have some device sending messages to/from the master at way too high a rate. The first step is to telnet into the master and see if you have any "message pending" readouts when you use the msg on command. SOmetimes you can tell what is causing the problem right from that, but more often you have to look further. Second, use NetLinx Diagnostics (the stand-alone one, diagnostics in Studio aren't as robust): turn on device notifications for all ports of all devices, and watch what is happening on our master. If any event is happening many times per second, it's suspect. If nothing unusual shows up to start, begin running through the operations of your system while you watch this window. Again, anything that happens many times per second needs to be addressed.
  • Options
    YuriyYuriy Posts: 20
    Hi!
    I have connected a notebook to the system and waited while the controller will locking up. Has passed six days.
    The controller has again locking up...
    The system was in a waiting mode of commands of the user.
    Netlinx Diagnostics has not output any errors or "message pending" in window
    "Diagnostics":

    Line 1 :: Memory Available = 25640664 <34840> - 16:28:21
    Line 2 :: Memory Available = 25616868 <23796> - 16:31:03

    In the window "Notifications" there were only old messages.

    In the window "Programm status" were the following:

    Line 1 :: Attempting to connect to the master controller -- 16:09:10
    Line 2 :: Valid connection to the master controller -- 16:09:16
    Line 3 :: Requesting Asynchronous Notification Messages from the master controller -- 16:09:22
    Line 4 :: Requesting Internal Diagnostic Messages from the master controller -- 16:09:26
    Line 5 :: Communication to the master controller has stopped -- 11:03:27
    Line 6 :: LOST COMMUNICATIONS WITH THE MASTER -- STOPPING ALL PROCESSES -- 11:03:28
    Line 7 :: Attempting to connect to the master controller -- 11:39:08
    Line 8 :: Failure to connect to the master controller -- 11:39:13
    Line 9 :: Attempting to connect to the master controller -- 11:48:42
    Line 10 :: Failure to connect to the master controller -- 11:48:47

    The controller does not answer any external commands! The WEB interface does not open. All starts to work after sequential turn off/on of power.

    The master firmware is v2.31.141.

    Somebody can help me ?
  • Options
    DHawthorneDHawthorne Posts: 4,584
    Sadly, the diagnostics messages on a NetLinx master are often less than helpful. The first two lines you cited show nothing more than a new memory allocation, but the real question is why was that memory allocated? There may be a process that used up too much memory, and that was what caused your lockup, but there simply isn't enough data to pin it down.

    Turn on page flip notifications in your panel, and trap all panel strings to echo to port zero. Use a telnet session to monitor your master instead of the diagnostics tool. Add send_string 0 statments to your command with messages showing when stuff is being fired. A sequence of such messages prior to a lockup may help you pinpoint what device or code block is causing the trouble.
Sign In or Register to comment.