Home NetLinx Studio

Excessive Feedback Statements in DEFINE_PROGRAM

TurnipTruckTurnipTruck Junior MemberPosts: 1,485
Greetings,

I have been tasked with troubleshooting a system with an odd problem. After uploading code to the master, an NXT-CV10 needs to be rebooted for its feedback to work properly. Having a first look at the code, there are MANY feedback statements in DEFINE_PROGRAM and I'm wondering if that could be causing havoc when the system comes back online.

Thanks.

Comments

  • Thomas HayesThomas Hayes Junior Member Posts: 1,164
    I had a long talk with AMX tech support yesterday and one of the topics was about overloading the panel with excessive polling. It can and will cause the panel to behave flaky or just lock up.
  • Spire_JeffSpire_Jeff Formerly Caffeinated Programmer Posts: 1,917
    How many is MANY? are we talking 50, 100s, 1000s? I have had well over 100 feedback related statements in the DEFINE_PROGRAM section without issue.

    Have you checked to see if the touch panel is getting some of the feedback from the ONLINE: portion of the TP data event? It could be that the feedback is being sent before the variables are populated after a reboot. Ideally, this data should also be sent when a change occurs in the data, but it is possible that the original programmer didn't provide for this.

    Jeff
  • Spire_JeffSpire_Jeff Formerly Caffeinated Programmer Posts: 1,917
    I had a long talk with AMX tech support yesterday and one of the topics was about overloading the panel with excessive polling. It can and will cause the panel to behave flaky or just lock up.

    It was my understanding that channel events in the mainline would only generate traffic if there was a change. Is there something going on that I'm not aware of?

    That raises another question... the feedback you are talking about, is it channel related, or is it sending text changes to the panel? I assumed (I know, I know) that we were discussing channel feedback. If it is sending text to the panels in the mainline without conditionals, it could definately be a cause of problems.

    Jeff
  • DHawthorneDHawthorne Old Timer Posts: 4,584
    Spire_Jeff wrote:
    It was my understanding that channel events in the mainline would only generate traffic if there was a change. Is there something going on that I'm not aware of?

    That raises another question... the feedback you are talking about, is it channel related, or is it sending text changes to the panel? I assumed (I know, I know) that we were discussing channel feedback. If it is sending text to the panels in the mainline without conditionals, it could definately be a cause of problems.

    Jeff

    Channel (and level, for that matter) events to a hardware device won't update unless they change, but channel events to a virtual go out no matter what. But SEND_STRING and SEND_COMMAND go out no matter what as well.

    It's not the number of messages going to a panel that lock things up, it's how fast they go out. If the message queue is filling up faster than the messages can be processed, that's when you get problems. How fast messages can be processed depends very much on how much other stuff is going on, but in most cases, they are the easiest to cut back.
  • TurnipTruckTurnipTruck Junior Member Posts: 1,485
    In the case of the system I am working on, the feedbacks are channels.

    [some device channel]=[some tp button]
    [some boolean variable]=[some tp button]
    ...etc
  • Thomas HayesThomas Hayes Junior Member Posts: 1,164
    Spire_Jeff wrote:
    How many is MANY? are we talking 50, 100s, 1000s? I have had well over 100 feedback related statements in the DEFINE_PROGRAM section without issue.

    Have you checked to see if the touch panel is getting some of the feedback from the ONLINE: portion of the TP data event? It could be that the feedback is being sent before the variables are populated after a reboot. Ideally, this data should also be sent when a change occurs in the data, but it is possible that the original programmer didn't provide for this.

    Jeff

    That's the million dollar question that I didn't get an answer too. In my case I have a warm-up/cool-down bargraph that I update every second for the specified time period. This period is from 40-60 seconds for warming up and 90 sec's for cooling.
  • viningvining X Member Posts: 4,368
    Thomas Hayes wrote:
    In my case I have a warm-up/cool-down bargraph that I update every second for the specified time period. This period is from 40-60 seconds for warming up and 90 sec's for cooling.
    Your doing this in DEFINE_PROGRAM? Sounds like a timeline would be more appropriate. Power on, start a timeline with a 1000ms repeat time, use a local var to increment on each timeline event (seconds) and use this var as a timer and your level. Kill when times up. IF (VAR == 60) kill time_line. Same for coolling. PWR OFF IF (VAR == 90) kill time_line. On every timeline event update your level feed back.

    Use the GLH command to change the bar graphs range high level from 60 to 90 and then back again.
    if (SoundBSent[1].SBCurLevelChannel != SoundB[1].SBCurLevelChannel)
    	  {
    	  SEND_COMMAND dvTPSoundBArray,"'^GLH-',itoa(SoundB[1].SBCurLevelChannel),',',itoa(nSBSongLength)"
    	  wait 1
    	       {
    	       SEND_COMMAND dvTPSoundBArray,"'^GLH-100,',itoa(nSBSongLength)"
    	       }
    	  SoundBSent[1].SBCurLevelChannel = SoundB[1].SBCurLevelChannel
    	  }
    

    You would only need one send command dvTP,"'GLH-level channel#....... and not the other stuff.
  • DHawthorneDHawthorne Old Timer Posts: 4,584
    Once a second, if it's really only going out that often, isn't going to even make a ripple on the processor usage. A few dozen times a second, I would be inclined to worry about. Turn on diagnostics for that panel, and watch how much stuff is really going out. It has a time stamp, so you can easily see if it's sending more than it needs to.

    I regularly make a timeline, and put all my panel updates in it so they can't go out more than the timeline frequency. Once a second it not too infrequent, but noticeable in terms of response, but a 500 millisecond is close enough to instantaneous as it needs to be, IMO.
  • TurnipTruckTurnipTruck Junior Member Posts: 1,485
    Spire_Jeff wrote:
    How many is MANY? are we talking 50, 100s, 1000s? I have had well over 100 feedback related statements in the DEFINE_PROGRAM section without issue.

    Have you checked to see if the touch panel is getting some of the feedback from the ONLINE: portion of the TP data event? It could be that the feedback is being sent before the variables are populated after a reboot. Ideally, this data should also be sent when a change occurs in the data, but it is possible that the original programmer didn't provide for this.

    Jeff

    About 50 feedback statements. Some are variable-based, none seem to have issue with non-popultade variables though.

    I have taken to pretty much re-coding the whole program. It's a lot of code that really doesn't do that much.
  • Thomas HayesThomas Hayes Junior Member Posts: 1,164
    vining wrote:
    Your doing this in DEFINE_PROGRAM? Sounds like a timeline would be more appropriate. Power on, start a timeline with a 1000ms repeat time, use a local var to increment on each timeline event (seconds) and use this var as a timer and your level. Kill when times up. IF (VAR == 60) kill time_line. Same for coolling. PWR OFF IF (VAR == 90) kill time_line. On every timeline event update your level feed back.

    Use the GLH command to change the bar graphs range high level from 60 to 90 and then back again.
    if (SoundBSent[1].SBCurLevelChannel != SoundB[1].SBCurLevelChannel)
    	  {
    	  SEND_COMMAND dvTPSoundBArray,"'^GLH-',itoa(SoundB[1].SBCurLevelChannel),',',itoa(nSBSongLength)"
    	  wait 1
    	       {
    	       SEND_COMMAND dvTPSoundBArray,"'^GLH-100,',itoa(nSBSongLength)"
    	       }
    	  SoundBSent[1].SBCurLevelChannel = SoundB[1].SBCurLevelChannel
    	  }
    

    You would only need one send command dvTP,"'GLH-level channel#....... and not the other stuff.

    Oh, sry I'm not doing in the define_program section, it was just an example of updating the panel.
  • viningvining X Member Posts: 4,368
    DHawthorne wrote:
    Once a second, if it's really only going out that often, isn't going to even make a ripple on the processor usage. A few dozen times a second, I would be inclined to worry about. Turn on diagnostics for that panel, and watch how much stuff is really going out. It has a time stamp, so you can easily see if it's sending more than it needs to.
    I agree but my concern was how it was being limited to only a second if in DEFINE_PROGRAM. Using waits? Or If (Time_To_Second(TIME) != NCurSecond) kind of a thing. Depending on how this was done it does have the ability to bogg down the processor especially if the send_level is going out every pass of the program and only the level value changes every second.
  • viningvining X Member Posts: 4,368
    TurnipTruck wrote:
    About 50 feedback statements. Some are variable-based, none seem to have issue with non-popultade variables though.
    If these are indeed just channel feedbacks there really shouldn't be a problem. If they are all feed back to just the panel your having issues with you could put all the feed back in a timeline repeating @ 200ms or slower, then create an Data_Event for the TP and start the timeline in the ONLINE event handler. If the feed back is to multiple panels you could try, again using feedback in the timeline and in define_start section starting the timeline after a 30 second or longer delay.

    None of this however should be nesaccary.
Sign In or Register to comment.