The rung fails because the BCD instruction needs a binary integer, so a real from the HMI must pass through LDD and RTOB before BCD, and OUT has to store the result. Keep the scaled value at or below 9,999 for a single word, or up to 99,999,999 with a double word, then cross-reference the destination to catch a second writer that overwrites the result every scan.
A rung that turns a real number from the HMI into BCD for a comparison contact, and a destination that stays empty, is a stacked fault. The conversion needs a different instruction set, and the destination may have a second writer that undoes the result after your rung executes. This article gives the rung that works, the 9,999 and 99,999,999 digit limits that decide the result width, the truncation rule behind a zero result, and the cross-reference check that finds the competing write. Instruction names are the ones this controller family's ladder manual prints, and the worked example carries one HMI entry through both result widths.
Why does a real to BCD rung write nothing to V2030?
The rung writes nothing because the BCD instruction needs a binary integer in the accumulator, and a one-word load of a two-word real leaves it nothing valid to convert, so the working sequence is LDD, RTOB, BCD, then OUT.
LD V2034 moves one word. A real on this family occupies two words, V2034 and V2035 in this layout, and BCD is a binary-to-digit formatting step that needs a whole binary integer in the accumulator. The DL205 user manual lists RTOB as the real-to-binary conversion and BCD as the binary-to-BCD conversion, with the accumulator carrying the value from one to the other.
Correcting the instruction set is only the first layer. A rung fixed that way can still write nothing while a second rung writes V2030 later in the scan, and a data view edit fails the same way, because the writing rung replaces your edit at its next execution. Treat it as two separate checks: does the conversion produce the number you expect, and does the result survive the scan.
What rung converts a real into a BCD value on a 250-1 CPU?
Use the four-instruction sequence this controller family documents for the job: LDD V2034 loads both words of the real, RTOB converts it to a binary integer, BCD formats that integer, and OUT V2030 stores the one-word result.
LDD V2034 ; load both words of the real from V2034 and V2035
RTOB ; real to binary integer
BCD ; binary integer to BCD digits
OUT V2030 ; store the one-word result in V2030
LD is the easy miss: it moves one word, and a real needs the double-word load. The touchscreen HMI writes its entry across both words, so read V2034 and V2035 as one value; the layout is the same one used when displaying a PLC float stored in two word registers on an HMI.
Keep the four instructions on your existing permissive contact, and choose the store width before the first download: OUT for a one-word result, OUTD for a two-word result. The width decision is the next section.
Why does the BCD result come out 0 when the HMI value has decimals?
RTOB truncates: it keeps the integer part and discards everything right of the decimal point, so a positive real below 1.0 becomes 0, and an entry of 12.6 truncates to 12.
Truncation is the documented behavior of this instruction family, and it looks like a dead rung when operators enter small values: an entry of 0.5 produces 0000 in the destination with every instruction working as designed.
Two corrections cover the usual cases.
Nearest-integer rounding for nonnegative values: add 0.5 between the load and the convert.
LDD V2034
ADDR R.5 ; add 0.5 to the real
RTOB ; truncation now lands on the nearest integer
BCD
OUT V2030
An entry of 12.6 becomes 13.1 after ADDR R.5 and stores 0013, where plain truncation stores 0012.
Keep the decimals: multiply the real by 1,000 before RTOB. The comparison contact then works on scaled integers, 12,345 standing for 12.345, and every contact in the chain has to use that same scale.
How large can the value be for single word and double word BCD?
A single-word BCD result holds 0 to 9,999: one 16-bit word carries four BCD digits, so 12,345 does not fit one word and a double-word result holding up to 99,999,999 is the wider choice.
The digit count decides it: one 16-bit word holds four BCD digits, 0 through 9,999, and one 32-bit double word holds eight, 0 through 99,999,999. With the 1,000 scale that keeps three decimals, the single-word ceiling corresponds to an input of 9,999 ÷ 1,000 = 9.999, and the double-word ceiling to 99,999,999 ÷ 1,000 = 99,999.999. Compare your largest entry against the ceiling and store the wide result like this:
LDD V2034
RTOB
BCD
OUTD V2030 ; eight BCD digits into the two-word destination
Two boundary cases need a decision at design time. A value that can pass the ceiling needs a wider result or a coarser scale: 100 in place of 1,000 lifts the single-word input ceiling to 99.99. A value that can go negative needs sign handling, because BCD digits carry no sign: mask the sign bit off the loaded real with ANDD K7FFFFFFF, then read bit B2034.15 as the negative flag while the magnitude converts as a positive number.
BCD arithmetic after the conversion has its own traps; if the chain divides in BCD, check the digit-loss fault where BCD division drops digits before trusting the comparison result.
What do the symptoms point to when V2030 still shows nothing?
Match the symptom to its layer: a zero destination with an entry of 0.5 or less means truncation, digits that appear and then change mean a competing writer, and a data view edit that vanishes means the same writer runs every scan.
- Destination holds 0000 with a positive entry below 1.0: truncation. The conversion works; the entry is below the scale the comparison expects.
- Correct digits appear for one scan, then change: a second rung writes V2030 after your rung in the same scan. Cross-reference the address, then condition or remove the other write.
- A data view edit vanishes by the next poll: the same second writer, executing every scan.
- Digits hold until a large entry, then turn wrong: the single-word ceiling from the width section above. Move the result to a double word with OUTD.
- The rung worked until the operator station changed: the older text station wrote BCD integers the comparison could read directly, and the newer touchscreen HMI writes reals, so the type conversion became mandatory.
Nonsense digits from the first scan point one layer earlier, at the data type the contact is reading; that is the same root as an HMI panel showing nonsense numbers from a PLC BCD analog register.
Worked example: what does a 12.345 HMI entry become in V2030?
With 12.345 in V2034/V2035, plain conversion stores 0012 in V2030 because RTOB truncates to 12; scaling by 1,000 stores 12,345, which passes the 9,999 single-word ceiling and therefore needs the double-word result 00012345.
Three paths cover the design choices.
Path A, integer comparison. LDD V2034 loads 12.345, RTOB truncates it to 12, BCD formats 0012, and OUT V2030 stores 0012. A comparison contact against 12 matches.
Path B, all three decimals kept. Multiply first: 12.345 × 1,000 = 12,345. The single-word ceiling is 9,999, so 12,345 does not fit; the double-word ceiling is 99,999,999, so 12,345 fits with room to spare. BCD produces the digits 00012345 and OUTD stores them into the two-word destination starting at V2030. Every contact downstream now compares scaled integers, 12,345 against a setpoint of 11,000 for 11.000.
Path C, nearest integer. ADDR R.5 turns 12.345 into 12.845, RTOB truncates to 12, and OUT stores 0012. The same rung on an entry of 12.6 stores 0013, since 12.6 + 0.5 = 13.1 truncates to 13.
Recommendation: convert with LDD, RTOB, BCD and OUT for integer comparisons; scale by 1,000 and switch to OUTD only when the comparison needs all three decimals and the scaled value stays at or below 99,999,999; and cross-reference the destination address before you blame the conversion rung.
How do you check the fix on the running program?
Verify in this order: monitor the real in both V2034 and V2035, watch the result after RTOB, confirm the BCD digits after the convert, then cross-reference V2030 and test at 0, a mid-range entry, and the 9,999 or 99,999,999 ceiling.
Put the machine in a safe state and stop it before you download the edited program.
- Enter a known value on the HMI, 12.345 for the worked example, and read the real from both V2034 and V2035 in data view.
- Watch the value immediately after RTOB in ladder monitor mode and compare it with the expected integer: 12 for plain truncation, and the same 12 after ADDR R.5 for this entry, since 12.345 rounds down.
- Confirm the BCD digits at the destination: 0012 in one word, or 00012345 across the pair for the scaled double-word result.
- Cross-reference V2030 and V2031. Remove the second write, or give each writer its own condition so only one executes on any scan.
- Test the boundaries: an entry of 0, a mid-range entry, and one entry just under and one just over the ceiling, 9,999 for OUT and 99,999,999 for OUTD.
Once the comparison holds, the number is ready for the rest of the plant. Where operators need to see it from across the floor, that becomes a display question: the article on displaying a PLC counter value where operators can see it covers sighting and text size, and the shop-floor screens section covers what that category of display is built for.
Questions
Why did the same rung work with an older text operator station?
The older station wrote plain BCD integers into V memory, so the comparison contacts read digits directly and no conversion was needed. A newer touchscreen HMI writes reals across two words with a decimal fraction, so every path from that HMI into a BCD comparison must convert the data type first. A swap of operator stations is the usual moment this fault appears.
When two rungs write the same V address, which value survives?
Ladder logic executes rung by rung, top to bottom, once per scan. When two rungs write the same address, the address ends the scan holding the value from whichever rung executes last, and a manual data view edit lasts only until that rung executes again. A cross-reference of the address lists every writer so you can condition or remove one.
How do you handle a negative real before a BCD comparison?
BCD digits carry no sign. Mask the sign bit off the loaded real with ANDD K7FFFFFFF right after LDD, convert the magnitude, and read bit B2034.15 as the negative flag. Branch the comparison on that flag: the magnitude path compares as a positive number, and the flag path handles entries below zero separately.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.