How to Propagate Data with Routings
To be able to exchange information with other objects, data must be able to propagate from one object to another in a deterministic fashion. In CDP Studio, such a connection between objects is called a Routing.
What Is Routing?
One of the most important aspects of CDP Studio is the ability to connect together objects using name-based Routing. It is the basis for allowing truly decoupled objects that you can code once and simply reuse how you want. Each object is decoupled from its surroundings by exposing an external interface. The interface can consist of any CDPNode based objects such as Properties, Signals, Parameters, Messages, CDPPorts and so on, and can be extended by new types as needed. Other objects can connect to this interface by specifying Routing to the object.
A Routing is a string consisting of object names uniquely describing the object location in the Project tree. The Routing string starts with the Application name, followed by the objects that comprise the hierarchical path to the relevant object. Each object in this path is separated by dots.
The Project tree below shows that MotorControl is an Application and MotorCalc is a Component that contains the RequestedSpeed which is exposed as an output:
To use this RequestedSpeed in one or more objects, the value can be retrieved from the RequestedSpeed into your variable by setting up a Routing to it. See below for how to Route a value in the Table Editor and how to Route a value in the Block Diagram.
As long as the Routing accepts the type that RequestedSpeed represents, the specific type of RequestedSpeed is not important. In other words, the Routing source type and the Routing sink type do not have to match. When a value is Routed, it is implicitly converted to the destination type.
A Routed value propagates automatically from the source object to the destination object that has Routing set. It does not matter where the value is located; It can come from an object in the same Application, or from another object in an Application running on a different computer somewhere else on the network. If the Routed value can not be found (it is not reachable within the network, or the source does not exist) then an alarm is set, and the value is continously requested until it is available. The Routing is marked as 'missing' until it is connected.
When a Routing is established, the object starts retrieving its value from the object specified in the Routing.
Note: The source object may update the value asynchronously from the sink object. The sink object will always retrieve the most recent updated value before it is processed. I.e. the source and sink objects may have different frequencies, and the sink will always use the most recently updated value from the source. Objects update their inputs an outputs atomically. In the example above, the RequestedSpeed output is updated at the end of each MotorCalc run.
See Priority levels and scheduling groups for more information about how objects are scheduled.
Note: The Routing path is stored in the object configuration so that it can be read and applied when the Application starts up the next time.
When working with pre-made objects that reside in a structure, it might be beneficial to use relative Routing to access objects.
A relative Routing always starts with a dot ('.'). For instance, '.IsRunning' means to connect to the 'IsRunning' object that resides in the current object. To look for IsRunning in the parent object, specify '..IsRunning'. You can specify as many dots as there are levels in the Application, and you can have more complex relative Routings, for instance, '...MotorCabinet.IO.Feedback.IsRunning'.
|...||Parent object's parent|
|and so on for more dots...|
In the figure below, an object inside MotorControl.MotorCalc.IOHandler can use relative Routing ...MotorCabinet.IO.Feedback.IsRunning to retrieve the IsRunning signal from the I/O.
Note: Relative Routing only works inside an Application, and can not be used to retrieve data from another Application. To address an object in another Application, you must specify the full Routing path.
Routing Using the Block Diagram
In CDP Studio Block Diagram, setting up a Routing is as easy as dragging a line from the source object to the destination object.
Another way to do Routing is to go to the source object, right-click the value and select 'Copy Path'.
Then go to the destination object value, right-click it and select 'Connect From ...'
Routing Using the Table Editor
In CDP Studio Table Editor, you can click into the Routing column and type the name of the Routing source object (or you can paste in the value if you have done 'Copy Path'). When you start typing, the Routing field will auto-sugguest the nearest value(s) to Route from.
Routing in the User Interface
In the User Interface Design mode, there is a property editor that lists all the properties of the selected Widget. All properties that end in 'Routing' have a Routing selector similar to the one in the Table Editor. You can either type a Routing into it, or you can paste in a Routing to a source (or destination) object. See Connecting Widgets to CDP for more information about CDP Widget Routing.
Message objects can be Routed in a similar way to values. In the Block Diagram, drag the message output from the source, and drop it at the destination message input, or use the 'Copy Path' approach as described above.
A CDPConnector is a transport channel for sending messages to an object and for retrieveing status information from an object. The target Object can be set by specifying it as a Routing path on the Connector.
Advanced Routing Concepts
It is possible to set up Routing of multiple values, sort of like Routing a C/C++ 'struct', by using CDPPorts to do bulk transfers of multiple values. A CDPPort lets you control one Routing to batch-connect multiple-values in any pre-configured direction.