Home AMX User Forum AMXForums Archive Threads AMX Hardware

New Firmwares Hell be aware

I have had problems with the latest firmware files for the MVP-8400 and NXD-1200V and NXD-1200VG.

1) I loaded the latest firmware (v. 2.83.9) into a MVP-8400 and the Lutron Homeworks Interactive P5 feedback via RS-232 stoped working. I am using the AMX Lutron_HWI_v2.3 module.
FIX: Downgrade the panel to v.2.70.8 and feedback is working again. This may affect a lot of dealer and projects out there. Be carefull with this firmware.

2) On the NXD-1200V and NXD-1200VG, Lutron feedback also stoped working with firmware v. 2.72.8. G4 web control also stoped working. You have to manually disable and enable the G4 web control for it to work. Every time you reboot the panel, you need to do the disable/enable procedure again for G4 to work.
FIX: Downgrade to firmware v.2.71.9 and both Lutron feedback and G4 web control work as expected.
NOTE: There is an issue with exiting a page with a video button under v.2.71.9. The screen will flash red for a sec. AMX fixed this issue under v.2.72.8, but broke other more important things.

Somehow the latest firmwares are being released with serious problems. I hope they are more carefull when they release the next updates. If anyone out there experience more problems with these firmwares and others lets post them here so we can avoid big headaches. AMX tech support wasn't aware of the 2 firmware problems I described above. They confirmed the G4 web control problem with v.2.72.8 and said they will fix it on the next release. Regarding the Lutron feedback I have no idea if they will take care of it or not.

Sincerely,

Ricardo

