Do separate timeline events use significantly more processing power?
Ken
Posts: 19
I've listed two examples timeline event setups below.
On what scale does a setup like example 1 use significantly more processing power than example 2? Other than processor usage is there any other reasons I wouldn't separate timeline events like example 1?
Theoretical timeline:
DEFINE_CONSTANT
long tlStatus = 10
DEFINE_VARIABLE
volatile long lStatusTimer[] = {500}
DEFINE_START
timeline_create(tlStatus, lStatusTimer, length_array(lStatusTimer), timeline_relative, timeline_repeat)
Example 1:
timeline_event[tlTest]
{
send_string 0, 'test - 1'
}
timeline_event[tlTest]
{
send_string 0, 'test - f'
}
timeline_event[tlTest]
{
send_string 0, 'test - @'
}
timeline_event[tlTest]
{
send_string 0, 'test - P'
}
timeline_event[tlTest]
{
send_string 0, 'test - 4'
}
Example 2:
timeline_event[tlTest]
{
send_string 0, 'test - 1'
send_string 0, 'test - P'
send_string 0, 'test - 4'
send_string 0, 'test - f'
send_string 0, 'test - @'
}
0
Best Answer
-
richardherman
Posts: 400
What problem are you trying to solve here?
personally I wouldn't use example 1. It probably works, but it almost never a good Idea to try to use NetLinx the way it is not intended.
If you want the event to branch to different actions, call different functions from the single timeline_event.
5
Answers
Example 1 came to mind when I was thinking of ways to have one feedback timeline but keep feedback related to specific devices in their associated include files.
Its not a real issue,I ended up consolidating the various feedbacks into one timeline event in the main source file.
But I was curious if there was any actual problems associated with example 1's design.
Think you better off having dedicated feedback timelines for each functional segment. Each timeline can then be optimized for that functionality - no need to update the current room environment parameters (temperature, set-points), as often as one does a disc transport counter. Also allows for more portable code if those functional segments are containerized in an include file. My convention is to define all timeline IDs in the main code so I run less of a risk of inadvertently duplicating ID's
I'd have to look, but I think the compiler will just put all of that into its timeline section for that particular ID and stack it. Should be akin to having multiple button_events for the same [dev,chan] - they all run, but in the order you have it written. So, I don't believe you're any worse off with example one over two. (But don't quote me...yet!
)
A bit off topic, but I'm still blown away that any type of repeating loop is suggested or used for feedback. We know when buttons are pressed, I/Os are triggered, strings come in, pages are flipped (you don't even need to watch for that when your page handling is done in code!), devices go online or offline, etc., etc., right? Just use that information to trigger a function that updates the necessary feedback. Simple and clean without any wasted time looping through variables constantly.
Not off topic at all and couldn't agree more - very much the better and more efficient methodology.
Sure, when that's an option. Some devices don't say anything about changes if you don't ask.
Sometimes it's the opposite - the device tells you endlessly about things that change rarely.
Example: Security systems, lighting systems, thermostats that typically report unceasingly. You need to attend to them and decide if anything they are saying matters right now. No point in pushing a status out to all the panels that's just the same as the status that came in 20 seconds ago. So keep the last one, compare to the new one, if the same, move along, nothing to do. Well, except when it is required to tell the device you heard it (security systems).
Actually, for thermostats, we use "fuzzy" compare... if the new current temperature is only 1 degree off the last reported, we defer action until it is reported several times. We've seen lots of thrash pushing panel updates as the temperature repeatedly teeters between two degrees.
Great to hear you both say that as I've been pondering a similar train of thought.
I had a small project that upon completion I noticed I'd used zero timeline-based feedback. It looked so weird to me since the usage of feedback timelines is so heavily pushed. I thought I must be doing something in the wrong/inefficient way but maybe I was actually doing it right.
Check the cpuusage and be equally as impressed vs a similar system implementing timeline feedback.
RE: Timeline feedback...
Throwback from old NI programming, where the PROGRAM loop ran endlessly anyway, putting feedback stuff in there didn't really seem to impact the system much. Replacing that with a timeline in new NX systems is the lazy programmer's way. Lazy can be popular.
There are some things that change because of more than one action, and abstracting the feedback in those instances might make rational sense. Otherwise, I hate to agree, but timeline-based feedback, much like me & my code, is a dinosaur of the past.
That might be why the NX forces folks to use a timeline cuz at least then they have set the speed instrad of letting it run full throttle as some often did with the NI’s where they didn’t even put the feedback behind a wait in def program which would be a poor man’s timeline.
I remember doing some comparison between the NI and NX, I think string comparisons or manipulations and the NX wasn’t very impressive. It either wasn’t much better or it was slower. So long ago I can’t recall.
Now in regard to timelines I often use one for the main and all the .axi’s. My mainline runs off my time axi and I have functions that are called every 250 ms, every second, every minute, every hour, every day and with in those functions I’ll use the lower clock times or modulos to fine tune the firing of other functions which reside throughout the main and axi’s.
I’ve see other’s code where they fire off a new timeline for everything and there ain’t nothing wrong with that either.