Kaleidescape Module ?

HARMAN_Lanussinio
HARMAN_Lanussinio
in AMX Technical Discussion
Hi,

I just notice the Kaleidescape module I use (available on Kal website) is overloading the CPU of my controller about 98% of usage.
I found the for loop used in the define_program section in the include file Kaleidescape Multiple Panel Include is causing the issue. when I removed it the CPU usage is back to normal.
This part of code is used to handle feedback on the panel.
Does anyone ever notice this issue ? and if yes how did you manage button feedback ?
Regards,
· Share on FacebookShare on Twitter

Comments

  • vining
    vining X Member
    I've never looked at the KScape module but I would hope they at least put a "wait 2" or something in define_program to throttle down the running of that feedback block and that for loop in the define_program section.

    Personally on a module like that there should be nothing in the def_prog section. Feedback should be sent to the TPs that are on the KScape page and online as feedback comes in. The feedback should also be stored in structures or other var types as needed and kept current so that when any TP goes onto the KScape page or back online after being offline it can be brought up to date immediately.
    · Share on FacebookShare on Twitter
  • HARMAN_Chris
    HARMAN_Chris Harman Professional University
    Take the loop out of DEFINE_PROGRAM and create a TIMELINE_EVENT to process the feedback. This will not impact the speed of panel feedback, but will reduce the number of times this processor intensive loop is occurring.
    · Share on FacebookShare on Twitter
  • mpullin
    mpullin Obvious Troll Account, Marked for Deletion
    Or, even simpler, just slap a wait 10 in front of it if it's not there already like vining said.
    · Share on FacebookShare on Twitter
  • ericmedley
    ericmedley Senior Member - 3709 Posts
    There s also a wired thing that happens on a few installs I've done. Check for channel on/off events on (I think ) channel 90. There were some situations where an interaction on the IP port of the KScape server that would send the master into a channel on/off storm that would bring the processor to its knees. I never found anything in code per se that got it into trouble. It appears to be just a ver fast response loop that gets started between the server and Netlinx proc. and since we can't see diagnostic messages on the IP port I could never watch the traffic to tell.
    · Share on FacebookShare on Twitter
  • John Nagy
    John Nagy CineTouch Product Manager
    RE: IP message storms from KSCAPES...
    Yes we've seen those but not since we worked with their engineer to figure it out and they modded the KSCAPE firmware nearly 3 years ago. Seems there was a condition that if the server lost connection to a player, it would immediately try desperately, as fast as it could, to ask it why. The requests of course all fail, each triggering a new request, later, rinse, repeat. (This is my recollection of the issue, I didn't do the work, it's thematically accurate if I have a detail wrong....)

    We were able to help find this because KSCAPE shared their module source for adaptation to our fairly unique architecture. That gave us the opportunity to put in our own diagnostics in places they had not... and we pinned it down.
    · Share on FacebookShare on Twitter
  • HARMAN_Lanussinio
    HARMAN_Lanussinio
    I'm not kind of using for loop in the define_program section but I just tested with a wait 10 and the cpu usage is around 1%.
    I'm doing test without the kal sytem connected but I had 98,58% of load before adding the wait so let's use the wait 10.
    Thanks for your help.
    · Share on FacebookShare on Twitter
  • a_riot42
    a_riot42 AMX Wizard
    John Nagy wrote: »
    RE: IP message storms from KSCAPES...
    Yes we've seen those but not since we worked with their engineer to figure it out and they modded the KSCAPE firmware nearly 3 years ago. Seems there was a condition that if the server lost connection to a player, it would immediately try desperately, as fast as it could, to ask it why. The requests of course all fail, each triggering a new request, later, rinse, repeat. (This is my recollection of the issue, I didn't do the work, it's thematically accurate if I have a detail wrong....)

    We were able to help find this because KSCAPE shared their module source for adaptation to our fairly unique architecture. That gave us the opportunity to put in our own diagnostics in places they had not... and we pinned it down.

    If its the same loop issue I've seen, it didn't have anything to do with the firmware. Its the module itself plus perhaps an AMX bug in combination. The devchans that are used here:
    //set up the devchans needed for triggering
{
    DCPortOpened		= {m_Kport, 104}
    DCPortInitialized		= {m_Kport, 105}
    DCPortPassingCommands	= {m_Kport, 106}
    DCIPConnection		= {m_Kport, 107}
    DCReportModuleInfo		= {m_Kport, 108}
    DCBinaryDelimiters		= {m_Kport, 109}
    
    DLConnectTimer		= {m_Kport, 8}
    
    //rebuild the event table to account for these changes
    REBUILD_EVENT()
}


    is where the problem lies. For unknown reasons, doing this devchan assignment using an IP port can cause the channel on the IP device to toggle back and forth forever. I haven't been able to replicate it so I think its an AMX bug that is revealed by this code. Changing the IP port here to a random virtual device seems to stop it from occurring. I don't think REBUILD_EVENT() is needed here either. The feedback in define_program is not what I would expect from a fine outfit like Kaleidscape. I've suggested they change this for years, since feedback is slower than it should be, but its still in there.
    Paul
    · Share on FacebookShare on Twitter
  • ericmedley
    ericmedley Senior Member - 3709 Posts
    a_riot42 wrote: »
    If its the same loop issue I've seen, it didn't have anything to do with the firmware. Its the module itself plus perhaps an AMX bug in combination. The devchans that are used here:
    //set up the devchans needed for triggering
{
    DCPortOpened		= {m_Kport, 104}
    DCPortInitialized		= {m_Kport, 105}
    DCPortPassingCommands	= {m_Kport, 106}
    DCIPConnection		= {m_Kport, 107}
    DCReportModuleInfo		= {m_Kport, 108}
    DCBinaryDelimiters		= {m_Kport, 109}
    
    DLConnectTimer		= {m_Kport, 8}
    
    //rebuild the event table to account for these changes
    REBUILD_EVENT()
}


    is where the problem lies. For unknown reasons, doing this devchan assignment using an IP port can cause the channel on the IP device to toggle back and forth forever. I haven't been able to replicate it so I think its an AMX bug that is revealed by this code. Changing the IP port here to a random virtual device seems to stop it from occurring. I don't think REBUILD_EVENT() is needed here either. The feedback in define_program is not what I would expect from a fine outfit like Kaleidscape. I've suggested they change this for years, since feedback is slower than it should be, but its still in there.
    Paul

    Yeah... I get a chuckle almost every time I get someone else's code in a project that has KScape in it. Almost without fail the original feedback routine in Def_Prog is commented out and the programmer's version in place. It is strange to me because the rest of the module is really pretty good code.
    · Share on FacebookShare on Twitter

Categories