Comments

  • DHawthorneDHawthorne Posts: 4,584
    Panel firmware cannot possible affect Lutron feedback. There is no direct connection. It must be a more general feedback problem relating to the way the Lutron module sends to the panel ... meaning it is actually a bigger problem than you are posting about. It would make issues with any module that handles feedback the same way.
  • annuelloannuello Posts: 294
    I've found that many of my NXD-CV7 panels (v1.13.6) have backlight problems. Due to the symptoms, I fully believe it is a firmware issue when turning the backlight on. I have the Display Timeout set to 5 minutes. Pressing the TP brings the master out of "standby" state into "operation" state. The master sends a 'BRIT-90' command to the TP to ensure that the backlight is on. However, the backlight fails to turn on. All subsequent 'BRIT-' commands seem to be ignored, even when using NLS ControlADevice.

    To get the backlight to turn on we have to either cycle the power, or go into the panel SETUP page and adjust the brightness there. Once the brightness has been adjusted in the SETUP page, subsequent 'BRIT-' commands work. A work-around that works most (but not all) of the time is to enable WakePanelOnMotionSense and set the brightness to something partially visible. E.g. 50%

    It seems as though the external control (via 'BRIT-' command) is questionable. The internal brightness control (via SETUP or MotionSense) is pretty reliable, though perhaps there is also something buggy with the motion sense which makes it not quite 100% reliable.

    I really don't want to keep my backlight on 24/7. I've had one CV7 do a very slight burn-in after 6 months.

    Roger McLean
    Swinburne University
  • truetrue Posts: 307
    I have had problems with the latest firmware files for the MVP-8400 and NXD-1200V and NXD-1200VG.

    1) I loaded the latest firmware (v. 2.83.9) into a MVP-8400 and the Lutron Homeworks Interactive P5 feedback via RS-232 stoped working. I am using the AMX Lutron_HWI_v2.3 module.
    Ricardo,

    I discovered this issue as well while I was writing a Vantage lighting module. Feedback wasn't working. I had since discovered that this affected only channels above 255, but only on ports 18 (or somewhere thereabouts) and above. Firmware 2.81.x and prior was not affected - this is a new bug.

    After talking with AMX support, we gave set_virtual_channel_count() a try, which does resolve the issue. (Time to rename the function? :))

    Try this code and see if it resolves the issue for you (keep in mind this will allow 400,000 channels to be maintained, so you may want to modify this to your scope if it does work for you):
    define_event
    data_event[10001:1:1] {
        online: {
    	stack_var integer startup_chans
    	for (startup_chans = 1; startup_chans < 100; startup_chans++) {
    	    set_virtual_channel_count(10001:startup_chans:0, 4000)
    	}
        }
    }
    

    Again, this has been reported to AMX. Let's see if it gets fixed.
  • viningvining Posts: 4,368
    true wrote:
    I discovered this issue as well while I was writing a Vantage lighting module. Feedback wasn't working. I had since discovered that this affected only channels above 255, but only on ports 18 (or somewhere thereabouts) and above. Firmware 2.81.x and prior was not affected - this is a new bug.
    This may be the cause of a similiar odditiy I noticed on MVPs, which coincidenally was for HomeWorks, probably cuz not to many other devices need so many buttons. I have individual dimmer feedback which begins at 501. KLS led feedback and other stuff is below 501. What I've noticed was intermittant cuz sometimes it worked and other times it didn't. The channel pushes still worked all the time but sometimes no feedback. The module I wrote has been rock solid up until now so I assumed it was something I did to customize it to this current job, although I really couldn't think of anything I did that could really screw it up that bad and feedback to the other TPs was fine (I think).

    Hmmm! I'm glad I read this before investing any time into figuring this out. This may very well have saved me many bumps and bruises from banging my head against the wall while chasing ghosts!

    Thx for the post!
  • truetrue Posts: 307
    vining wrote:
    This may be the cause of a similiar odditiy I noticed on MVPs, which coincidenally was for HomeWorks, probably cuz not to many other devices need so many buttons. I have individual dimmer feedback which begins at 501. KLS led feedback and other stuff is below 501. What I've noticed was intermittant cuz sometimes it worked and other times it didn't. The channel pushes still worked all the time but sometimes no feedback.
    Exactly - channel pushes still work, it's only _feedback_ that doesn't work. That's what threw me off when I was writing my module - I could change the lights and loads, but couldn't see them come on! :)

    They key is the port - I sent test code and a panel to Pete at AMX with the port set to 5, and he couldn't reproduce the issue - it worked over there. I never tested the code locally, and when I did I discovered that only the higher ports are affected. Feedback should _always_ work somewhere around port 18 and below, and should _never_ work above 255 for ports above 17 or 18 with 2.83.9.
  • dthorsondthorson Posts: 103
    I've noticed similar issues with feedback. Mostly when doing feedback to virtual devices or combined devices.

    Try changing you code to send feedback to the actual device.
  • viningvining Posts: 4,368
    true wrote:
    Feedback should _always_ work somewhere around port 18 and below, and should _never_ work above 255 for ports above 17 or 18 with 2.83.9.
    The problem I noticed was on port 7 and may have only been for channels number above 255 but I didn't check. It was working fine the other day so who knows. Gremlins?
  • DHawthorneDHawthorne Posts: 4,584
    I have an answer on the original issue. It seems that if you upgrade the MVP firmware in too big of a jump, you can scramble the CF card. The cutoff is version 2.57.53. If you upgrade any panel that currently has a lower firmware revision than that to the current, you run the risk of messing it up. I just did this, and the symptom in my case was the touch screen stopped responding to touch. Everything else worked. Tech support suggested I revert to 2.57.53 and then upgrade it again, but that scramble it entirely - dead panel. I had to drive back to my store in a snowstorm, and back to the customer with a replacement, costing me an extra 4 hours (3 of which were driving to a job normally only 20 minutes away).

    The AMX tech told me there was a warning in the new firmware description not to load it over older revisions. I assured him there certainly was not, thinking he meant in the little description box you get in Studio when you do an upgrade. Turns out he meant on the web site ... like I'm supposed to remember this "Prior to upgrading to this release from any versions prior to v2.55.43 please contact AMX Technical Support." on a site for a file I downloaded weeks ago. No warning in there that it could actually brick a panel though.
  • adysadys Posts: 395
    I have a lot of problems since the firmware update in 8400 (2.83.9)

    this is one

    http://www.amxforums.com/showthread.php?p=24179#post24179

    this is two (I solved it, but I didn't have it before the update)

    http://www.amxforums.com/showthread.php?t=3754


    The new problem that I found to be connected to the firmware - I have a lot of animations buttons to show states in the house - when animation is runing the panel become so slow, and the animation harldy move.

    Checking it on a panel with 2.63.5 version, the problem is not exist!

    Anyone knows how can I find 2.63.5 firmware to get back to it?


    Thanks.
  • adysadys Posts: 395
    Ok


    I got back to 2.70.8

    The animaitons problems solved!
    No more problems.

    Its a shame that I don't have all the new tools in the old firmware, but its working as it should.


    I will update soon about the network settings issue too (need some time to see if it happens)

    In my opinion - do not upgrade!
  • rolorolo Posts: 51
    The solution to your problem is to set your virtual at port 1

    So

    DEFINE_DEVICE

    dvTPHighPort1=10001:33:1
    dvTPHighPort2=10002:33:1

    vdvTPCombinedVirtual=33001:1:1


    DEFINE_COMBINE
    (vdvTPCombinedVirtual, dvTPHighPort1, dvTPHighPort2)

    For your high button/port functions, create a virtual with a port 1 address. The virtual and the actual don?t have to have the same port.

    To use channels above 255 you will still need SET_VIRTUAL_CHANNEL_COUNT

    This is a known bug...
Sign In or Register to comment.