Planimate has a few fundamental types for storing information in a model.
Attributes store a single value or string of text and are useful for key parameters, constants and control variables in routine code. They can be formatted to a number of different in-built formats which are used during data input and display.
Tables consist of rows and columns, with each column having a different format assignable. As well as storing data, tables are the data source for a number of different table views including graph plots.
Label Lists are a collection of name/value pairs and are useful for defining sets of identifiers (eg: location names). Attributes and Table Columns can be formatted to indicate their data are members of a label list. Planimate exposes many internal label lists to facilitate its advanced routine operations.
Item Classes can have a number of item and table pointers assigned to them, as well as being able to carry other items. This makes them a type of data in Planimate as well Through a process that is called Tupling in Planimate, an item can transfer its attributes to a row in a table where columns have matching names.
DataSet is a system for loading and saving data in a Planimate model featuring compression, encryption and mechanisms to cope with an evolving model.
Data Connectivity and Integration
The Planimate® Platform currently supports a variety of data transfer mechanisms:
- Open Database Connectivity (ODBC) connectivity to and from a wide range of data sources like DB/Spreadsheet etc.
- Reading and Writing of Plain Text files (tab delimited, comma separated, HTML)
- TCP/IP Data Packet transmission (XML formatted) through Client and Server Sockets and ports.
- HTTP request processing (Web Enablement) and URL fetching.
Data Exchange during a Model Run
Data can be both imported and exported during a Model Run. The exported data comprises the current value of selected attributes, and Tables. Imported Data is assigned to various Attributes, or Tables. You can select the Attributes that you wish to write, using the Attribute Selection Dialog.
Any item passing through a Change Object set up for Data Exchange triggers a Data Exchange event. There are a number of options for data transfer using a Change Object.
Data can also be loaded and saved using Planimate®’s own DataSet features. This can be done during a Model Run, either manually from under File in the Menu Bar, or under the control of the Model itself using Routine operations.
Clipboard Handling in Planimate®
Individual Text strings or numeric values can be copied and pasted using the usual Ctrl-C and Ctrl-V access to the Clipboard.
Table Cells or Selections can be copied to the Clipboard using the Right-Click context menu on a table cell or selection. Copied table data is put into the Windows clipboard when another application is brought to the foreground. (e.g. Using Alt-Tab). Tables copied to the Clipboard include their Column Headings, for convenience. The data is Text and is formatted as seen in the Table Cells.
Pasting Data into Tables from the Clipboard
You can use the windows clipboard to copy data into tables in Planimate.
This is done from the Table Editor Window Menu Bar via File / Import from Clipboard or from a Cell/Selection context menu "Import from Clipboard" option. These only appear if there is data in the clipboard.
Note that only entire Tables may be Imported - partial Table import from Clipboard is not supported.
Setting Clipboard Defaults
In the Table Editor Window under File in its menu bar, you can specify some defaults that will determine what data is transferred to and from the clipboard.
Configure Clipboard Import Defaults You can choose default options to apply to Data Import from the Clipboard. Various options can be selected.
Configure Clipboard Export Defaults You can choose default options to apply to Data being copied to the Clipboard from this table. Various options can be selected.
Planimate® has been successfully used as a back end application, activated through web applications. Users enter data through their Internet Browser, which is processed through a script. The Planimate®-Based Application (PBA) is called and run, and outputs are returned in tabular and graphical form via the script.
InterDynamics has also developed an API for the creation of DLL's that can extend the capabilities of a PBA in specific areas, making its ultimate functionality open-ended.
The above features magnify the potency of competitive advantage derived from the adoption and use of PBA’s. PBA’s are not limited to the individual workstation. PBA’s can comfortably reside and operate reliably in a larger IT environment, and can obtain, process and deliver information to multiple users throughout the organisation, operating in interactive graphical, or engine-like modes.
Web Enablement of PBA's
Planimate® Data Exchange options enable the acceptance of data inputs via HTML forms, and the presentation of outputs, in tabular and graphical form via either HTML tables, or JPG/GIF images, suitably converted and processed through the ASP script. Planimate® is also capable of directly outputting textual/numeric data pre-formatted as HTML.
The sockets will carry streams of 8 bit ASCII clear text. Planimate® will send and expect broadcast “packets” formatted in an XML based format.
A packet will look like this:
<model name=”model name”
time=”1 Jan 2001 00:00:00”/>
attribute4=”misc info 1”/>
A separate packet is sent for every model broadcast associated with a socket. Upon receiving a valid packet, Planimate® will generate a broadcast and use “tupling” to set the attributes of the target class to any matching attribute available in the packet.
format="raw” specifies the attribute values are unformatted values
format="normal" is the default and specifies formatted values
A received broadcast will have the values processed as determined by the value/presence of this tag. A broadcast can be sent with unformatted values by adding "2" to the "use item" field in the change object "broadcast" routine operation (ie: the value should be 3 instead of 1 to cause attributes to be sent without any formatting).
Debugging Attributes in Models
Portal Attributes are capable of capturing information from, and also informing, a number of different model components simultaneously. It could be that the information currently held by a Portal Attribute is incorrect for some of the components. This raises the issue of the ordering of Portal Attribute operations.
Using the Pause at Events Debugging Option to perform Event Stepping becomes extremely slow and frustrating in a large model.
Instead, use the on-screen display features of attributes to provide an " on the spot " explanation of the " unseen " activity of the Model.
Where conflicting operations occur simultaneously in a model using attributes to control or regulate various aspects, strange model behaviour may be difficult to track down.
The most easily addressed solution to this problem is to keep control mechanisms and attribute references local to one area. You still have the same challenge, but limiting it to one screen makes maintaining the model easier.