To understand queued modules, it is necessary to recall that any number of module calls can be created as statements in states. Normally, the number of concurrent copies (instances) of a module that can be created by module calls is limited by available RAM memory. Every module call starts its own instance of that module when it is active. Prefixing a module definition with the keyword "Queued" makes that module a queued module and only a single instance of the module is allowed to run - all other module calls will return invalid values and do nothing. All module calls to that queued module which do not run enter a queue for that module, to wait for a chance to run, which only becomes available when the running instance of that module stops.
Typically, the queued module will return a value to signal its calling module that it has completed its work; the calling module will change to another state, which will stop that instance of the module and make a space available for the next queued module call to run an instance. The next module to run will be the module which has been waiting the longest in the queue (i.e. the one that entered the queue first or earliest).
Every instance of a queued module contains its own variables, and behaves in every way like other modules, separate from other instances of the same queued module.
Note: It should be noted that queued modules will work only on modules called from a steady state; queued modules will not work on modules that are implicitly or explicitly launched.
Programmers familiar with much earlier versions of VTS might look for “Fixed modules”. “Fixed” is an older term for what is now a queued module, and is no longer in use.