Excessive Feedback Statements in DEFINE_PROGRAM

TurnipTruck · January 2007

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.

Thomas Hayes · January 2007

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_Jeff · January 2007

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_Jeff · January 2007

Thomas Hayes wrote:

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

DHawthorne · January 2007

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.

TurnipTruck · January 2007

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 Hayes · January 2007

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.

vining · January 2007

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.

DHawthorne · January 2007

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.

TurnipTruck · January 2007

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 Hayes · January 2007

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.

vining · January 2007

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.

vining · January 2007

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.

Excessive Feedback Statements in DEFINE_PROGRAM

Comments