Timeline feedback?
Kailex
Posts: 5
Hi there,
I'm new to programming AMX and I'm trying to accomplish the following. When I press a button I would like to advance to a wait page, watch a progress bar count up, then have it advance to another page.
Currently I'm accomplishing this, however I'm finding problems with the progress bar feedback. Without the follow line the progress bar steps up in larger increments making it appear laggy.
The Timeline
The DEFINE_PROGRAM for timer feedback
PS. Im using an NI-3100 and a MVP-8400. The choppy feedback does not appear to be a wireless issue.
I'm new to programming AMX and I'm trying to accomplish the following. When I press a button I would like to advance to a wait page, watch a progress bar count up, then have it advance to another page.
Currently I'm accomplishing this, however I'm finding problems with the progress bar feedback. Without the follow line the progress bar steps up in larger increments making it appear laggy.
//timerstatus code added to update panel more smoothly TIMERSTATUS = TIMERSTATUS + 1 //increments to make feedback smoothIf I add the line above it ramps smoothly until the very end and then is gets a little choppy. I've also noticed I can't run any calculations in the define_program, is this correct? Any input or suggestions would be great.
The Timeline
TIMELINE_EVENT[TL1] // Splash Advancement
{
switch(Timeline.Sequence) // which time was it?
{
case 1:
{
// Do Something
//Show the power up wait page.
SEND_COMMAND dvTP01,"'PAGE-ProjectorWait'"
IF (ONOFF = 0) //for button animation
{
OFF[dvTP01, 302]
}
Else
{
ON[dvTP01, 301]
}
}
case 2:
{
// Do Something
}
case 3:
{
//Do Somthing
IF (ONOFF = 1) //for button animation
{
ON[dvTP01, 302]
}
}
case 4:
{
//Do Somthing
}
case 5:
{
// Do Something
//Show the Presentation Page or splash page depending on ONOFF state.
IF (ONOFF = 0)
{
SEND_COMMAND dvTP01,"'PAGE-Splash'"
}
ELSE IF (ONOFF = 1)
{
SEND_COMMAND dvTP01,"'PAGE-MainControls'"
}
}
}
}
//SPLASH STARTUP BUTTON
BUTTON_EVENT[dvTP01, 21] //SPLASH STARTUP
{
PUSH:
{
StartupTimer[1] = 0 //Pageflip
StartupTimer[2] = 100 //Do Soemthing
StartupTimer[3] = 12000 //Do Soemthing
StartupTimer[4] = 13500 //Do Soemthing
StartupTimer[5] = 15000 //PageFlip
ONOFF = 1
TIMELINE_CREATE(TL1, StartupTimer, 5, TIMELINE_ABSOLUTE, TIMELINE_ONCE)
}
}
The DEFINE_PROGRAM for timer feedback
(* WAIT TIMER FEEDBACK *)
IF (TIMELINE_ACTIVE(TL1))
{
//timerstatus code added to update panel more smoothly
TIMERSTATUS = TIMERSTATUS + 1 //increments to make feedback smooth
//the code doesnt appear to work why? timercalc remains 0
TIMERCALC = TIMELINE_GET(TL1) / 15000
//The line below alone only updates about 5 times in 15 seconds
//If the timerstatus code above is added it updates more smoothly.
SEND_LEVEL dvTP01,105,(TIMELINE_GET(TL1)) //Update timer on Touch panel
}
Else
{
TIMERSTATUS = 0
}
PS. Im using an NI-3100 and a MVP-8400. The choppy feedback does not appear to be a wireless issue.
0
Comments
J
To do this I set up a timeline to run every second and using an array for time like [0,1000]. Then on timeline sequence = 2 i send out the feedback. On timeline sequence 1 I use timeline.repetition to check to see if I need to do an event or end the timeline.
It's also an advantage to put the feedback into a timeline so mainline doesn't have to process the if statement every cycle.
Second, TIMERCALC will always be zero until the very last instant of the timeline. Once the timeline is done running, I would think that it's timer value will be zero. so, even if the DEFINE_PROGRAM section happens to fire in that last second of the timeline, the next pass through it will be 0 again. If you are trying to use TIMERCALC to indicate the timeline has successfully completed, just set it when you trigger the last event in the timeline.
Lastly, as I look at the code... why are you even using the DEFINE_PROGRAM code? It appears that everything you are doing in the DEFINE_PROGRAM section is in reference to the timeline. Just make the timeline fire at intervals of 100 and make it repeat. Fire events based on the timeline iteration and after the last event, kill the timeline. This removes the need to check if the timeline is active as the only time your code will run is when the timeline is active. It also gives you a very good way to throttle feedback to the touchpanels.
Just my opinions,
Jeff
My interpretation of that statement is that timelines fire at guaranteed times instead of taking their turn like everything else. I went looking and couldn't find any evidence to support that. Can anyone comment?
I also went looking for the justification for timelines - what the AMX folk think we should use them for. And it's clear that they do NOT suggest we should use them instead of regular WAITs in the mainline, eg checking for something every second. They do suggest we should use them instead of stacked WAITs executing some non-trivial timed sequence of events. I don't think I have ever implemented such a thing. Slide sequence? Light show? Lower the lift before you open the doors? Open the windows one at a time to reduce power load?
Is a timeline is more efficient than a wait? It has been suggested that anything in the mainline occupies processor time. Of course it does. But why would a timeline or any other sort of event occupy significantly less processor time? The same check has to be made, just in the runtime system instead of our code. Perhaps more efficently, written in highly optimised assembler; but I imagine the NetLinx compiler produces fairly efficient machine code as well.
We need a postgrad researcher who can rush off and test this kind of thing 8^)
I suspect that there is a slightly exaggerated respect for timelines in our community - "that's the correct way to do it". But for the simple stuff, and almost all of it is simple, a WAIT is one very simple line of code in one place, while a timeline is 4 rather more complicated lines of code in 4 different places.
Waits are still perfectly appropriate for simple "I need to wait a few seconds here" kind of applications. I tend to only use timelines for cycles that run continuously (like a panel update cycle) or for cycles with multiple events. If I'm just waiting for a receiver to warm up, a WAIT does the job just fine.
Resource wise, I'm quite sure a timeline has to use more than a WAIT. I don't consider that an argument in their favor at all.
Here's my perspective based upon my experience.
Since NetLinx is created by programmers and many end user programmers (us) come from other programming backgrounds (C++, Java, etc...) we naturally inject our own biases and 'ways of doing things' into our reasoning. At times NetLinx seems very 'C++' and other times more 'JAVA'-ish (is that a word?) Oh, full disclosure, I come from the days when FORTRAN, BASIC, COBAL, Z-80, and IBM card readers roamed the Earth. That's my background.
I too have wondered why it seems we are told to go running to a particular way of doing something even though another way actually gets it done just as well and doesn't require more lines of code and/or processor cycles.
I still to this day don't use the "Button_Event triggers a function that determines what button_event was triggered which then sends me to another function or call that actually does the thing the button_event was called upon to do" method. This is a very 'JAVA-Object Oriented' way of thinking to me. I just get it done in the button_event. Breaking the 'Object Oriented' construct doesn't make me loose much sleep.
I do use the methodology when I'm dealing with a large series of button events that would otherwise be very difficult to manage. I've seen people create huge chunks of code using the first example to manage IR control of a DVD player. In my mind get it done in the button_event; don't go sailing through 5 sections of the code. Don't haul hay in a Cadilac...
timelines are the same for me. It's a matter of scale. If I'm doing a silly little wait for IR flashes I don't contruct a timeline. It's clunky and overly time consuming. It doesn't offend my sense of fashion to use an olde-tyme WAIT if it gets me through the gig. (oh, that's so last century...)
There are definite camps when it comes to programming. Many times these camps tend to overlook practicality in favor of being 'right'.
'viva la difference!'
Unless they've started teaching a new approach in recent years, last I got from Amx was that a timeline was absolutely the way to go in NetLinx for doing your button feedback every 150 ms or so, so yes - checking for something every second (or several times a second) is absolutely okay. Otherwise, your feedback is going to live in DEFINE_PROGRAM, which we're supposed to avoid using whenever possible.
If you have a sequence of events you want to trigger (like the examples you mention above) timelines absolutely kick ***. They require more structure to implement than WAITs, but I think it's worth it in cases like this.
For simple stuff, like "On this button push I'm turning this relay on, then I want it off in 10 seconds", WAITs are still great...
- Chip
This was what I was told when learning about them.
I believe the Timelines get put into the event table so they are serviced the same as a button event etc and aren't tied into mainline at all.
Timelines are a little more powerful in that you can dynamically change them, use repetition and sequence to get info about them, you can stack them so if you have similar type commands to be processed you save on typing. That being said like others if it's just some IR timing i'm doing I use wait. I have seen others who actually have written their own custom wait type functions using timelines as well but I haven't personally gone that far.
Can anyone quote chapter and verse from some technote or manual somewhere that says that?
Chip,
What AMX instructor taught you not to use DEFINE_PROGRAM for your button feedback?
There is really nothing at all wrong with processing feedback the "old" way. It works perfectly in NetLinx and there no reason to avoid the DEFINE_PROGRAM section.
Of course you can always use a repeating TIMELINE if it makes you happy.
Just to clarify, each feedback statement is evaluated for a change in state, whether processed in a TIMELINE or DEFINE_PROGRAM. If there is no change, the statement is ignored.
Perhaps there is a misconception that a panel message is generated as each feedback statement is evaluated. If this was true the output led on your master would never turn off.
I do believe WAIT behavior is well documented. Each pass through mainline, the processor checks if any WAITs are due, then fires the code if they are. So, no matter what else may happen, the timing on a wait can and will be thrown off by whatever happens to delay a full execution of the mainline loop. In most systems, this is completely negligible; it mattered far more in an Axcent3 than any NetLinx controller.
Joe at AMX East teaches to use a timeline for button feedback instead of define_program. His reasoning, IIRC, was that define_program runs thousands of times a second, which is unnecessary, and if you put it in a timeline that runs only, say, 100 times per second, or even 30 times per second, no human will be able to tell that its going any slower, but the processor will be doing less work.
J
Very interesting. In a very large program it might make a difference, although DEFINE_PROGRAM is suppose to run when there are no events pending.
A good exercise would be to test how many times mainline loops with various size programs by running a counter in the DEFINE_PROGRAM section.
DEFINE_VARIABLE Integer nCount Integer nStop = 1 DEFINE_PROGRAM Wait 600 // Test every minute after first pass { nStop = 1 nCount = 0 } Wait 10 // End test after 1 second { nStop = 0 Send_String 0," 'Mainline counter = ',ITOA(nCount)" } IF (!nStop) nCount ++if(!global_update) { // do a whole bunch load of feedback statements. // do a whole bunch load of feedback statements. // do a whole bunch load of feedback statements. // do a whole bunch load of feedback statements. // do a whole bunch load of feedback statements. // do a whole bunch load of feedback statements. // do a whole bunch load of feedback statements. WAIT 6 { global_update=0 } global_update=1 }It refreshes every 6 ticks (600ms)
It works great. Most statements don't repeat if the state has not changed. However, some_variable=some_other_variable type statments or [some_device]=some_variable can get into that crazy 'update ever processor cycle' thing.
By trapping all my feedback statements in this simple loop, I get around it. I also have a slower loop for things that don't need that much refreshing.
my 2 cents...
I only send feedback to a specific touchpanel(s) that a user is viewing or when it comes ONLINE.
For example: if the user is viewing the Security section, I will send alarm zone status to ONLY that touchpanel. Once the user exits that section I stop sending feedback. If no touchpanels are viewing any sections (Security, Lighting, Music, etc.) there is no feedback being sent at all.
I will agree it's a lot more work to have to keep track of every touchpanel, but in a large system it runs MUCH smoother.
I also feel sorry for the processor having to loop around in circles checking things over and over.
My biggest crime in regard to feedback statements is that they are not consolidated. I have waits in DEFINE_PROGRAM sections of multiple include .axi files, I have in multiple time_line some active 24/7 while others active when in use which in my mind is a mess. Plus I have both in modules which is, what it is. The processor probably only cares a little but I need to re-think and find a better way to manage this. The idea of eliminating includes all together as some members do is temping and with multiple DEFINES section is probably manageable but I like the portability of includes with just the an INCLUDE defined in DEFINE_START or just an #INCLUDE.
What if we had DEFINE_FEEDBACK (feedback name,repitition) so that includes could be pulled into a common feedback statement. Possibly using multiple DEFINE_FEEDBACK each with a different pararemter for repition; slow, medium, fast. In your includes you could pick the type or types of feedback handler that best suited you various feedback needs. Modules are still on their own.
I know I can accomplish the same thing using #INCLUDE and #IF_DEFINED or #IF_NOT_DEFINED but that would get messy.
There is a huge difference between evaluating a feedback statement and actually sending feedback to a panel.
It takes very little processor resouces to evaluate a feedback statement whether located in a TIMELINE or DEFINE_PROGRAM. Actual updating the panel is another matter. I agree; only send what is necessary when it is necessary.
I tend to design a LOT of feedback into my UIs (this is surely good) and I code all of it in (more or less) one place (this is certainly good).
So almost anything that happens will require a UI refresh, but if I called the refresh routine everytime anything happened, the system would get swamped.
So at the end of every function that changes anything that might possibly influence the UI, my code calls a routine called SetRefresh(whatever) which sets one of an array of flags plus a global flag.
Meanwhile, I have a 5/10 second wait that consults the global flag and then runs through the array of flags and repaints whatever on the UI needs repainting.
It works very well and is very easy to tune for performance.
Absolutely. It's the whole process of sending a message to a panel and waiting for a response that bogs the processor down. The current generation of masters is pretty tough to even create a speed bump with evaluations and pure code (unless it's recursive). Its the messaging to devices that has always been NetLinx's Achilles Heel.
Seems unnecessary to me to evaluate feedback (or anything for that matter) thousands of times a second, so it seemed like sound advice at the time...
I haven't used mainline for anything in years, save a recent job where it made more sense to use an old fashioned system call for camera control, and I was too lazy to wrap it in button events.
- Chip
I got my cert(s) staring in 2001 and I remember being told to do all feedback in the Define_Program section. It has been said many times that even though your run through mainline thousands of times a second, it is not sending out thousands of feedback updates. Neither method (Define_Program vs. Timeline_event) is going to cause problems that I'm aware of. I'm not sure why there's an argument over the two methods? Otherwise, it's just two programmer's opinions.
I did say in an earlier post that that is how I do it. (use a wait)
I agree, it is the prudent thing to do.
Heck - lets all go back and spec Axcent 3's on jobs.
- Chip
BUTTON_EVENTS have advantages over PUSH and RELEASE.
DEFINE_FUNCTION has an advantage over DEFINE_CALL.
i think you should use the potential of Netlinx to the max. These things are not created for fun, they serve a purpose!
I'd just as soon see DEFINE_PROGRAM, PUSH, RELEASE, DEFINE_CALL, etc. all become invalid keywords that won't compile when you specify your program as being Netlinx based...
- Chip
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. If you find it more helpful to group feedback statements for certain buttons right after the BUTTON_EVENT statements, you can do that - so all your audio conference button feedback can be put with all the audio conference button events, switcher feedback with the switcher buttons, etc...
- Chip
Sorry to respond to such an old thread but I felt I must chime in on this one. I will give an example of a program I wrote about a year ago. It was pretty basic. One room with a couple of sources, a video conferencing unit, a telephone dialer and one touch panel.
At that point in time I was just getting my feet wet in AMX and was putting all of my panel feedback in DEFINE_PROGRAM.
There were maybe 20 buttons I was tracking, one bargraph level for volume feedback and a text string being sent to the panel that contained the phone number for the dialer.
After loading code the first thing I noticed was the panel feedback was a little sluggish. The tech at the time pointed out that the Output LED was practically solid RED. After a few more minutes the panel would bog down considerably.
Perplexed by this, I created a timeline that fired every 400ms. Bingo, the Output LED was flashing every 400ms and the panel was feeling more responsive.
As far as I could tell it wasn't a glitch in my code so from then on I've put my panel feedback in a timeline and never looked back. Yeah it's a tad more work to setup but I guess the bottom line of this discussion is whatever you feel more comfortable with.
I do occasionally use the Define_Program section for button feedback, but for variable text updates, I use a time line.
Jeff