Home› AMX User Forum› AMX Technical Discussion

Kaleidescape Module ?

HARMAN_LanussinioHARMAN_Lanussinio Posts: 35
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,

Comments

  • viningvining Posts: 4,368
    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.
  • [Deleted User][Deleted User] Harman Integrated Technologies Group (ITG) Posts: 0
    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.
  • mpullinmpullin Posts: 949
    Or, even simpler, just slap a wait 10 in front of it if it's not there already like vining said.
  • ericmedleyericmedley Posts: 4,177
    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.
  • John NagyJohn Nagy Posts: 1,742
    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.
  • HARMAN_LanussinioHARMAN_Lanussinio Posts: 35
    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.
  • a_riot42a_riot42 Posts: 1,624
    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
  • ericmedleyericmedley Posts: 4,177
    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.
Sign In or Register to comment.