In addition to the
service interface types, which use communication networks for exchange
of data, and the
service interface types described under the Local Multicast pattern, only the
two additional functional block types shown below
are required. The function of these these blocks is to translate data
from a local multicast group to a remote multicast group (
) or vice versa (
) according to the following features:
IDinput. For convenience, the default value of this input is set to the function block's instance name. This can be overridden by connection to a non-default variable or configuration parameter.
TYPEinput as a comma-separated list of data types, e.g.,
An abstract internal implementation of each of these function block
types is shown below for the case when a single data element is being
transferred. The actual number and types of data being transferred is
determined by the
input as explained above.
The FBDK provides built-in support for the use of tagged data when a system configuration is being edited:
TAGOUT/TAGINservice interface types in the system configuration.
PUBLISH_n/SUBSCRIBE_nblocks using the same tag.
PUBLISH_n, SUBSCRIBE_n, PUBL_n, SUBL_n, TAGOUT, or
TAGINtype by selecting the tag in the Tags table, then using the Drag and Drop gesture to drag the tag from the table to the instance name of the FB. For instance, in the example below the
TRANSPORT_SENSEtag data is applied to the
The methodology for using this design pattern consists of the two steps listed below. It can be used as a sub-pattern to simplify and avoid errors in the Distribution phase of other methodologies, such as the layered MVC pattern.
FRAME_DEVICE, using the local multicast pattern. As an example, see the
FLASHER_TESTL, using the Move To pop-up menu item on a resource in the Navigation tree.
RMT_FRAME, as appropriate.