TP elements blinking

ubernyako
ubernyako Junior Member
in AMX Design Tools
Hi there. So here's the deal:
I have this system with KNX-NXB bus. KNX controls all the lights. And so I need sticky button if some light source is on. I use Modules as described here: http://amx.com/techcenter/deviceModules.asp?Category=Central%20Controllers
It works pretty good, but button on panel starts blinking like crazy. NetLinx Diagnostics show few hundred ON/OFFs to a panel channel per second. BTW, it all works well if I use only 1 or 3 buttons. But i need over 1000 !! Tried all kinds of feedback, tried MIO-R4 instead of TP - all the same. Did somebody encountered such problem?
· Share on FacebookShare on Twitter

Comments

  • ericmedley
    ericmedley Senior Member - 3709 Posts
    The rapid blinking is two or more feedback statements fighting it out. One statement is trying to do an 'on' and another an 'off'

    it may be in the module or might be in your code somewhere.

    One way to ferret it out is to comment out the feedback statement and watch diagnostic.
    · Share on FacebookShare on Twitter
  • ubernyako
    ubernyako Junior Member
    Now I' suspicious about this part in KNX_NXB sample code: 
    //Modules for control/feedback for NXB-KNX A
DEFINE_MODULE 'AMX_KNX_Updater' Updater(dvKNX_A, lKNX_Value_A) // Module handles update of array for feedback control
DEFINE_MODULE 'AMX_NXB_MOD' nxbMod(dvKNX_A)  //Module handles remote logging from NXB-KNX A as well as facilitates List Save and List Load functions
DEFINE_MODULE 'NXB_KNX_UI' UI(dvKNX_A, aTP_NXB_A, lKNX_Value_A) // Module handles UI control and feedback for NXB-KNX A
DEFINE_MODULE 'KNX_Table_NXB_A' config(dvKNX_A) // Module handles configuration of Actors on NXB-KNX A

