Exemples de programmation et de configuration du DXM

The associated XML configuration file can be loaded into a DXM100-Bx Wireless Controller. This configuration file includes examples of several functions and operational aspects of the DXM Wireless Controller. This configuration does not require remote radios.

The associated XML sample programs can be loaded into a DXM150-Bx or DXM100-Bx Wireless Controller.

The Sample Timer XML provides an example of a continuously running timer that resets at different time intervals. It does not require remote radios connected to the DXM1x0 to function. The timer is always running. The DXM display LEDs are enabled by universal input 1 on the DXM100 and isolated input 1 for the DXM150. The input is labeled LED Enable. When the LED Enable input is active, LEDs 1, 2, and 3 on the DXM turn on for 5, 10, and 20 seconds respectively as defined by Action Rules. The timer automatically resets at 25 seconds, then LEDs 1, 2, and 3 are again turned on. This ongoing timer can be used for OEE applications, etc.

One-shot Timer XML provides an example of a timer sequence started with the rising edge transition of the Input Trigger. The InputTrigger is universal input 1 on the DXM100 and isolated input 1 for the DXM150.

All timer and input values can be observed via the display of the DXM.

This sample tank level application allows users to set alert ranges using action rules. A K50U Ultrasonic sensor monitors tanklevels. A Wireless TL70 Tower Light uses the red and yellow lights to signal tank levels.

This configuration file starts with a basic monitoring of the battery and incoming power to the DXM100-Bx Wireless Controller. Italso monitors the Universal Inputs of the DXM Controller and the time that it is operating on battery or a power supply.

In addition, the XML is designed to monitor the distance from a K50U ultrasonic sensor connected to the DXM100-Bx WirelessController using a Wireless Q45U Node. The results of the distance measurement are then transferred to a three-color (green,yellow, red) TL70 wireless stack light.

This provides the customer with a method for using a three-color tower light to indicate five statuses. The primary use of theNearing Too Full and Too Full red LED status was to allow the operator time to fill the tank.

Machine operators are more concerned with the Proper Amount (green), Nearing Empty (yellow). and the Empty (red) statuses.Generally, if the green light was not on, they wanted to start filling the tank. If during the tank filing operation the tank wasoverfilled, they also wanted time to take corrective action.

The XML configuration file includes examples of how to use the action rules for monitoring aspects of the DXM100, and there is a schedule set up for emailing stored logs on a weekly basis.

This ScriptBasic example reads three registers from an external Modbus temperature/humidity probe connected to the master RS-485 port (pins M+/M-). The external Modbus device is defined as ID 8 in this ScriptBasic program.

See the ScriptBasic manual for more information on the individual functions.

ScriptBasic can be used to create custom push intervals to a web server. Because the Real Time Clock (RTC) is available to ScriptBasic, ScriptBasic can use the RTC to push data that is aligned to time throughout the day. The program is fairly simple and can be used for any events that need to coincide with wall clock time.

Use the programming language ScriptBasic on the DXM Controller to map inputs to outputs of different scales. The ScriptBasic program (NullSpanV2.sb) and associated XML configuration file (NullSpanV2.xml) show an example of how this is accomplished.

When converting between different input/output types, define these four key parameters:

Null

On the input side, Null defines the starting point.
In this example, the Null value is –20 ⁰C (the starting of the output range).

Span

Defines the total range of the input.

In this example, Span is 80. The temperature range starts at –20 °C and therefore ends at +60 ⁰C.

Output Range mA

Defines the total output range. In this example the output is a current (mA) output with a total range of 20000 μA, or 20 mA. For a 4–20 mA output, the range is 16000 μA, or 16 mA.

Output Range mA Offset

If the output range starts at zero, the offset is zero.

For example, 0–20mA. If the range is 4–20mA, the output offset is 4 mA.

