Home› AMX User Forum› NetLinx Studio
Options

Yet another iPort thread....

jjamesjjames Posts: 2,908
in NetLinx Studio
Since I can't get the Duet version to work at all, I've been using the NetLinx version with a lot of success. Here's my problem: 18 touch panels are getting updated continuously and causing a lot of traffic. Isn't there any way to stop the updating? Such as disconnecting each panel in the TP array from the module / feedback?

Comments

  • Options
    viningvining Posts: 4,368
    If you make an array to track which TPs are on the iPort page and then in the SEND_VTEXT() and fnDO_FEEDBACK() do a for loop to compare against the active iPort TP Array and then instead of doing feedback and send text to the entire TP array just do it to the individual TP based on wether it's on the iPort page or not using the loop.
  • Options
    DHawthorneDHawthorne Posts: 4,584
    This is one of the few cases where I'll use dynamic combines. Set the iPort module to talk to a virtual device. Create an array the size of the maximum number of panels. When the iPort is selected on a panel, add that panel to the array, and combine the array with the virtual. When it is de-selected, remove it from the array and re-combine what is left. When nothing is combined, all the updates just go to the virtual; since it is internal to the master, there is no delay. Here is the routine I use to dynamically combine and uncombine: 
    DEFINE_FUNCTION CHAR Update Device Combine (DEV dvVirtual, DEV dvDevice, DEV dvDevArray[], CHAR cAddMode)
{
    STACK_VAR LONG  nNewIndex ;
    STACK_VAR DEV   dvTempArray[MAX_NUMBER_TPS] ;
    STACK_VAR LONG  nCount ;
    
    SWITCH(cAddMode)
    {
        CASE TRUE :
        {
            nNewIndex = (LENGTH_ARRAY(dvDevArray) + 1) ;
            SET_LENGTH_ARRAY(dvDevArray, nNewIndex) ;
            dvDevArray[nNewIndex] = dvDevice  ;
            COMBINE_DEVICES(dvVirtual, dvDevArray) ;
        }
        
        CASE FALSE :
        {
            UNCOMBINE_DEVICES(dvVirtual) ;
                        
            FOR(nCount = 1, nNewIndex = 0; nCount <= LENGTH_ARRAY(dvDevArray); nCount++)
            {
                IF(dvDevArray[nCount] <> dvDevice)
                {
                    nNewIndex ++ ;
                    dvTempArray[nNewIndex] = dvDevArray[nCount] ;
                }
            }
            dvDevArray = dvTempArray 
            
            SET_LENGTH_ARRAY(dvDevArray, nNewIndex) ;
            SET_LENGTH_ARRAY(dvTempArray, nNewIndex) ;
            
            IF(LENGTH_ARRAY(dvTempArray))
                COMBINE_DEVICES(dvVirtual, dvTempArray) ;
        }
    }
    RETURN cAddMode ;
}
  • Options
    viningvining Posts: 4,368
    Dave, not that it really matters but are you adding / removing based on page tracking or button pushes that open or close the TP device pages in question.
  • Options
    viningvining Posts: 4,368
    OK, I guess it would be much simpler to use the function with in the UI module and add or remove TPs based on button pushes (open / close buttons) and not via page tracking.

    It's a nice function Dave, very clean and elegantly simple!
  • Options
    jjamesjjames Posts: 2,908
    Ok - quick update. I found the problem. It's not that we have 13 panels . . . it's because the code is so BAD! (My code that is.) If anyone recalls, this is the same job that I've been thinking about / toying with a complete re-write (but the boss says nay.) It has a LiteTouch module (minus UI) and a Destiny 6100 security panel module (comm & UI), then added an extremely poor DEFINE_PROGRAM and a iPort comm & UI module . . . and what do you get? Extreme slowness. Anyway, I was able to streamline the DEFINE_PROGRAM a bit, and that helped a lot. This is also on an NI-4000.

    Also, it didn't matter if I only had 1 TP or 13 TPs being updated, it was slow as molasses. Streamlining some code helped. Just another reason to rewrite the code!
  • Options
    DHawthorneDHawthorne Posts: 4,584
    vining wrote:
    Dave, not that it really matters but are you adding / removing based on page tracking or button pushes that open or close the TP device pages in question.
    Strictly on the basis of a button press selecting the iPort, and any other press that un-selects it. I don't trust page tracking to be reliable enough here ... one missed message, or a panel that loses it's page-track setting, and you have an uncontrolled device.
Sign In or Register to comment.