Additional Inherited Members
- 90 public functions inherited from CDPComponent
- 37 public functions inherited from CDPObject
- 42 public functions inherited from CDPBaseObject
- 26 public functions inherited from CDP::StudioAPI::CDPNode
- 22 public functions inherited from CDP::StudioAPI::ICDPNode
- 2 static public members inherited from CDPComponent
- 6 static public members inherited from CDPObject
- 1 static public member inherited from CDPBaseObject
- 12 protected functions inherited from CDPComponent
- 13 protected functions inherited from CDPObject
- 1 protected function inherited from CDP::StudioAPI::CDPNode
- 31 protected variables inherited from CDPComponent
- 7 protected variables inherited from CDPObject
- 9 protected variables inherited from CDPBaseObject
- 1 static protected member inherited from CDPObject
The PortMUX component is a multiplexer for CDPPort objects where Index=0 selects the first input port and propagates the connection or data to the output port.
PortMUX is useful when one needs to switch between different CDPPorts coming into your component to change the source of control values or data utilized. PortMUX supports any CDPPort object. Both data ports and proxy ports are suitable for PortMux usage. Port types used in the multiplexer should be compatible, allowing any input port to connect to the output port.
Note the following features are only available when the MUX contains data ports (ports that either use ValuedConnections or are code ports with local properties):
- NoSwitchDelay - when the multiplexer Index changes, normally the port reconnection will occur and that takes several cycles to complete. However, with data ports that only contain local properties, data is propagated without actually connecting the ports, starting from the same cycle the Index changes.
- EnableReverseProxy=Values - when set, reverse propagates values through all possible port chain connections regardless of the MUX index selection. See Advanced: Configuring EnableReverseProxy.
To set up the PortMUX multiple input ports and a single output port is required in configuration.
|Index||Input port selection where value '0' selects the first added input port for output port connection. Overflow Index values will always fall back to the last input port.|
|NoSwitchDelay||NoSwitchDelay is set when Ports in multiplexer all have local data properties allowing no-delay switching to be possible.|
|EnableReverseProxy||When set, reverse propagates values through all possible port chain connections regardless of the MUX index selection. See Advanced: Configuring EnableReverseProxy.|
When adding ports with local data to PortMUX the data direction on input ports and output ports must match. The simplest is to think that the data coming in from the input port must go out from the output port and the other way around. Inside the multiplexer, the data connections are made automatically and should not be manually created.
Advanced: Configuring EnableReverseProxy
When the EnableReverseProxy property is set, values are reverse propagated from end to start through all possible port chain connections regardless of the MUX index selection. This option is useful in redundancy and diverging input and output paths. The Messages flag is meant for enabling reverse propagation of GUI app value changes and the Values flag for regular routed values within the control system. Note, the latter only works on data ports (both input and output ports must either use ValuedConnection or be code ports with local properties).
When setting up a PortMUX with EnableReverseProxy turned on, it is important to get right the Input flag of port connections. Here is an image to take as an example. The upper part of the image shows how a PortMUX is used in a component and the lower part shows the implementation inside the PortMUX. All connections within ports are of type ValuedConnection to enable NoSwitchDelay and to support also reverse proxy of values.
- When using EnableReverseProxy=Messages, follow the Msg nodes on the image above. Setting the Messages flag means that if a GUI application connects to End.Msg, then changes done in GUI are reverse propagated to both MsgStart0 and MsgStart1. Note forward data propagation also still works (as GUI widgets allow two-way value binding). When changing MsgStart0 (presuming PortMUX.Index=0), the value is propagated to MsgEnd (but not MsgStart1 because value change was not initiated from End.Msg).
- When using EnableReverseProxy=Values, follow the Val nodes on the image above. When the Values flag is enabled and ValEnd is changed, the value is propagated to both ValStart0 and ValStart1. Otherwise, when the EnableReverseProxy is disabled, it would have only been propagated to ValStart0 (presuming PortMUX.Index=0).