//Modules for control/feedback for NXB-KNX B
DEFINE_MODULE 'AMX_KNX_Updater' Updater(dvKNX_B, lKNX_Value_B) // Module handles update of array for feedback control
DEFINE_MODULE 'AMX_NXB_MOD' nxbMod(dvKNX_B)  //Module handles remote logging from NXB-KNX as well as facilitates List Save and List Load functions
DEFINE_MODULE 'NXB_KNX_UI' UI(dvKNX_B, aTP_NXB_B, lKNX_Value_B) // Module handles UI control and feedback
DEFINE_MODULE 'KNX_Table_NXB_B' config(dvKNX_B) // Module handles configuration of Actors on NXB-KNX

    So 'NXB_KNX_UI' module contains feedbacks. They are generated in 'AMX_KNX_Updater' (unfortunatelly it's compiled, so I can't see how exactly). Now there's a moment I don't Understand: "aTP_NXB_B" is some kind of touch panel. And sample code uses two panels for two KNX-buses. But I have only one. Should I make virtual devices "aTP_NXB_B" and "aTP_NXB_A" and then combine them like 
    DEFINE_COMBINE ( virtual_panel_which_i_will_use, aTP_NXB_B, aTP_NXB_A, my_real_touch_panel )
    Will this work fine? (of course I will call devices with some other words=))
    · Share on FacebookShare on Twitter
  • ericmedley
    ericmedley Senior Member - 3709 Posts
    I do notice that you declared a module in both instances and did not make them unique.

    //Modules for control/feedback for NXB-KNX A
    DEFINE_MODULE 'AMX_KNX_Updater' Updater(dvKNX_A, lKNX_Value_A) // Module handles update of array for feedback control
    DEFINE_MODULE 'AMX_NXB_MOD' nxbMod(dvKNX_A) //Module handles remote logging from NXB-KNX A as well as facilitates List Save and List Load functions
    DEFINE_MODULE 'NXB_KNX_UI' UI(dvKNX_A, aTP_NXB_A, lKNX_Value_A) // Module handles UI control and feedback for NXB-KNX A
    DEFINE_MODULE 'KNX_Table_NXB_A' config(dvKNX_A) // Module handles configuration of Actors on NXB-KNX A

    //Modules for control/feedback for NXB-KNX B
    DEFINE_MODULE 'AMX_KNX_Updater' Updater(dvKNX_B, lKNX_Value_B) // Module handles update of array for feedback control
    DEFINE_MODULE 'AMX_NXB_MOD' nxbMod(dvKNX_B) //Module handles remote logging from NXB-KNX as well as facilitates List Save and List Load functions
    DEFINE_MODULE 'NXB_KNX_UI' UI(dvKNX_B, aTP_NXB_B, lKNX_Value_B) // Module handles UI control and feedback



    perhaps you should name the second instance UI2 or something.

    DEFINE_MODULE 'NXB_KNX_UI' UI2(dvKNX_B, aTP_NXB_B, lKNX_Value_B) // Module handles UI control and feedback

    In fact now that I look back, you don't have unique identifiers on the whole block of 2nd modules. that's probably the problem.
    · Share on FacebookShare on Twitter
  • Marc Scheibein
    Marc Scheibein Junior Member
    I agree to Eric. Pretty sure this is the cause.
    Also the other modules for the second gateway should have own identifiers.
    · Share on FacebookShare on Twitter
  • ubernyako
    ubernyako Junior Member
    thanks for the answers!
    btw, what UI part means? What it affects? 
    DEFINE_MODULE 'NXB_KNX_UI' [b][i]UI[/i][/b](dvKNX_A, aTP_NXB_A, lKNX_Value_A
    · Share on FacebookShare on Twitter
  • Marc Scheibein
    Marc Scheibein Junior Member
    This is a unique identifier required by the compiler to differ multiple instances of the same module. The name itself doesn't matter (could be ABC and XYZ) because you can't refer to it.

    Imagine the module as a printer driver. You only have one driver file, but you have 2 identical printers. The system internally need instances "Printer1" and "Printer2" of the driver to manage the processes, and on the Operating system level they are port PRT1 and PRT2
    · Share on FacebookShare on Twitter
  • ericmedley
    ericmedley Senior Member - 3709 Posts
    ubernyako wrote: »
    thanks for the answers!
    btw, what UI part means? What it affects? 
    DEFINE_MODULE 'NXB_KNX_UI' [b][i]UI[/i][/b](dvKNX_A, aTP_NXB_A, lKNX_Value_A

    UI means User Interface.

    In this case (and most) there are two modules. the 'comm' or communication module is the link from the device to the program. The UI module is the link of the program to the user interface.

    an example of this is you might have a DVD player. Two different DVD players will use different protocols or IR files. But the user interface might be the same for both. So, you can easily change the 'comm' modules while leaving the UI in place.
    · Share on FacebookShare on Twitter
  • a_riot42
    a_riot42 AMX Wizard
    Marc Scheibein wrote: »
    I agree to Eric. Pretty sure this is the cause.
    Also the other modules for the second gateway should have own identifiers.

    I've had modules defined with the same identifier accidentally many times and it never seemed to make any difference that I could discern. I thought the compiler ignored it. What would the expected behavior be in that case?
    Paul
    · Share on FacebookShare on Twitter
  • Marc Scheibein
    Marc Scheibein Junior Member
    a_riot42 wrote: »
    I've had modules defined with the same identifier accidentally many times and it never seemed to make any difference that I could discern. I thought the compiler ignored it. What would the expected behavior be in that case?
    Paul
    NetLinx code based modules would just show effects like mixed up states, the effects also depend on the way the module is programmed.

    Duet modules may show more strange effects because of the way they are handled within the controller.
    A few days ago a dealer reported that he can't get Duet Devices online properly. He used one Duet module in 3 instances, plus 2 different Duet modules. After reboot, some Duet devices are created, some not, sometimes they disapper randomly. Finally we found that he has used the 3 instances of the same Duet module with correct different device numbers (41001, 41002, 41003) but the same identifier. We got it fixed simply by using different identifiers for the instances. Now also all the other Duet modules work like expected.
    · Share on FacebookShare on Twitter

Categories