I do occasionally use the Define_Program section for button feedback, but for variable text updates, I use a time line.
I won't even do that! Normally I will only send the VT when the text changes. If I put the VT send_command it in define_program or a timeline I will create a duplicate array or structure, one to hold current values and one to hold sent values and then in the timeline or define_program do something like this:
This way I never resend the text unless needed, even waitng 400ms between send_commands for VT is too often to do somthing that isn't needed. I will also create a function to update the TP VT so that whn a specific panel comes online after be offline or if I'm tracking TPs to determine what page they are on I update their VT when then flip to the new page.
Chip Moody wrote:
Another cool advantage of using TL feedback over ML is that you can have multiple TIMELINE_EVENT statements for the same timeline throughout your code.
That never dawned on me. I was always creating new timelines or pulling the feedback from includes and putting them into the main code to consoladate everything. The idea of using multiple time_line events for the same time_line and putting them through out the code makes simple sense.
You could probably do the same thing for modules by passing them a simple trigger variable to trigger feedback.
I think this has been a rather interesting conversation about the difference between the two updates.
I always use timelines for polling or sequences. I normally make my button_events update my panel text, because most of our installs are dealing with 8+ touch panels. I tried to run the text updates in define program and it would bog down the processor.
As far as the speed of the define program. I love using the forbidden for loops in my define program, because I don't like typing code 8 times, plus it lets me populate one constant and I'm done. I've never witnessed a bump and I've done as much as 15 touch panels with 20 rooms and 10 sources.....
I think each tool has its place. One of the things I enjoy about AMX and these forums is learning about different tools and finding new more efficient ways to do what we do.
When you wake up in the morning and put your shoes on, you don't have to think about it again.
Now what if I asked you to check and see if you had shoes on every second of the day.
You could still think about other things, it would just take away from your response time.
This is one reason I do not ever use AMX modules for any large multi panel projects. These modules do not take in to account the multiple panel feedback issue. AMX have designed modules for single panel corporate systems and rightfully so as their sales are mostly commercial (hopefully this is changing!!!)
Foot note!
With small systems it's OK to use DEFINE_PROGRAM for feedback, the master is so fast it doesn't even matter AND I know NI masters don't wear shoes, they have rubber feet.
When you wake up in the morning and put your shoes on, you don't have to think about it again.
Now what if I asked you to check and see if you had shoes on every second of the day.
You could still think about other things, it would just take away from your response time.
This is what you're doing in my earlier example where do a comparison to see if the text has been sent. Your checking to see if your shoes on on every seconds.
Running the send command in DEFINE_PROGRAM or in a TIME_LINE w/o this comparison you are actually bending over and putting the same pair of shoes on over and over and over again.... Try doing other chores at the same time, it won't be easy.
So if you going to send text in DEFINE_PROGRAM or in a TIME_LINE you at least have to look to see if your shoe are on so you don't put them on again. Ideally do the text update when the text changes or a TP comes online and don't spend the rest of the day looking at your feet to verify if you're actually wearing shoes.
I think everyone is forgetting that even timelines and events require checking every pass through mainline (the actual program mainline, not just what you manually put there in DEFINE_PROGRAM). So, if you are doing a simple check in DEFINE_PROGRAM, there is little, if any, difference to the processor. Either way, it still has to check if it's "time" to do the operation. It's only when you put complex conditions or operations in DEFINE_PROGRAM that it makes a difference. If you are just checking a variable or channel state, it's negligibly different, if at all, than the processor checking an internal flag.
But it's not only bogging down the processor, you are also bogging down the touchpanel if you send feedback to it all the time.
The cool thing about timelines is the ability to PAUSE/KILL/RELOAD/WHATEVER. Also being able to make a timeline do something once, or repeat comes in handy sometimes...
But it's not only bogging down the processor, you are also bogging down the touchpanel if you send feedback to it all the time.
The cool thing about timelines is the ability to PAUSE/KILL/RELOAD/WHATEVER. Also being able to make a timeline do something once, or repeat comes in handy sometimes...
Who said anything about sending to the panel every time? I'm saying check a variable or a flag before sending; the test itself is what I am referring to.
Who said anything about sending to the panel every time? I'm saying check a variable or a flag before sending; the test itself is what I am referring to.
This only sends the feedback when power_state changes, and you loose the overhead of the "if" and the "wait".
--D
It's a long story. I put a whole bunch of things in this section including my own time module for touch panels. by doing this one IF I actually avoid 10 others.
I just included it in the example since it was copied from something. In the case cited, it is indeed not needed.
It's a long story. I put a whole bunch of things in this section including my own time module for touch panels. by doing this one IF I actually avoid 10 others.
I just included it in the example since it was copied from something. In the case cited, it is indeed not needed.
I also use a very elaborate system to check panel tracking. I don't use DEFINE_PROGRAM or a TIMELINE, I only send data when a panel needs it.
Comments
if (SoundBSent[1].SBCurListIndexHi != SoundB[1].SBCurListIndexHi) { SEND_COMMAND dvTPSoundBArray,"'!T',13,itoa(SoundB[1].SBCurListIndexLow + 1),' - ',itoa(SoundB[1].SBCurListIndexHi + 1)" SoundBSent[1].SBCurListIndexHi = SoundB[1].SBCurListIndexHi }This way I never resend the text unless needed, even waitng 400ms between send_commands for VT is too often to do somthing that isn't needed. I will also create a function to update the TP VT so that whn a specific panel comes online after be offline or if I'm tracking TPs to determine what page they are on I update their VT when then flip to the new page.Chip Moody wrote: That never dawned on me. I was always creating new timelines or pulling the feedback from includes and putting them into the main code to consoladate everything. The idea of using multiple time_line events for the same time_line and putting them through out the code makes simple sense.
You could probably do the same thing for modules by passing them a simple trigger variable to trigger feedback.
I think this has been a rather interesting conversation about the difference between the two updates.
I always use timelines for polling or sequences. I normally make my button_events update my panel text, because most of our installs are dealing with 8+ touch panels. I tried to run the text updates in define program and it would bog down the processor.
As far as the speed of the define program. I love using the forbidden for loops in my define program, because I don't like typing code 8 times, plus it lets me populate one constant and I'm done. I've never witnessed a bump and I've done as much as 15 touch panels with 20 rooms and 10 sources.....
I think each tool has its place. One of the things I enjoy about AMX and these forums is learning about different tools and finding new more efficient ways to do what we do.
Now what if I asked you to check and see if you had shoes on every second of the day.
You could still think about other things, it would just take away from your response time.
This is one reason I do not ever use AMX modules for any large multi panel projects. These modules do not take in to account the multiple panel feedback issue. AMX have designed modules for single panel corporate systems and rightfully so as their sales are mostly commercial (hopefully this is changing!!!)
Foot note!
With small systems it's OK to use DEFINE_PROGRAM for feedback, the master is so fast it doesn't even matter AND I know NI masters don't wear shoes, they have rubber feet.
if (SoundBSent[1].SBCurListIndexHi != SoundB[1].SBCurListIndexHi) { SEND_COMMAND dvTPSoundBArray,"'!T',13,itoa(SoundB[1].SBCurListIndexLow + 1),' - ',itoa(SoundB[1].SBCurListIndexHi + 1)" SoundBSent[1].SBCurListIndexHi = SoundB[1].SBCurListIndexHi }Running the send command in DEFINE_PROGRAM or in a TIME_LINE w/o this comparison you are actually bending over and putting the same pair of shoes on over and over and over again.... Try doing other chores at the same time, it won't be easy.
So if you going to send text in DEFINE_PROGRAM or in a TIME_LINE you at least have to look to see if your shoe are on so you don't put them on again. Ideally do the text update when the text changes or a TP comes online and don't spend the rest of the day looking at your feet to verify if you're actually wearing shoes.
The cool thing about timelines is the ability to PAUSE/KILL/RELOAD/WHATEVER. Also being able to make a timeline do something once, or repeat comes in handy sometimes...
Who said anything about sending to the panel every time? I'm saying check a variable or a flag before sending; the test itself is what I am referring to.
This is true.
If you have this statement
DEFINE_PROGRAM if(global_update=0) { [dvTP_1,1]=power_state wait 9 { global_update=0 } global_update=1 }It is not sending a button state command every 9 ticks. It only sends them when the state changes.
I just tested it.
I'm not sure why you need all the extra code...
This only sends the feedback when power_state changes, and you loose the overhead of the "if" and the "wait".
--D
It's a long story. I put a whole bunch of things in this section including my own time module for touch panels. by doing this one IF I actually avoid 10 others.
I just included it in the example since it was copied from something. In the case cited, it is indeed not needed.