ReleaseNotes:Planimate 4.11 Release Notes

From Planimate Knowledge Base
Jump to: navigation, search

Release notes, bug fixes and misc enhancements to Planimate 4.11


  • Important Enhancement to broadcasts

The system now defines and sends some broadcasts which the modeller can use:
PreInit Start
Sent when the model is about to enter pre-init stage, just before it would pause if the modeller has selected "Pause After Pre-Init".
Note this is always sent, even if the model does not pause at pre-init
A good time to do initial calculations and table imports, before the user gets to see the model for the first time (assuming run on load is enabled)
PreInit End
Sent when the system is leaving pre-init stage. If the model paused at pre-init, it is sent when the user selects continues the run.
A good time to do final cleanups to attributes which are used to post initialise objects, eg: pipe total delay and interval, conveyor
Probably not required often
Run Start
Sent when the system is about to actually start running - objects have been fully initialised, pending events are scheduled for entries etc.
A good time to "throw" items into place, preload other items into queues etc.
Run Pause
Sent when the system is about to go into pause mode, because the user or an event has initiated a pause or there are no more events.
A good time to update tables and displays that the user will be exposed to
Run Continue
Sent when the system is resuming a run. Note this is also sent at the start of the run after the "Run Start" broadcast.
A good time to validate any changes made by the user dueing pause mode
Run End
Sent when the model is stopping, either because the user has selected stop or a stop condition has been reached at an exit.
NOT sent if an error causes the stop or an exit triggers a stop using the "Stop All Runs" mode.

Note: a broadcast during pre-init (either triggered by the events or the above buttons) should avoid putting items into objects with capacity as initial item loadings and state (stoppage) for these objects has not been determined - this is done just before the "Run Start" broadcast is sent

  • increased label width to 63 character (+ 1 internal terminator)

Label selection list now dynamically resizes to the longest label

  • Handling of long labels in dialog fixed (combo box was clipping them)
  • "Comment" calculation type added (in "special")
  • Calculation display is wider, may need to shrink comment area to see it all now
  • table shows owner in "Table" button menu, can go to owner by selecting that option. Solves "Where is this table defined" problem
  • now include owning change object name in routine dump
  • routine exports (TXT file) now get appended


  • Track Logic Change

The lookahead mechanism now resets switches in portals on the other end of track sections which are explored during "lookahead" meaning that it now should be valid to have a switch immediately at a portal with many sections feeding it. The switch should no longer "stick" to the decision made for the first item which tests it.
Note: Cyclic switches will probably not work properly here since the cycling sequence will not be retained.

  • Pipe line display sped up
  • fixed bug with table redraw when the "Edit Original" option is used on a table view


P I P E S -----------

Designed by InterDynamics Pty. Ltd.
Implemented by Riccardo Macri
(C) 1998 InterDynamics Pty. Ltd.

Pipes are the third type of "spatial" connection which can be formed between portals. They compliment track and spatial links for items by providing links for attribute value flow.
The pipe's logical operation and its on-screen representation are quite distinct, hence changing the display properties does not affect the model run results, nor the model run time when advancing without animation.
Logical Model -------------

  • The pipe connects a "Source Att" in the "Source Object" to a "Target Att" in the "Target Object". These will typically be portal attributes of the source and target portals. By default the pipe looks for an attribute called "pipe" but this can easily be changed in the Pipe's Object menu.
  • "Total Time" determines the time between a quantity being collected from the source and deposited at the target (assuming "Run Control" is at 1, more on this later).
  • "Time Resolution" determines how often the pipe "samples" - in effect determining the flow granularity. If the Time Resolution equals the Total Time, the pipe does the transfer in one big "bite".
  • "Load Rate/Hour" determines the overall flow rate at which the pipe draws from the source attribute - with the proviso that the pipe will not draw the source below zero.

The pipe is composed of a number of "logical bins" in series, each bin stores a quantity representing its "level". The number of bins is computed by Total Time / Time Resolution - the finer the time resolution, the more bins.

[source]-->[ ][ ][ ]...bins...[ ][ ][ ]-->[target]
Events get generated at intervals of "Time Resolution", at every event the pipe:

  • shifts its contents one bin towards the target (implemented such that the number of bins does not affect the speed of the shift)
  • "dumps" the last bin into the target attribute (incrementing it)
  • "loads" the first bin from the source attribute (decrementing it by the load amount). The load amount is computed by:

Load Rate/Hour -------------- x Timn Resolution 3600.0
Hence the load amount is less for smaller time resolutions, since more loads are occuring per hour.
The load amount gets clamped to prevent the source attribute being made negative - ie. the "demand" cannot be met. In addition, an object option "Load Integral Values" forces rounding of the load amount, so the pipe always contains an integral quantity without any fractions.
Note: If the load amount per sample is less than 0.5 and the integral values option is on, nothing will be loaded!

