Resolving Rapid SCADA Setpoint Value Mapping Errors

After the command mapping is corrected, the operator can select 10, 50.5, or 101.5 and the device receives that setpoint instead of the selection index 0, 1, or 2. The screen is displaying the intended labels; the output binding must translate the underlying command value.

What is the screen actually sending?

A dynamic-text command with three entries has two distinct value sets: the text shown to the operator and the command value generated by the selected entry. With labels configured as 10;50.5;101.5, Rapid SCADA enumerates the available choices. The first selection generates 0, the second generates 1, and the third generates 2.

Changing the visible text does not change those underlying enumeration values. The tag is right; the binding is wrong when the output channel passes the selection index directly to the driver.

Operator selection	Command value	Required device value
10	0	10
50.5	1	50.5
101.5	2	101.5

Confirm this layer first: operate each screen choice and observe whether the command path reports 0, 1, and 2 in the same order. That proves the display control is enumerating its entries as designed.

Which channel must carry the setpoint?

A working input channel proves that Rapid SCADA can read from the device. It does not create a write path. Commands require an output channel, called a control channel in some interfaces or documentation, bound to the correct device and command destination.

Setting	Location	Effect
Dynamic-text choices	Webstation view or command control	Displays the selectable labels and generates their enumerated command values
Output channel	Server configuration	Receives the command, applies the assigned output formula, and routes the result
Device command	Communicator configuration	Associates the server command with the driver destination
Device address	Driver command configuration	Selects the OPC item or device register to be written
Input channel	Read configuration	Returns the device value for end-to-end confirmation

For a Modbus installation using address 2109 as a pH setpoint, bind the output channel to the command that writes that address. The address is installation-specific; verify it against the device register map and the driver's addressing convention. A successful read from address 2109 does not prove that a write command exists for it.

Check the configuration by confirming that the screen control references the intended output-channel command number and that the command references the intended Communicator device. Do not continue until all three objects form one path.

Where does the command formula execute?

The command entry point determines whether Rapid SCADA evaluates the output formula. A Webstation command travels to Server, where the output-channel formula can transform it. Server then passes the transformed result to Communicator. A command entered directly from Communicator does not pass through the Server calculation stage.

Command source	Path	Formula applied?	Best use
Webstation	Webstation → Server → Communicator → device	Yes, when assigned to the output channel	Testing the operator's complete production path
Communicator command interface	Communicator → device	No Server calculation	Testing driver addressing and a raw device value

Both command methods can work, but they answer different questions. Use Communicator to prove that the driver can write a known raw value. Use Webstation to prove enumeration mapping, Server processing, driver transmission, and device acceptance together.

The message The command has been sent successfully indicates that the command was passed from the command interface to the service. It is not proof that Server evaluated a formula, that a protocol frame reached the device, or that the device retained the setpoint. Confirm the chosen test path before interpreting that message.

How should the enumeration be mapped?

Command formulas must use Cmd, not Cnl. Cmd contains the output command value being processed. Cnl belongs to channel-value calculations and can produce 0.00 or otherwise incorrect behavior when used for command mapping.

For evenly spaced integer outputs, a direct expression is sufficient. The mapping (Cmd*256)+256 converts command 0 to 256 and command 1 to 512. This conversion occurs only on the Server path.

For non-linear setpoints, create a function that maps every allowed command index:

double Out_real(double cmd)
{
    if (cmd == 0) return 10.0;
    if (cmd == 1) return 50.5;
    if (cmd == 2) return 101.5;
    return cmd;
}

Then assign the output-channel formula:

Out_real(Cmd)

The final return is required because a function must return a value from every logical path. Select the fallback according to the device's operating policy. Returning cmd exposes an unexpected index for diagnosis; a production configuration may instead route invalid choices through an approved safe-value or command-inhibit strategy.

All formulas return a double, including mappings whose results look like integers. The downstream driver or OPC item still has its own data type. Verify that it accepts the required numeric range and decimals. A working integer command does not prove that a decimal value such as 50.5 can be represented at the destination.

Compile the formula and exercise it with inputs 0, 1, and 2. The required outputs are 10.0, 50.5, and 101.5. A Formula Tester project can isolate compilation and branch errors before the formula is attached to the live output channel.

How is the formula connected to the command path?

1. Create or select the output channel used by the screen command. Input channels alone cannot transmit a setpoint.
2. Assign Out_real(Cmd) to that output channel. Do not place the mapping only in a read-channel formula.
3. Bind the output channel to the intended Communicator device and device command.
4. Configure the driver destination using the address or OPC item defined for the setpoint.
5. Confirm that the destination's data representation can carry the mapped value, including its fractional part.
6. Issue each command from Webstation, not from Communicator, while testing formula execution.

Byte or word permutation is a separate issue from selection mapping. OPC commonly presents an already typed value, so adding a byte permutation without a measured byte-order problem can corrupt a correct setpoint. For a direct device driver, inspect the register representation only after the line log proves that the correct mapped number reached the driver. The check at this stage is that Server receives 0, 1, or 2 and hands the corresponding setpoint to Communicator.

What does the communication-line log prove?

Inspect the communication-line log when the command acknowledgement appears but the setpoint does not change. The installation described uses:

C:\SCADA\ScadaComm\Log\lineXXX.log

Replace XXX with the applicable communication-line identifier. Match the log timestamp to one deliberate command so normal polling traffic does not obscure the write.

A captured Modbus transaction showed:

Send (8):    04 06 00 01 00 01 19 9F
Receive (5): 04 06 00 01 00
Receive (3): 01 19 9F
OK!

The transmitted fields identify device address 04, function 06, register field 00 01, and data field 00 01. The data field proves that the driver sent 1, not the formula result 512. An OK! result proves that the exchange completed at the protocol layer; it does not turn 1 into 512.

Observed result	Likely boundary	Next check
No command entry in the line log	Server-to-Communicator routing or wrong communication line	Check output-channel, device, command, and line assignments
Log transmits 0, 1, or 2	Formula bypassed, missing, or bound to the wrong channel	Send from Webstation and inspect the output-channel formula
Log transmits the mapped value but the device does not change	Address, data type, write permission, scaling, or device-side rejection	Check the device register map and read back the destination
Integer writes work but decimal setpoints fail	Destination representation or scaling	Check the OPC item or register data type and any configured scaling

The proof before moving on is a line-log request containing the intended mapped value at the intended destination.

How do you verify the complete setpoint path?

1. Display the current setpoint through the established input channel.
2. From Webstation, select the button labeled 10.
3. Confirm that Server processes command index 0 through Out_real(Cmd).
4. Confirm in the communication-line log that Communicator transmits 10 in the destination's configured representation.
5. Read the setpoint back and confirm that the device reports 10.
6. Repeat the same sequence for label 50.5, command index 1, and mapped value 50.5.
7. Repeat it for label 101.5, command index 2, and mapped value 101.5.

If a value changes only when sent from Communicator, the raw driver path works but the screen-to-output-channel binding needs correction. If it changes only from Webstation, the Server formula is doing required conversion and a raw Communicator test must use the already converted device value. The final acceptance check is agreement among the selected label, the mapped Server value, the transmitted driver value, and the device readback.

FAQ