Home AMX User Forum AMX Technical Discussion

Queues implemented using multiple timelines

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?

Comments

  • ericmedleyericmedley Posts: 4,177
    Timelines are one of those strange Netlinx-y things that don't quite work like other languages ivmplimentation of them.

    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.
  • If the timeline is inside a module you can use the any id without fear of it clashing with other modules or instances of itself.

    At least that's what I'm led to believe - seems to work for me!
  • magmag Posts: 3
    ok, so a pool it is.

    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).
  • My queue timelines typically have a process flag to determine where in an operation it is. So I have some constants defined to indicate the various stages of communication like this:
    TIMELINE_IDLE			= 0
    TIMELINE_INIT			= 1
    TIMELINE_CONNECT		= 2
    TIMELINE_LOG_IN			= 3
    TIMELINE_SEND			= 4
    TIMELINE_RECEIVE		= 5
    TIMELINE_DISCONNECT		= 6
    TIMELINE_WAIT_FOR_TIMEOUT	= 7
    

    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.
  • magmag Posts: 3
    @regallion
    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?
  • Depends on the device but yeah I may have a global variable (inside the module) that holds any data back from the device. e.g. CHAR cData[32]

    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).
Sign In or Register to comment.