Networked EXRCPU or EXRLCPU units

Networked eDAQXR/eDAQXR-lite units can be connected in a variety of ways.

Networking Modes: There are two modes that are supported. There is an SXR test configuration option to specify the desired mode. See Test setup > Network mode for more information.

Mode 1 Networking

One eDAQXR/eDAQXR-lite serves as the networked system host (subsequently referred to as the master node), and all other connected eDAQXR/eDAQXR-lite units provide source data to the master node (subsequently referred to as slave nodes). The master node is not defined in the SXR setup file. When the user starts a test on any network node, that node becomes the master node. This allows the user to experiment with CPU load balancing which is discussed later.

The master node is always used to start the test. The master node runs the test engine that processes all input channels, Computed channels and DataModes and drives the run time displays. A single SIE file is generated on the master node only.

The user only needs to communicate with the master eDAQXR/eDAQXR-lite.

All test runs modes (Normal, Cyclic and Remote control) are available in a networked system. If the Remote control run mode is used, the EXRCPU/EXRLCPU IO switch 1 on the master node must be used.

Mode 2 Networking

The primary difference between Mode 1 and Mode 2 from the user point of view is that every node runs a test engine and generates an SIE file. This mode will typically only be used when Mode 1 cannot be used due to CPU processing limitations on the master node, or when there is insufficient SIE file storage space on the master node.

While each node generates an SIE file, the SIE files are logically linked together. When the SIE file is downloaded on the master node (or on any slave node), the system generates a composite SIE file containing all of the data from all nodes. Similarly, if the user deletes an SIE file on any node, the SIE files on the other nodes are also deleted.

NOTE
There is the following restriction on the current offering for Mode 2 networking.

• Channels cannot be shared across the network nodes (i.e., channels defined on any given node
cannot be used on another node for DataMode triggering, use in a computed channel, etc.).
The user interface does not prohibit this. If the user configures as SXR test in this way, the user interface will attempt to start the test run. However, the system will reset on error.

Physical Connection Options: These options are completely independent of the option to use Mode 1 or Mode 2 networking.

Connections with no EX23-R switch: A maximum of three eDAQXR units can be connected. A maximum of two eDAQXR-lite units can be connected.

  1. For a minimal two eDAQXR node system, connect either of the ETH ports on one node to either of the ETH ports on the other node. For the two eDAQXR-lite node system, connect the E1 port of the first node to the E1 port of the second node.
  2. For a three eDAQXR node system, select one node (the first node) to use both ETH1 and ETH2 ports. Connect one of the ports on the first node to either of the ETH ports on the second node, and connect the other port on the first node to either of the ETH ports on the third node.
  3. Unused eDAQXR ETH ports can be used for other network devices such as MX modules, Axis cameras routed through a commercial POE switch, etc.

Connections using one or more EX23-R switches: There is no restriction on how many eDAQXR nodes can be connected.

  1. Currently, the only officially supported connection mode is to connect all eDAQXR/eDAQXR-lite ETH1 ports to one of the EX23-R ports, and to connect nothing to any of the eDAQXR ETH2 ports.
  2. Unused EX23-R ports can be used for other network devices such as MX modules, Axis cameras routed through a commercial POE switch, etc.

CPU load balancing (Mode 1): For many applications, the user does not need to be concerned with this issue. However, if the average CPU load of any node exceeds 50%, the user should consider options for balancing the CPU loads across the nodes, which may require some trial and error experimentation. Following are some guidelines.

  1. The master node will typically have the highest CPU load. It is usually best to configure the units so that the slave nodes have as many eDAQ/eDAQ-lite layers as possible. Similarly, assign most MX modules and Axis cameras to slave nodes. EXRCPU/EXRLCPU CAN and GPS interfaces are processed almost completely in the test engine and so it is not very important which node these are connected to.
  2. Source data streams from MX modules, Axis cameras and future network data are assigned to one of the eDAQXR/eDAQXR-lite network nodes for “first level” data handling. These network sources are all assigned to the master node by default. However, the user will often want to assign these to one of the slave nodes. Note that these network node assignments are completely independent of the physical ETH port network connections.
  3. With a system configured, it is advised that the user run some check out tests with the System channel “cpu_load” added to the test for each network node. Start the checkout test and let it run for 5 minutes or so. Analyze the SIE data for these channels to assess the load balancing and decide if further action is required.
  4. Bear in mind that adding run time displays will place additional (and often significant) load on the master CPU. As such, if these are not already defined in the checkout tests, configure the test so that the master node CPU load is as low as possible.

CPU load balancing (Mode 2): While this is somewhat less of a concern relative to Mode 1 networking, the master node still has the processing overhead for interacting with the user interface and running the display charts. As such, the suggestions above for Mode 1 networking are still applicable.