Note: Decreasing the Time Resolution (yielding higher resolution) means more events need to be scheduled to keep the logcial pipe updated, this will impact on model performance.

Graphical Representation ------------------------
The graphical display of the pipe has been designed to efficiently display the state of the logical pipe without impacting on model results. In addition run speed is not impacted by complex displays if they are not visible.
The pipe is drawn using a number of straight "sections", bend points may be used to shape curves. Parameters which affect the display are collected in the "Display Settings" sub menu. These include:

  • Display Resolution: This determines the amount of sections into which the pipe is "sliced" for display purposes, in effect determining how granular material flow in the pipe *appears*.

It must be at least the number of bends in the pipe (otherwise the pipe cannot be accurately drawn) but typically a display resolution of at least 100 yields a much smoother result.

  • Border Thickness: Determines the thickness of the border lines of the pipe
  • Pipe Width: Determines the width of the pipe. Interesting effects occur with very wide and bendy pipes!
  • Activity Update: Determines the interval (in ms) over which "activity" highlights in the pipe are moved. These are different coloured bars which "chase" down the pipe to highlight material movement.

The time is in terms of *real* milliseconds, independent of model run speed.

  • Activity Spacing: Determines the spacing of the "activity" highlights in the pipe.

Nice smooth activty effects can be attained using:

  • large display resolution (200)
  • wide activity spacing (15)
  • fast activity update (50ms)
  • a model "Display Update Interval" which yields at least 10 screen updates a second (this depends on the models complexity, CPU and most frequent scheduled event).

Note that this will give a smooth effect even for a pipe with a single logical bin - in more detail:
If there are more bins than sections, some sections will show the average states of a number of bins
If there are more sections than bins, some sections will share the same bin

  • Nominal Load Rate

This gives the pipe a reference from which compute its bin "occupacy" level. This in turn is used to colour the sections when updating the pipe display.
Pipe Colours
These are in a separate sub-menu
Border Pipe border lines Empty Colour used for section if bin level virtually 0 (< 1.0e-12) Low Colour used for section if bin level < 0.25 of nominal Medium Colour used for section if bin level < 0.75 of nominal Full Colour used for section if bin level >= 0.75 of nominal Activity Colour used for the chasing "activity" bars
Note: The display settings "Set To Defaults" / "Set From Defaults" options respectively Set Defaults / Apply Defaults for the pipe graphical setting AND colour selections. The defaults are used for newly created pipes during the current session.

FINALLY: The "Run Control" Attribute ------------------------------------
This is the most powerful parameter in the pipe. The default value of 1 causes the pipe to operate as described above. Changing the value affects things as follows:

  • Setting it to 0 suspends pipe operation. The pipe gets stopped
  • Setting it to 2 DOUBLES the speed of the pipe... the sampling interval gets halved, causing the SAME loads to occur twice as fast. So the pipe doubles its flow rate.
  • Setting it to 0.5 HALVES the speed of the pipe... the sampling interval gets doubled, causing the pipe to halve its flow rate.

And now the surprise:

  • Setting it to -1 REVERSES the operation of the pipe - the target becomes the source, and the source becomes the target. The pipe now flows material backwards.

Any +ve or -ve real value can be used to scale the pipe's operating speed.
The "activity" animation also gets scaled / reversed to highlight the change in the pipes update rate.

  • Whenever* this attribute is changed, any pending update event for the pipe is removed and a new one scheduled for the newly calculated update interval (or none if the pipe is stopped, with a 0).

Attribute Reading -----------------
The pipe uses 7 attribute references which specify its operational parameters. Some of these are only read at initialisation time, others are read on-the-fly.
Only read at pre-init:
Transit Time Update Interval Nominal Load Rate
Read/updated on-the-fly
Source Att Target Att Load Rate/Hour Run Control


    • New file version 193
  • Implemented ranges on column/row operations like Sum, Avg, Min, Max

For old models these are initialised to 1..RowCount or 1..ColumnCount as appropriate if the source is a column or row respectively
These enable sub-regions of a row/column to be worked with

  • Broadcast Buttons

Broadcast buttons send a specific broadcast messages, causing interested broadcast entries to immediately produce an item (of the type of the flow leaving them).
No continue is required, the item is produced once the button is clicked and its event is processed to completion (end of its processing thread).
A "Broadcast/Continue" button continues the run once the broadcast message has been processed.

  • Matched row *** AND COLUMN *** access to tables

The MATCHED CELL attref mode enables dynamic location of rows and columns in a table, rather than using direct indexing.
For the row: A "key column" is searched for a specific "key value". The match is the row which will be used. If the match fails, an error occurs. This match is *by value* so its important that the format of the key column and key value be the same (ie. same label list)
For the column: A string match is sought between the table column label and the label of the attribute addressing the column. (If the attribute is not formatted for labels, its treated as a normal index). In effect it implements a mapping between a label list (eg: _Model Objects) and the column labels of the table.
If the label is not located in one of the table columns, an error occurs
Using the attref COLUMN INDEX mode, a model can determine whether a label matches any column of the table without an error - instead 0 is returned. This is in addition to using COLUMN INDEX to determine the index of a column label selected from that table.

  • "Dont Show Pause Messages" display option

