CtrlX
| This driver is unfinished and not usable yet. Pinging is the only thing that works; discovery is an unimplemented stub, there is no tag address syntax, so reading and writing are not available, and the browse implementation does not work yet either. This page describes the current state for anyone continuing the work - it is not linked from the navigation. |
The CtrlX driver talks to Bosch Rexroth ctrlX CORE devices through their REST/Data-Layer API over HTTPS, rather than over an industrial fieldbus protocol.
Supported Operations
| Operation | Description |
|---|---|
|
Checks that the device is reachable and the credentials are accepted. |
|
Not implemented. The driver hands out a discovery request builder, but
|
|
Does not work yet. The connection carries an implementation that is meant to enumerate the device’s Data Layer nodes, and it is the furthest along of the unfinished operations, but it does not produce usable results. |
|
Not implemented. The corresponding request builders return |
The connection reports read, write, subscribe and browse as unsupported in its metadata, so a
caller that checks getMetadata() before deciding what to do gets an honest answer rather than
being sent into a request that cannot succeed.
Connection String
ctrlx:https://{host}
ctrlx://{host}
https is the only supported transport, and it is also the default - so the transport part can be
omitted. Any other transport is rejected with
Only 'https' transport is supported by this driver.
Authentication
A CtrlX connection always requires a username and password. Obtaining a connection
without authentication throws CtrlX connections require authentication., and an authentication
object that is not a username/password pair is rejected as well.
|
PlcConnection connection = new DefaultPlcDriverManager()
.getConnection("ctrlx://192.168.1.1",
new PlcUsernamePasswordAuthentication("boschrexroth", "boschrexroth"));
Connection Options
| Name | Type | Default | Description |
|---|---|---|---|
|
STRING |
Key store of certificates to trust, instead of the JVM’s public authorities. |
|
|
STRING |
Password of the trust store named by |
|
|
STRING |
|
Type of the trust store named by |
|
STRING |
PEM certificate of the device to trust, for a device carrying its own certificate rather than one issued by an authority the JVM already knows. |
|
|
BOOLEAN |
|
Trust the factory default certificate that ships inside this driver’s jar, for any host. See the warning below. Setting it logs a warning. |
|
BOOLEAN |
|
Accept a device certificate issued for a different host than the one connected to. |
|
INT |
|
Largest number of nodes a single browse will read; |
|
INT |
|
How deep a browse will follow children; |
The driver used to trust the Bosch factory default certificate bundled in its own jar, and
to trust it instead of the platform’s authorities rather than in addition to them. That
certificate identifies nobody - anything holding it and its key was trusted, for any host - and the
username and password travel over that channel. Because it was also the only trust anchor, a device
with a properly issued certificate could not be reached at all. A device still on its factory
certificate now needs allow-factory-default-certificate=true, and the better answer is to give the
device a certificate of its own and name it with server-certificate-file or a trust store.
|
A browse walks whatever tree the device describes, and nothing in the answer says how large that
tree is or that it ends, so browse-max-total-nodes and browse-max-depth bound it. Reaching
either one warns and returns what was found rather than failing.
Browsing
| Browsing does not work yet. What follows describes how the existing implementation is meant to be used, for whoever picks the work up. |
Browse queries are glob patterns matched against the Data Layer node paths, not tag addresses.
** matches everything and is intended as the simplest way to see what a device exposes:
PlcBrowseResponse response = connection.browseRequestBuilder()
.addQuery("all", "**")
.build().execute().get();
The driver has no tag address syntax of its own - parseTag is not implemented - which is the
reason read and write are unavailable.
Discovery
Discovery does not work yet. CtrlXDriver.discoveryRequestBuilder() returns a builder backed
by CtrlXPlcDiscoverer, whose discoverWithHandler is still an empty TODO returning null, so no
ctrlX CORE device is ever located.
|
Maven Dependency
The driver is not part of the plc4j-driver-all meta package while it is unfinished, so it has to
be added explicitly:
<dependency>
<groupId>org.apache.plc4x</groupId>
<artifactId>plc4j-driver-ctrlx</artifactId>
<version>1.0.0</version>
</dependency>
| The driver declares no connection-string parameters of its own, which is why this page has no generated options table like the other protocols. Everything it needs comes from the host in the connection string plus the credentials. |