Queues implemented using multiple timelines
mag
Posts: 3
Hi all,
From reading here it seems that it is a good idea to have a command queue for each device and process the queue using a timeline.
If so, the problem is that I have to assign the timeline IDs at compile time right?
I figure that inside the timeline event (that handles multiple timeline IDs) I can use the timeline ID to look in the list of queues and process the appropriate one, but with each having to be defined at compile time it looks like I'll have to declare a pool of timelines and assign them at runtime. Is that right?
From reading here it seems that it is a good idea to have a command queue for each device and process the queue using a timeline.
If so, the problem is that I have to assign the timeline IDs at compile time right?
I figure that inside the timeline event (that handles multiple timeline IDs) I can use the timeline ID to look in the list of queues and process the appropriate one, but with each having to be defined at compile time it looks like I'll have to declare a pool of timelines and assign them at runtime. Is that right?
0
Comments
I tend to treat them in the same fashion as a dev array with the exception that I creat Timeline stacks (similar to the old button_event stacks we used to do) and reference the TL I'd in code.
But, yes they need to be set in stone from the get-go.
Bear in mind you don't have to use the constant to call the timeline. Any long variable will do.
At least that's what I'm led to believe - seems to work for me!
and in a timeline event i can kill, pause, etc. the very timeline that is executing?
then the gist of it would be a fn adds a command to the queue for processing, and if not already running, starts a timeline with an ID that will be handled by one of the pooled timeline events.
in the event handler the timeline ID says which queue to process and if the queue is empty, stops the timeline. (the other step to add is to only move to the next in the queue when a data event response from the device confirms the command was successful).
Which the timeline then continually runs through a SWITCH / CASE processing each stage and moving on where needed. For example, it'll loop around the TIMELINE_RECEIVE section until it receives a response (or times out waiting).
And yes, a timeline can kill itself.
can i ask what are you doing in your switch code that will allow you to advance past TIMELINE_RECEIVE?
are you checking status of the device against a record of what you now expect it to be?
So in the TIMELINE_SEND section I'll clear out cData (cData = '') before sending a command to the device. Then the device's STRING event will fill cData with data.text when it comes in.
Meanwhile the timeline is just looping round in the TIMELINE_RECEIVE part until it sees cData isn't empty. It then parses it, does whatever it needs to do and moves onto the next stage (e.g. TIMELINE_DISCONNECT which then closes the connection if there's nothing else in the queue).