This example uses a ScriptBasic program to calculate the heat index. These calculations are too complicated to use Action Math Rules but are easily accomplished with ScriptBasic. For more DXM Controller information, refer to the appropriate instruction manual.

Use the DXM Controller and Action Rules to read multiple inputs, logically OR the values, then write the result to an output or outputs. There are unlimited variations that can be accomplished using Action Rules and Read/Write maps.

This example does not explain how to use the DXM Configuration Tool or discuss details of the DXM Controller configuration.

Monitoring device health is important to do in a network to ensure that all devices are communicating, and all data is up-to-date. This example will cover using a DXM to monitor device health (either MultiHop radios, or Modbus devices) and send an output when a device is no longer communicating as it should.

This tech note will explain how to use the Bit Packing and Unpacking files with the DXM controller. The required equipment is a DXM700, DXM1000, or DXM1200 controller and up to 47 of P8 or P7 nodes.

P7 and P8 radios are Performance radios that have 12 configurable I/O. They are bit-packed radios, which means that all inputs are packed into a single register for each radio, and all outputs are packed into a separate register. It is possible to mix and match the IO so that you can have any combination of inputs and outputs that add up to 12 (7 in and 5 out, 3 in and 9 out, etc.). The Bit Packing and Unpacking files will unpack the single bit-packed input register into individual registers on the DXM that will just show a simple on/off value (1 or 0). The files will also handle the bit packing to control the outputs on the P7 or P8 radios. This allows the user to simply change a register from a “0” to a “1”, or vice versa, to turn on and off outputs on the P7 and P8 radios.

Lastly, these files are pre-configured to be compatible with ProfNet (up to 47 nodes) and Ethernet/IP (up to 17 nodes).

Monitoring the incoming power to the DXM IO-Board is a good practice to ensure the power supply for the DXM is supplying sufficient voltage and current, especially if the DXM is powered off a battery (such as a 12 V SLA battery commonly used in solar-powered applications). Note that this is only available on DXM100, DXM150, and DXM1000 models.

From the IO-Board, it is possible to read the following:

1. Battery Voltage (mV)
2. Battery Charging Current (mA)
3. Incoming Supply Voltage (mV, solar or power supply)
4. On-Board Thermistor Temperature (°C)

Many Banner radios, such as the K70 wireless touch buttons, have a latching input. It can be useful to use Modbus commands so that this input can be cleared without having an operator manually clear the latch by pushing the button a second time. This example will go through reading in the latching input on a K70 wireless touch button and will when a register in the DXM transitions from “0” to “1”.

Conducting a site survey remotely can be very useful if the DXM is in a location that is hard to reach in person. Using modbus commands, it is possible to conduct a site survey and read the results over serial or ethernet. This example file allows a register to be changed from a “0” to a “1” to conduct a site survey to a performance node. The results from that site survey is then stored in the DXM’s local registers and can be read remotely. Note this file is only intended for use with the performance radios. These files are also setup for Ethernet/IP.

Using a vibration sensor is a good way to determine if an asset is running or not. When an asset is running, the vibration should be at a much higher level than when it is idle. By monitoring the vibration, and setting a threshold at a certain level, it is possible to determine if the asset is running or not.

The following sensors can be used to monitor vibration:
QM30VT1
QM30VT2
DX80NxQ45VA

Ensure to use a compatible radio with the QM30 sensors. The QM30VT2 may also be wired directly to the DXM.

Monitoring node health is important to do in a wireless network to ensure that all radios are communicating and providing up-to-date data. This example will cover using a DXM to monitor node health and send an output when a node drops communication.

The health register for performance nodes is always I/O 8 (register 24 for node 1, register 40 for node 2, register 56 for node 3, etc.). The value of this register will be “128” when the node is in normal operation. When the value is NOT 128, then this usually indicates some type of error. The most common error code to appear here is “13569” which indicates a link loss. However, it is usually best (and easiest) to monitor this input and fire an output whenever the value is NOT “128”.