prevents the model from complaining about "no events" and announcing that it has become "paused" which is very useful for interactive models which respond to message buttons

  • Paused click on portal -> Cached Links option now shows each link and the computed distance to it
  • Objects can directly reference the object index of their owning portal this works up hierarchy until it finds an exported portal, if none then 0 is returned
  • Table printing bugs fixed
  • Was not properly recomputing rectangle boundaries during the print. Things were made worse if the screen was at zoom of < 100% before the print.

note: some differences will still occur due to possible different printer device fonts. I lock the table boundaries and the display code fits as many rows/columns as it can depending on the current font metrics. Even different zooms will yield different results especially for non truetype fonts which only render at discrete resolutions.

  • conveyor now reads running time attributes when item first enters

This gives the model an opportunity to set up conveyor delays, as long as it occurs before the conveyor is used.

  • unless items are preloaded into it or fill gaps option on shuttle conveyor is on.
  • When adding a spatial link between portals the system prompts you to provide a name for the portal in the model object list


    • New file version 192, major changes, migrate to with care **


  • Spatial links

A new type of connection between portals, added like a track but they work very differently.

  • No capacity limit, entering item never blocked
  • Item leaving spatial link must never be blocked
  • Item does not need a trip, you set a System-Item attribute to a *final* destination (via a global label) and the item takes the shortest path there
  • section times not specified on the links, you set a total run time on the item and the animation is performed such that the item arrives at the final destination in the specified interval
  • items can have spatial link details set up through a message item
  • New table addressing modes

Instead of addressing a table by Row/Col, one specifies
Key Col, Col and Key Value
The Key Col column is searched for the value Key Value then that row is used to address the cell at column Col
Instead of specifying a row directly, one specifies Key Col and Key Value,
The Key Col column is searched for the value Key Value and that row is then the target row for the operation
In both cases:

  • If more than one row matches "Key Value" then any may be returned... dont expect any preference
  • If no rows match "Key Value" then the model stops with an error

Its intended that these MATCH modes are used where its assumed all expected keys/labels will be in the table, and the labels will be changing order meaning row order cannot be relied upon.
Performance will be slower than using CELL and ROW due to the search so only use where label lists are changing and the tables cannot be kept in index order.

  • New Attref mode enables column label index for any table to be determined
  • in "Column Index" mode you pick a table then set the column reference to "Column Label" mode

At runtime it will return the index of that column
Useful in searching across table rows rather than down

  • tables/mappers are now always addressed using Row/Col even if they have a single column. Old models with single column tables may have a zero "column" attribute which will need to be fixed.
  • placing (via meta panel) an item at a Portal will actually pass the item on to a Queue in the Portal called "_!Catch" - modeller must create this

This enables Portal object location to act as both a spatial link location and a target for placing initialising items

  • Model can query # of objects which are in the object label list (system attribute) - will be useful when remote access of object attributes is implemented
  • tweaks to formatting width for set calculations


  • Queues now properly give error when thrown items cause them to "overflow"
  • log viewer exit fixed
  • printing when paused (backing store re-enabled), not font probs yet
  • dialog centering


  • fixed "attribute" bug with endifs
  • now expects _PL_KEY.KEY for key files (_SV_KEY.KEY still works)
  • reworked label handling so object/route/broadcast label formatted columns can be imported
  • help files now expected in a sub-directory called HELP, not SV_HELP


  • about box precludes other events
  • about box only shown briefly if loading a model
  • spaces in path now handled when launching model directly from explorer
  • bugs handling long names fixed with database
  • dial message introduced in previous version fixed


  • fixed about box problem (was not looking in database)
  • fixed bug in editing first object label introduced in last version


  • dial redrawing reworked
  • fixed dial display updated to attribute value when ctrl-pasting in portal and retaining values
  • avoid flicker between previous and current value (bad for image views) when first redrawing scrn in paused mode
  • New object mode specific icons for entry, exit, change, switch, meta portal also dispatcher
  • cell ctrl-click menu has option selection to select auto across/down for multiple value table entry

problem with ghost boxes being left

  • "none" object added to object list selection
  • now have "about" box for planimate!
  • fixed memory leak in StringList (DeleteAll was not releasing string memory) mainly a problem when browsing icons
  • fixed: lost table row/column property selection in calculation when a table gets renamed
  • object label list reindexing/sorting
  • paint: removed save visible/load painting options since they do not properly save font usage info, causing problems on load. Use portal copy/ paste and the "Other Options"->"Copy All Visible" options to move paint info from panel to panel.
  • icon for loop can be specified from the track menu, no need to hack the system.db file

idkbase note 164