Home AMX User Forum AMXForums Archive Threads AMX Hardware

Panel takes 3 sec's to respond

Here is an odd problem I just had. The client called to say the panel
(CV-7) had stopped working. It was working but took 3 sec's of holding the button down to respond to the command.This was also true for the 'setup' pages/buttons of the panel which should be independant of the program I think. I removed the panel to check for preasure points and such but all was fine. I rebooted the panel and it started to work properly with no detectable delay. Anyone else see this problem before?

Comments

  • Thomas,

    I have this problem also.
    Never tested the local setup buttons.
    Problem is that in my case it's a house with several panels wired and wireless.
    At certain times the system became very slow showing the log told me that all panels dropped offline on regular times for about 20 sec.
    Strange thing was that they dropped off at the moment the heating was switched on by some NXC-rel10 cards connected to the ICSNET.
    I cannot say that this was the problem because whe also discoverd some bad network cables.
    I did some bug fixing and firmware updates and now it seems to work fine but i'm not sure so i monitor the installation every day.
    That's all i can tell at this moment.
    Good Luck
  • Here is an odd problem I just had. The client called to say the panel
    (CV-7) had stopped working. It was working but took 3 sec's of holding the button down to respond to the command.This was also true for the 'setup' pages/buttons of the panel which should be independant of the program I think. I removed the panel to check for preasure points and such but all was fine. I rebooted the panel and it started to work properly with no detectable delay. Anyone else see this problem before?

    When your panel is in the network, you can do telnet to it and do a MSG ON. This will activate the panel's internal debugger, maybe you can get debug messages.
  • kzorakzora Posts: 2
    Why the CV7 slowness?

    I also have a slowness problem with a CV7 (NXD-CV7). I have it solely connected to a NI-2100 master (lone Ethernet devices). After some undesignated amount of time, with an unknown trigger, the panel takes close to thirty seconds to respond then will go and do all of the presses in slow motion that happened when it was locked up. This even happens in the setup mode so I do not believe it is the program. I am going back on site to figure out why it is behaving so, project is due by 6:00pm so I hopefully will have an answer then. If someone knows the reason why this is happening, This is me asking for help. Thanks
  • Sounds like the problem that wireless MVPs used to have. Link would drop out, user would press buttons at random, link comes back up and all the pushes get sent at once. Argh.
  • Thomas HayesThomas Hayes Posts: 1,164
    We still have this 'slow response' issue. I added some code to my program to re boot the panel once everynight. Then a really great problem has now developed, when I reboot the panel the calibration goes so far out that I am unable to activate any buttons..talk about loss..loss situation..I think engineering need to check into this problem.
  • annuelloannuello Posts: 294
    I had the same problem with several CV7s here. I log when a panel goes online/offline, and they didn't seem to be loosing their connection to the master. I also saw the sluggishness in the setup pages. A firmware update seemed to fix it for me. Now running v2.70.7 quite happily.

    Roger McLean
    Swinburne Uni.
  • kzorakzora Posts: 2
    so umm... I found out the reason for my slow NXD-CV7. It had to do with a mistyped loop which jammed the queue with messages via IP to the touchpanel. I guess it got to be so much that the master and the TP slowed to a crawl, sometimes able to respond and do commands in the queue only to find soo many send_commands waiting that they appeared to lock up. I wasn't even able to connect via ethernet because of the traffic.

    I found this out by first noticing that the output light of the master was jammed on. I then tried to comment out the code that had some type of output(send_command) until I found the offending code. After a little trail and error the problem was solved. Just a heads up, to unlock the messed up code and reload some new version I had to use DIP Switch 1 to start my master w/o running the infested loops.

    In the end, my problem was operator error, and not some vague AMX flaw. Good luck and good night.
  • Spire_JeffSpire_Jeff Posts: 1,917
    I seemed to have this problem on an NXD-CV5 today. This is a new installation, so this is the first occurance, but it seems to be exhibiting the same issues as are being described with the CV7. I will check for a firmware upgrade and see if that prevents this in the future.

    Anyone else have any luck finding a definitive cause? I have a couple of ideas as to what is causing this, maybe someone else having problems can see if any of the following apply:

    1. Dynamic Images (there are about 5 of them updating every 5 to 10 minutes... weather satellite images)
    2. A good number of buttons that are being changed with ^BMF commands including hiding and unhiding.
    3. The touchpanel is originally converted (save as different panel type) from an MVP-8400 file.
    4. Some of the buttons are copied from other panels (which I noticed replaced existing graphics files of the same name)
    5. There is a radio tuner that is sending RBDS info to a button as it is received (no more than one update every .7 seconds) if the touchpanel is currently controlling the device.

    I did run netlinx diagnostics and did not see massive amounts of traffic between the processor and the touchpanel. Rebooting the touchpanel fixed the issues. Unfortunately I forgot to telnet to the panel and do a MSG ON in the panel. If it locks up again, I will try to check the MSG ON.

    The nxd-cv5's on this job are running the current 2.51.1, the nxd-cv7 is running 2.57.54. I have decided not to upgrade the CV7 yet as I did not see that problem appear yet and just in case it is a new issue with firmware I'm going to hold off on changing it. (seems this problem is rather new and could be a firmware issue)
    Jeff
  • Thomas HayesThomas Hayes Posts: 1,164
    I have none of the stuff you list Jeff and still have sluggish panels. I'm leaning towards a memory leak or something around this line.
  • Spire_JeffSpire_Jeff Posts: 1,917
    Not sure if they have an update for the CV7, but I just talked with tech support and they sent me a new version of firmware for the CV5 that is supposed to address the problem.

    Jeff
  • Thomas HayesThomas Hayes Posts: 1,164
    What is the firmware release number Jeff?, is it presently available online?(once the web is back up)
  • Spire_JeffSpire_Jeff Posts: 1,917
    The firmware I was dealing with was for the CV5 and it was 2.51.2. I did not see it on the web, but I could have missed it as this is the description:
    ===================================
    Description: Ring firmware v2.51.2 Built on February 16 2007 06:39 PM

    Contents:

    Firmware:MIPS Bootloader for NX-CV5
    Version:v2.51.2
    Target:MIPS

    Firmware:Linux Kernel for NX-CV5
    Version:v2.4.20-pre6.2
    Target:MIPS

    Firmware:FPGA file for NX-CV5
    Version:v1.01.04
    Target:MIPS

    Firmware:OPT File System for NX-CV5
    Version:v2.51.2
    Target:MIPS

    Firmware:G4 for NX-CV5
    Version:v2.51.2
    Target:MIPS

    Firmware:HCS12 firmware for MVP-7500,MVP-8400,NX-CV7,NX-CV10
    Version:v2.51.2
    Target:HCS12

    ===================================

    Not sure if they have a new firmware file for the CV7, but the only thing listed as being fixed by this firmware on the CV5 was loss of touch response.

    Hope this helps,
    Jeff
  • Thomas HayesThomas Hayes Posts: 1,164
    Thx's Jeff.
    I have 1 CV5 now but have a few more projects with them coming up. Keep us posted if it works.
Sign In or Register to comment.