A controller accepts a 60.0 °C setpoint as scaled integer 600 at holding-register protocol address 20. The linked sandbox opens the exact unit, function, address, quantity and value so the reader can verify the PDU rather than copy an unexplained hex string.
Follow the workflow
This Temperature controller example uses Modbus function 06. Select the function from the documented object type and whether the operation is a read or write—not because two register names look similar.
Do this in the product
Open the preconfigured request and confirm the function-code label before running it.
Open the exerciseThe request transmits protocol address 20. Human-facing 0xxxx, 1xxxx, 3xxxx and 4xxxx references are notation, not values to paste blindly into the 16-bit address field.
Do this in the product
Compare the address field with the expected PDU 06 00 14 02 58.
Open the exerciseThe request quantity is 1 and the training value is 600. Multiword data, signed values, enums and decimal scales remain application-map concerns beyond the core Modbus frame.
Do this in the product
Run the server grader and read each function-specific limit check before copying the request.
Open the exerciseA normal Modbus response proves that a server accepted the request format. It does not by itself prove that a motor moved, a valve reached position or a process value is correctly scaled.
Do this in the product
Save the known-good request, then use a paid project to retain later fault and commissioning evidence.
Open the exerciseCore concepts
The simulator creates a repeatable result; these concepts make that result transferable to real vendor software and supervised practical work.
The transmitted address is a zero-based 16-bit field unless the specific device manual states a different table convention.
The expected request begins 06 00 14 02 58; TCP adds MBAP framing while RTU adds unit address, timing and CRC.
Function, address and response can be valid while units, signedness, scale or machine permissions remain wrong.
Continue in the workspace
Run the foundation exercise publicly, then use a subscription for advanced challenges, saved configurations, full attempt history, sharing, assigned paths and team reporting.
Related learning surfaces
Competency and practice field guide
Direct answer
The learner can encode the intended value, enforce engineering limits, confirm the controller accepted it and verify the permitted control response without confusing setpoint with process value.
Written for pLC and instrumentation learners writing a bounded setpoint to a separate temperature controller over a documented interface.
Authorized actor, controller identity, setpoint register, write function, data type, decimal place, unit, lower and upper limits, operating mode, response, read-back and change record.
Approved engineering setpoint through validation and encoding to write request, controller acceptance, read-back, internal control action, output and independently observed process value.
One bounded setpoint change is accepted, read back correctly and produces the permitted direction of response.
Below minimum, at minimum, at maximum, above maximum, negative value, decimal mismatch, wrong mode, timeout, duplicate request and restart.
An authority, identity, register, encoding, limit, unit, mode, response, read-back or process mismatch.
The change governed by approved limits, target documentation, safe testing and rollback procedures.
Use the documented write function and register, validate engineering limits, encode the type and decimal place, then read it back and observe the permitted response.
The setpoint is a request and the process value is measured feedback; combining them hides whether the controlled process actually responded.