Home AMX User Forum AMXForums Archive Threads AMX Hardware


Trying to add latest frimware to my panel it keeps hanging at file 6of 8. Im trying to do it through NETLINX STUDIO 2. My panel number is 11111 - I have no idea what could be the problem
Current Firmware Version on my Panel is v2.43.21


  • Options
    NXD-CV7 Firmware Load Issue


    We too have seen this same issue when loading touchpanels and not just CV7 panels by the way although they seem to be more likely to exhibit the problem than other panels. The download always seems to hang between file 5 and 6 of the download - I believe that file 5 is the sensor file.

    First, be sure to give it plenty of time before you give up. The transition from file 5 to file 6 always takes longer to complete regardless of the panel and even when transfers are ultimately successful. By give it some time, I mean give the transfer 5-7 minutes to move from file 5 to 6 - if it goes to 10 minutes you can cancel and try again.

    Second, the only thing we have been able to do to more reliably transfer firmware to the panels is to ensure the transfers are done while the system is not busy and ideally, we move the touchpanel to a standalone Master system specifically used for firmware uploads. By doing this, we are ensured of a very idle system without a lot of TCP or ICSNet bus traffic. When we do this, we rarely have to attempt the upload more than once whereas it may take 3-5 tries on a busy system if in fact it ever succeeds. We have had some CV7 panels that we simply had to move to a standalone system in order for the firmware upgrade to be completed.

    A final note although this does not impact you, I have had problems with firmware uploads to MVP panels hanging between files 5 and 6 repeatedly when the upload is attempted while the panel is docked in the TDS tabletop docking station. Removing the panel from the docking station and connecting the power directly to it almost assures a successful transfer to the panel the first time.

    Just some data points and information for you that might help.
  • Options
    ClingpeachClingpeach Posts: 156
    Im posting this mainly so that I dont forget to do this next time and to let other people know having this problem.
    Turn on netlinx dipswitch 1 and the firmware upgrade will go though
  • Options
    jeffacojeffaco Posts: 121
    Im posting this mainly so that I dont forget to do this next time and to let other people know having this problem.
    Turn on netlinx dipswitch 1 and the firmware upgrade will go though.
    "Netlinx dipswitch 1", if you're referring to the bank of dip switches on the master card, has nothing to do with loading firmware. That dipswitch controls if mainline code is run at bootup; it gives you a "backout" if mainline code somehow crashes the NetLinx controller or causes it to get into a tight loop and become unresponsive.

    If flipping this switch helps you, then it's probably because, as Reese points out, your system is too busy and it's the busy nature of your system that's causing the problem. So while this helps you in your case, it's not necessarily generally useful.

    My code is all event based; I have no "mainline" code that runs constantly. When I'm doing firmware updates, my system is generally idle (no events are triggering). As a result, I've never encountered this issue.
  • Options
    Chip MoodyChip Moody Posts: 727
    Isn't that the program disable switch? I thought turning that on kept the loaded program from running AT ALL - mainline or _EVENTs...

    - Chip
  • Options
    NXD-CV7 Firmware Load


    Correct - that dipswitch is the Program Run Disable (PRD) switch which prevents the master program from being loaded and run. I am pretty sure that is what Dave meant even though his post sounded like only mainline was not executed but everything else might be available.

    To further the points from both Adele and Dave, I have encountered one system in which setting the PRD was the only way to do a firmware load. Like Dave, I do not use mainline except sparingly and even then any feedback in mainline runs only if necessary (some condition has changed) and not every pass through mainline. Hence, my systems are usually ok for firmware transfers if no one is actively using the system for control. I have run into systems that use 'chatty' serial devices like the Arrakis on autoplay that generates enough background activity to cause problems on firmware loads as the result of events and subsequent updates in responding to those events. This is however rare.

    The PRD is a fallback for firmware loads but as Dave points out, generally it can be achieved even on a running system depending on how the system is implemented and how busy it is in mainline and also on the level of event handling going on. Sometimes I carry a spare NXC-ME with me to the jobsite that contains a minimal program load and I use it to connect touchpanels that require firmware loads. This way, I can isolate the touchpanel onto a dedicated master for the duration of the firmware load and not affect the master of the operational system. I realize this is not possible in all cases but I have used it in certain situations.

Sign In or Register to comment.