The recipe link writes a plain decimal number, and the rung's SUB instruction reads the same 16-bit word as BCD digits, so the subtraction fails even though the panel shows the right value. Use SUBB, which reads the word as one binary number, verify one hand-calculated result, then copy the change to the rest.
Your recipe values reach the PLC fine. The panel shows 4000, the link is mapped, and still the rung that should compute a jog target sets nothing, for all six materials. Nothing is wrong with the recipe or the link. The fault is one number-format split at the math instruction: the recipe software writes the value as a plain decimal word, and SUB does its arithmetic on BCD digits. The instruction set gives you a second form, SUBB, which reads the same word as one straight binary number. Swap SUB for SUBB on one rung, check one hand-calculated result, then carry the change to the other five rungs. This page explains what each instruction actually reads, why the display stays correct while the math fails, and the one-rung test that settles it.
One word, two readings
V4000 is a 16-bit word, and the same 16 bits carry two legal readings.
As BCD, each group of 4 bits holds exactly one decimal digit, 0 through 9. Four groups give four digits, so a 16-bit word tops out at 9999.
As binary, the whole word is one number, 0 through 65535.
Take the bit pattern 0x0FA0. Read as binary it is 4000: 15 x 256 + 10 x 16 + 0 = 4000. Read as BCD its four digit groups are 0, F, A, 0, and F and A are not decimal digits, so there is no BCD number in that word at all.
Recipe links write plain decimal by default. The number you type, 4000, goes into the word in straight binary, and a reader that expects a plain number shows 4000 back. BCD in a PLC usually comes from thumbwheel switches and BCD input cards.
Why the panel shows the right number while the rung sets nothing
The panel and the math instruction are two separate readers of the same word.
The recipe link does its job. It places the value in V4000, the panel reads that word as a decimal number, and the display looks right. Everything up to the rung is healthy.
The rung is the second reader. SUB picks up the word and applies BCD digit math to it. The word holds digit groups a BCD reading cannot use, so the rung has no operand to subtract, and the destination word is never written. One healthy reader and one blocked reader, on the same bits, is exactly what produces a display that works and a rung that does nothing.
So keep the two checks apart: a correct display tells you the link works, and the math instruction still needs its own hand-checked test.
What SUB and SUBB each read
SUB and SUBB both subtract one 16-bit word from another and write the difference to a destination word. They differ in how they read the bits: SUB works on BCD digits, SUBB works on binary words. The Standard RLL Instructions chapter of the DL06 user manual documents the pair this way, and the same plain-versus-B split repeats across the math instructions. On a DL260, a rung that loads a recipe word and subtracts with SUB is doing BCD math on binary data.
| Instruction | Reads each operand as | Matches a recipe write of plain decimal | 4000 minus 100 |
|---|---|---|---|
| SUB | Four BCD digits, one per 4-bit group | No, the digit groups carry A through F | No valid operand, destination left unset |
| SUBB | One binary number, 0 to 65535 | Yes | 3900 |
Keeping the link, the math and every downstream reader in one format is what the swap buys you.
Worked example: 4000 lb mix target minus a 100 lb jog
Inputs, from the batching job itself:
- Recipe target, material 1: 4000 lb, typed into the mix design, and the recipe link places it into V4000 as a plain decimal word.
- Jog amount: 100 lb, the amount to fetch before final setpoint, held in V4010.
- Destination: V4167, the jog target word.
- Hand-calculated answer to check against: 4000 - 100 = 3900 lb.
Rule in words: SUBB reads each 16-bit operand as one binary number, subtracts the second from the first, and writes the binary difference to the destination.
Arithmetic:
- V4000 holds 4000 decimal, which in a 16-bit word is 0x0FA0: 15 x 256 + 10 x 16 + 0 = 4000.
- V4010 holds 100 decimal, which is 0x0064: 6 x 16 + 4 = 100.
- SUBB computes 4000 - 100 = 3900 and writes 3900, which is 0x0F3C: 15 x 256 + 3 x 16 + 12 = 3900.
Result: V4167 reads 3900 in the programming software, matching the hand calculation exactly.
The old rung explains the silence: with 0x0FA0 in the word, SUB's digit groups read 0, F, A, 0, F and A are not decimal digits, so the rung never had a valid operand and never wrote the destination.
Run the test with the batch sequence blocked from acting, because a jog target that suddenly becomes a valid number can drive a real output.
Decision and threshold: change this one rung from SUB to SUBB, enter the 4000 and 100 values, and require V4167 to read exactly 3900. At 3900, the format question is settled for recipe data on this CPU. On a math fault or any other value, stop and read the actual instruction and operand formats in your programming software before editing anything else.
Copy the fix to the remaining five rungs
With the test rung verified, repeat the change per material and check each rung on its own numbers:
- Read the three addresses on each rung first: recipe word, jog word, target word. Materials rarely share one address layout, so confirm each address on screen before you edit.
- Hand-calculate each material's target from its own recipe and jog values, then require the destination word to match it.
- Keep the original SUB version of each rung in the project as a comment or a disabled rung so the change can be reversed.
Then follow the target word downstream. The compare that ends a batch, and any operator display of the jog target, now receive binary words, and they must read binary too. A downstream element still set for BCD misreads 0x0F3C the same way SUB did, since its digit groups carry F and C. Fix those readers in the same pass, one known value at a time.
Recommendation: when recipe values display correctly but a subtraction rung writes nothing, change that rung from SUB to SUBB, run one hand-checked value through it, and require the destination to read your own arithmetic, 3900 for a 4000 lb target with a 100 lb jog, before copying the change to the other five material rungs. Keep every reader of those target words on binary as well.
Where else the same split shows up
The binary-versus-BCD question reaches past subtraction:
- Timer and counter presets break the same way: a preset that behaves up to 9 and misbehaves from 10 up is the same two readings of one word.
- When the data genuinely is BCD, from thumbwheels or BCD cards, keep the BCD instructions. The article multiply a BCD register by a ratio in PLC ladder logic shows a BCD rung done properly.
- A recipe value that arrives as ASCII text is a different encoding problem, covered in ASCII recipe values and how a PLC sees an integer.
- Floating-point values are a third format, and converting them into BCD words has its own traps, covered in fix a PLC real to BCD conversion that writes nothing.
One rule covers all of them: settle the format of the data first, then pick the instruction that reads that format.
Questions
How do I tell whether an existing V-memory word holds BCD or binary?
Split the 16-bit word into four 4-bit groups and read each group as one hex digit. If every group is 0 through 9, the word is a valid BCD number; 0x1234 read as BCD is 1234. Any group from A to F, like the F and A inside 0x0FA0, means the word holds no BCD number, so a BCD instruction has nothing valid to read. Some words are valid in both readings, so the source that wrote the word decides which meaning applies.
Does swapping SUB for SUBB change anything the operator sees?
The recipe link and the panel keep working as before, so the mix design values look unchanged. What changes is the rung's own reading and the words it writes out. Any screen or report that shows a jog target now receives a binary word, so check one display against a hand calculation: enter a known recipe and confirm the shown number matches your own subtraction for that mix.
What if one operand comes from a BCD source and the other from the recipe?
Then the rung mixes formats: a plain decimal recipe word in one operand and a BCD value, for example from a thumbwheel input, in the other. No single instruction reads two formats at once. Convert one operand into the other's format before the math, then keep that converted word consistent for every instruction that follows it. Check each operand's source separately, because a six-material pattern can mix sources.
Why did the rung fail outright instead of computing a wrong number?
A BCD instruction needs decimal digits in every 4-bit group. The word 0x0FA0 carries F and A, which no decimal digit group can hold, so there was nothing valid to subtract and the destination stayed unset. A wrong-but-plausible result points the other way: binary data that happens to use only the digit patterns 0 through 9. The word 0x0123 is 291 in binary but reads as 123 in BCD.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.