Read a DS18B20 temperature in CODESYS ladder

What the sensor gives you

The DS18B20 speaks 1-Wire: commands and data share one data line, with supply and ground on the other two pins. It is a digital sensor, so a ladder contact, an analog-input channel mapping or a scaling block cannot reach it. The 1-Wire device support in the runtime performs the bus transactions, and your ladder reads the result.

Resolution is programmable from 9 to 12 bits. At 12 bits the sensor needs up to 750 ms for one conversion, the datasheet maximum. That number sets your fastest honest update rate, whatever the task interval says. If your temperature sensor speaks I2C instead of 1-Wire, the work is register-level and follows a different path: reading an I2C register from a CODESYS function block.

What you need before the ladder

• The runtime on your single-board controller with 1-Wire device support installed, so adding the sensor raises no unresolved device description.
• The sensor wired with power off: supply, ground and data, with the pull-up resistor on the data line at the value the sensor datasheet specifies. Decide between external supply and parasite power before wiring; the datasheet prints both hookups.
• The sensor added in the device tree under the controller's 1-Wire master, with a name you will recognize, such as DS18B20.
• A task for sensor acquisition, separate from your machine-control task.

The instance the runtime generates

The instance is implicit. The device tree name is the instance name, and the sensor's outputs are members of it. An entry named DS18B20 gives you DS18B20.rTemp.

Rename the entry and the expression changes with it. A project copied from another machine fails to compile until the names match. A sensor function block you declare yourself in ladder is a separate object with no connection to the configured device, and it can conflict with the generated name. Use the generated instance.

Reading the value in ladder

1. Write down the exact device tree name of the sensor entry. Everything downstream spells it character for character.
2. Declare an application variable for the temperature, for example rCabinetTemp, with the same data type as the generated member. Open the member's declaration in the editor and read the type and unit there before applying any threshold.
3. Create a program for sensor acquisition and open it in the ladder editor.
4. Insert a MOVE instruction. Wire DS18B20.rTemp to its input and rCabinetTemp to its output. rTemp is a numeric value, so a contact is not its destination. MOVE is the IEC 61131-3 transfer operator, and it exists in every ladder editor in this environment.
5. Assign that program to its own task. Set the task type to interval, the interval to 1000 ms, and the priority number to lower urgency than your machine-control task. In the CODESYS task configuration, 0 is the highest priority and larger numbers are lower.
6. Download the application, log in, and watch the MOVE rung in online mode.

Worked example: one 12-bit sensor, a 1000 ms task and a 30 ft reading position

Inputs:

• Conversion time: up to 750 ms at 12-bit resolution, the sensor datasheet figure.
• Device tree entry named DS18B20, so the output is DS18B20.rTemp.
• The reading also goes to a floor display that operators read from 30 ft. The legibility planning figure is 30 ft of viewing distance per inch of capital height (FHWA).

Rule in words: set the task interval above the conversion time so every scan transfers a completed conversion, and set the displayed capitals to at least the viewing distance divided by 30.

Arithmetic:

• Interval: a 1000 ms task interval leaves 1000 − 750 = 250 ms of margin over the conversion, so each cycle transfers a finished value.
• Text size: 30 ft ÷ 30 ft per inch = 1.0 in of capital height minimum for the displayed number.

Decision: configure the acquisition task at 1000 ms with priority below the control task, and render the temperature in capitals 1.0 in tall or larger. Any interval shorter than 750 ms re-reads the previous conversion, so a 100 ms task delivers no fresher data than the 1000 ms task while waking the bus ten times as often.

How to check it worked

1. Compile. The expression DS18B20.rTemp resolves with no unresolved-reference error. If it fails, the device tree name and the expression differ.
2. Log in and monitor the rung. The MOVE executes on every acquisition-task cycle and rCabinetTemp follows DS18B20.rTemp.
3. Warm the sensor with a finger. At 12 bits expect movement within two or three conversions, so within about 1.5 to 2.3 s.
4. Open the task monitor while the acquisition task runs and confirm the machine-control task's cycle time holds its value.

When the number stops moving

A number sitting in your variable can be a stale one. If the MOVE's enable condition goes false, the destination keeps its previous value; if the bus stops responding, the member can hold its last conversion. Before the temperature trips a machine action, define what the logic does on loss of communication: use the status and diagnostic facilities of the 1-Wire device support where the runtime provides them, and where none is exposed, add a heartbeat that a watchdog resets on every successful transfer. A steady reading is not, by itself, evidence of a healthy sensor; the finger test above is.

Recommendation: read the generated instance, not a declared copy. Copy DS18B20.rTemp into your own variable with a MOVE, in a program on its own task at a 1000 ms interval with priority below machine control, and define the loss-of-communication behavior before any threshold acts on the value. Set this up while the sensor entry is fresh in the device tree so the name in the ladder matches the name in the tree from the first download.

From the sensor to a floor display

If this temperature belongs on a screen the crew watches, the sensor read is half the job. Sizing the letters is its own calculation, covered in small screen text readability for a signage display. For the board itself, planning an offline sensor status display for a shop floor covers what to show and how to keep it running without a network, and displaying a live dashboard on a signage screen covers the live-value path. Where the screen shows process values with no operator input, specifying a read-only process display for a plant is the checklist to follow.

Questions