TimeLine Recourses
jwells
Posts: 25
Hi,
Does anyone have comments regarding the resourses used in a Netlinx controller (NI-3000) with timelines? I'm looking to implement a time check and didn't now which would be more efficient, either a timeline or a couple of IF (TIME = ?????) commands in the mainline DEFINE_PROGRAM section.
Does anyone have comments regarding the resourses used in a Netlinx controller (NI-3000) with timelines? I'm looking to implement a time check and didn't now which would be more efficient, either a timeline or a couple of IF (TIME = ?????) commands in the mainline DEFINE_PROGRAM section.
0
Comments
All the more you get a very accurate time management with Timeline as it's able to trigger around every 0.003/0.003 second !
Hope it helps
Vince
The IF TIME=???? is an old Axcess convention that existed only because axcess didn't support timeline events. AMX documents that this should be avoided in netlinx for several reasons. If your program is simple, the system will ask itself "is the current time equal to this time" tens of thousands of times per minute. If your program is very complicated, passes through mainline will take a back seat & your target time may fall between passes through mainline.
Creating timeline events sets up a seperate thread that takes up very little system resources and processing time. The system "knows" about the event & when to do it. It's like going to the front door every 30 seconds to see if someone is there compared to going to the door when the doorbell rings.
Fred
Not that 100%
WAITs are checked at the end of execution of an Event or of mainline. So a WAIT may become some kind of unexact, especially in Mainline... A TIMELINE is much more exact because its operated just like any other Event.
But you are right - it depends on the solution you need.
Now in this particular application the alternate choice is to use if time = ..., which implies a precision of a minute or maybe a second, in which case I doubt the wait potential lateness would make such a big difference.
Then this is probably diverging from the original thread intention, but I don't see the difference betwen an event (as you said timeline were) and something checked at the end of an event or mainline... At the end of the day Netlinx never interrupts an event or mainline, so whatever is the timeline or wait wanting to do will only occur after said event or mainline. In other terms, the potential lateness is the same whichever way you go.
You may have meant "after all events have fired" instead of "at the end of an event", in which case the lateness potential is greater for WAITs, but that depends really on when is the timeline event posted.
This probably belongs to a "How netlinx really works internally" thread :-)
Fred
Apologies in advance, too much time on my hands today ...
Well, the current discussion regarding the use of TIMELINE_EVENTs versus statements in Mainline got me thinking. I too generally avoid Mainline for most code although there are some things I still put in Mainline. Timelines are extremely useful for a wide variety of purposes and what can be done in Mainline can almost certainly be done more efficiently in a timeline. Futher, timelines have advantages over WAITs (as pointed out in this thread and others) with respect to the accuracy of the timing of the event and the fact that WAITs can not operate on temporary (stack) data.
With the philosophical commentary out of the way, I was intrigued by statements like mainline executes millions, thousands, hundreds, ... of times per second. It got me thinking - how frequently does mainline execute? The answer of course depends entirely on how much code you put in Mainline as well as how busy your system is with event processing. I was curious though how frequently a minimal Netlinx program with a single simple Mainline statement does execute when no external events are occurring.
I wrote a test program that I downloaded to an NI-700 (the fastest processor of all of the current Netlinx Masters). Mainline had a single statement in it namely to increment a counter. In DEFINE_START, the counter was set to 0 and the boot time was logged. Using diagnostics to simulate a button press on a touchpanel, the program would print out the average number of mainline passes on the system. Here is what I discovered:
NI-700: average Mainline passes with single/simple counter - 16850 per second
So, it would appear that even in the ideal of circumstances, adding code to Mainline would not cause it to execute more than 17,000 times and as you add more code (and more complex code), this number goes down
I then added a simple IF statement (and later replaced it with a more complex IF statement) to see what effect this would have on the number of passes of Mainline. I discovered that the simple addition of an IF statement resulted in on average a 12% degradation in the number of Mainline passes completed. The number of iterations of Mainline decreased from 16850 to 14750 on the average.
Now having said this, I have seen systems in which Mainline runs less than 10 times per second because Mainline (main program and all modules) are doing a very significant amount of work. I am sure there are some systems that are programmed in a way that they may only run Mainline 1 or 2 times a second. The corrollary is pretty obvious - the more stuff you cram into Mainline, the longer a pass of Mainline requires and hence the number of times Mainline runs per second decreases. I really wanted to know the starting point for Mainline iterations on a clean/fast system. Your mileage will of course vary based on processor type, amount of code in Mainline, and event activity. I have a module I include in most programs that provides a Mainline iteration measurement just so I can ensure that the system is performing well and has not been mis-programmed so as to bog down the system.
Now for the ulterior motive in the post - I think a thread on How Netlinx Works Internally as proposed by Fred/Marc is badly needed. It would be a big help for newbies and experienced Netlinx programmers alike (wish AMX would add course material to this effect to Programmer III). There is a good bit of information on the structure/syntax of the Netlinx language but not a lot of information on how the system works so you can program more effectively (timeline versus mainline versus WAIT is such an example). Maybe some devil's advocate statements or questions to get it started:
Netlinx is a multi-threaded application but the Master is capable of executing only a single thread (event, mainline, ...) at any given time?
Mainline runs when no events are queued for handling?
Once Mainline starts, it runs to completion (not pre-empted by events)?
While events are queued/pending, Mainline does not run (event queue has priority)?
Events are queued based on their arrival - there is no priority given to event types?
Can a busy system generating significant events potentially affect the accuracy of a TIMELINE event (long event queue, long event processing time)?
WAITs, when encountered, are placed on a list for examination/execution at a later time?
The WAIT list is processed as part of Mainline handling and only after Mainline has completed?
If I stuff all of my feedback statements into Mainline and as a result it runs only once per second, what is the advantage to using a TIMELINE that triggers once per second for the same feedback statements instead of Mainline?
This is what we know from practice:
1) only one type of event can be executed the same time. For exaple this means, as long as a BUTTON_EVENT is executed, no other BUTTON_EVENT can be executed. It will be stacked until the running BUTTN_EVENT is finished.
2) mainline is only executed if no EVENT is in queue of operating.
3) mainline is NOT finished if a EVENT occurs! Mainline will be breaked and executed from the beginning(!!!) if no more EVENTs are in queue.
4) as long as EVENTs in queue, mainline is NOT executed.
5) I'm not sure. Maybe the DATA_EVENT has a higher priority because of ONLINE and OFFLINE handling.
6) I never checked that in detail.
7) Yes. WAITs are put into a list and executed at the end of event handlers or mainline. But because the code of WAITs is "oursourced" from the point where the WAIT is launched, it will be executed later, and will not take an event busy (but FOR and WHILE will!).
8) I'm not sure it detail.
9) Because the mainline is stopped if an event is received, it may happen that not all of the feedbacks are set. Whith a timeline, they will. Another issue with the feedbacks in mainline is performance. Some days ago I speeded up a customer's program just by delaying his mainline feedbacks with a WAIT 3. Because of the spped of a netLinx master, mainline is executed so often that it will get slowed down because the feedback instructions can't be sent to the devices so fast and often...
Marc
Note: can also do once at online events if you don't want to wait...
(* SEND RISE/SET INFO EVERY TEN MINUTES - from scheduler *)
IF ((RIGHT_STRING(TIME,4) = '0:00') && nSENDINFO)
{
nSENDINFO = 0
SEND_COMMAND dvTPFamLogic,"'!T',2,'SUNRISE ',SUNRISE"
SEND_COMMAND dvTPFamLogic,"'!T',3,'SUNSET ',SUNSET"
}
IF ((RIGHT_STRING(TIME,4) = '1:00' && ! nSENDINFO))
{
nSENDINFO = 1
}
Personally, I would prefer numeric values instead of strings:
nMyHour = TIME_TO_HOUR(TIME)
nMyMinute = TIME_TO_MINUTE(TIME)
nMySecond = TIME_TO_SECOND(TIME)
IMHO numeric values are much easier to compare...
IF((nMyOldMinute <> TIME_TO_MINUTE(TIME))AND(nSENDINFO))
{
SEND_COMMAND dvTPFamLogic,"'!T',2,'SUNRISE ',SUNRISE"
SEND_COMMAND dvTPFamLogic,"'!T',3,'SUNSET ',SUNSET"
nMyOldMinute = TIME_TO_MINUTE(TIME)
}
The SWITCH::CASE will be operated if minute has changed. It may be critical to check for 00 seconds also, because the routine may be executed at 0:01 ...
But - both will work like the same....
Marc,
In your earlier post regarding Mainline execution, you noted:
Do we know this for sure? This could have some significant implications for code placed in Mainline on systems with frequent events particularly if Mainline execution is interrupted and is then restarted from the beginning and not continued from the interrupted point. In the AMX training class where we had a high level discussion regarding Netlinx control flow, we were led to believe (and the documentation implied this as well) that once Mainline execution started, it ran until completion (even if it had been interrupted).
As Fred stated in the Netlinx Internals thread, perhaps this would be fairly easy to test. Creating an infinite loop in Mainline and then triggering events for processing would provide a data point. Note the following comment on WHILE statements from the Netlinx documentation:
There is no timeout period as was the case with Axcess. The original intent of the timeout period was to prevent WHILE loops from locking out updates to/from the AXlink bus. The NetLinx Central Controller handles bus updates through a separate execution thread, thereby eliminating this potential problem.
This would tend to imply that the Mainline thread is pended under certain conditions (handling interrupts) and perhaps to prevent Mainline from looping without relinquishing control (as Marc stated). The question in this case would be whether or not Mainline execution is resumed or restarted. It would appear some creative testing is in order to test the theories.
I am going to cross-post to the Netlinx Internals thread - feel free to respond there or I can re-post your answer. Thanks,
Reese