Flavors Technology Incorporated |
PIM/Paracell Product Summary |
|
In a typical complex application, one PIM can replace up to 25 programmable devices, providing a tightly-coupled solution. The PIM can interface to many tens of thousands of I/O points through industry standard local area networks. The PIM must also be able to interface to the general purpose computers that oversee the non timecritical aspects of an application. To that end, the PIM comes equipped with powerful and flexible distributed I/O subsystems.
All PIM I/O (with the exception of I/O to the development workstations) is performed through I/O memory, a subset of shared memory.
As explained in earlier chapters, the raw control resources available to Paracell programs consist of from hundreds to thousands of cells communicating with one another through shared memory.
Figure 4-1.
PIM I/O encompasses data points, data collection terminals, data display terminals, and the shared memory of other computers. Paracell views I/O in real time through I/O variables which are defined at configuration time. Once I/O configuration is completed, from the tiles' point of view there are no differences between I/O variables and other global variables. The PIM hardware and software make transparent the association between the I/O variable and the data point.
Figure 4-2.
In the above example, the I/O variable "water-temp", is referred to by name as are other variables.
The I/O for a PIM installation is configured into the PIM via I/O tiles. I/O configuration need only be done at installation time and when hardware modifications are made. During development and use, data points are referred to by name.
The I/O configuration process involves loading the workstation database with an I/O map of the application, whereupon I/O variables may be defined and mapped.
Figure 4-3.
I/O tiles are easily recognized by the distinctive icon shown above. As is true with other tile types such as Paracell Tiles, Navigator Nodes, or SoftScopes, an I/O tile can be documented, and colors, patterns or icons can be selected by the developer (see Figure 3-17).
The Configuration Editor (ConED) is used for providing the workstation database with a map of application I/O. It is here that the developer lays out the physical definition of the configuration.
The left-hand side of the ConEd window provides the layout in a hierarchial list of the application configuration, from the configuration of the PIM at the highest level, to individual adapters on I/O personality cards, and the tiles that relate to that specific adapter.
The right-hand side of the ConEd window provides detailed information on the value/device selected on the left, in this case "Adapter 0".
Figure 4-4.
Having defined the physical I/O configuration, the final step in connecting the application database to the real-world I/O is the linking of I/O variables to physical points. This is accomplished in an I/O Tile.
The variable names are already known to the database, having been defined in the various Paracell Tiles. If a variable name is used that the database is not aware of, the author is prompted to either select the correct variable name or define this value as a new variable.
Figure 4-5. In the I/O Tile, the variables listed on the left correspond to the data points listed on the right.
The I/O tile window can be expanded out so that the author can follow the path of the variable or point.
Figure 4-6.
In order to support the mapping of PIM global variables to the plethora of possible networks and devices, a flexible hardware platform has been developed.
4.a A General Purpose Design
With the exception of the development workstation, all external devices must interface to the PIMbus through an I/O board. Because the PIM must interface to a large variety of devices, the I/O board is only part of the solution. The I/O board, which has a general purpose design, talks to the outside world via an I/O Interface Board designed to interface to one or more external networks or computers.
An I/O interface board is known as a FIM, or Field Interface Module. Each I/O board is connected to at least one FIM. The FIM varies in design according to the device(s) to which it is connected.
Figure 4-7. In the above examples three I/O boards of common design are each connected to a different FIM.
4.b I/O Memory Arbitration
Because I/O memory is dual ported, measures have been taken to prevent data collision. I/O boards will not read the I/O memory until the multiprocessor boards have finished exporting, and I/O boards will not write new values into I/O memory until the MP boards have finished importing.
Another way to look at this is to consider the behavior of I/O tiles during a PIM frame. I/O tiles behave just as Paracell tiles do with this caveat: On a read cycle, I/O tiles export values to shared memory. On a write cycle, I/O tiles import values from shared memory.
Figure 4-8.
Arbitration is made easy because data points can be cleanly divided into two groups. By the synchronous nature of the PIMbus, every PIM frame the PIMbus is first in read mode, then in write mode. The transfer of data points between I/O memory and the field is handled by a processor on the I/O board or by an external device, and does not affect PIM performance.
Chapter IV: Reliability
Back: Paracell, last section
Table of Contents
Return to Top of Page
Flavors Technology, Inc. |
Copyright© 1993-6 by Flavors Technology, Inc. All rights Reserved.