Gallons to pounds conversion in a PLC with no floating point

Why won't the MUL instruction accept 8.18?

On this instruction set MUL works in BCD only: the instruction and its K constants carry no decimal point, so K8.18 is not a value the CPU can accept; you multiply by the integer 818 and let the screen's two-place decimal setting show hundredths.

Each BCD register holds plain decimal digits and nothing in the format stores a point. The point is an agreement between you and the display: store the factor with its digits shifted two places left, so 8.18 becomes 818, and tell the numeric display to show two decimal places. The stored product is hundredths of a pound and the screen shows pounds and hundredths. The general method is scaled integer math when your PLC has no floating point; this gallons-to-pounds job is one case of it, with a fixed factor and an overflow check at full scale.

That agreement is also the whole test. Any reading that looks wrong is a misplaced point or a wrong factor, and the 10-gallon check below separates the two.

What do you need before you write the rung?

You need four things: a whole-gallon value in one register, two adjacent registers for the product, a decimal-position setting on the operator interface, and the factor for your liquid, which is 8.18 lb per gallon here.

• A gallon count, not a raw count. The level sensor is taught to the tank and transmits 4-20 mA; the analog input reads that span as 0 to 4,095 counts. Scaling turns counts into gallons: 0 counts = 0 gallons and 4,095 counts = 30,000 gallons. The multiply must receive gallons, and feeding it the raw count produces a plausible-looking weight that is wrong by the whole scale. The scaling step is the same work as scaling a 4-20 mA transducer for an HMI display.
• Two register blocks. V2012 holds gallons in this example, and V2014 with V2015 holds the 8-digit product. Use your own addresses and write the unit on each one.
• A numeric display object with a decimal-position setting. The point belongs to the screen object, not to the register; the register only ever holds digits.
• The factor for the liquid. 8.18 lb per gallon here. A different liquid changes the constant and the overflow check; water, at about 8.34 lb per gallon, is covered in the FAQ below.

How does the gallons-to-pounds rung look?

The rung is three lines: load the gallon count as a double, multiply by the constant 818, and store the product as a double, which on the example's V registers reads as follows.

LDD V2012     ; 8 BCD digits in: the whole-gallon count
MUL K818      ; times 818, so the product is hundredths of a pound
OUTD V2014    ; 8 BCD digits out, across V2014 and V2015

1. Scale 0 to 4,095 counts to 0 to 30,000 gallons and land the whole-gallon value in V2012, in the operator interface scaling table or in an earlier rung, never both.
2. LDD V2012 loads the count as one 8-digit value.
3. MUL K818 multiplies by the integer factor; no decimal point enters the math.
4. OUTD V2014 writes the product to V2014 and V2015 on every scan, so keep the gallon count out of those two registers.
5. Point the numeric display at V2014 and set decimal places to 2, which turns a stored 8,180 into a shown 81.80.

How do you prove the decimal point landed in the right place?

Ten gallons must store 8,180 in the product registers and read 81.80 lb on the screen; a screen that shows 8,180 has its decimal position set to zero places, and one that shows 818.0 has it set to one.

With the process quiet, write 10 into the gallon register from the programmer and watch the product registers. The stored value must read 8,180, which you can check by hand as 10 × 818 = 8,180 and 10 gal × 8.18 lb/gal = 81.8 lb. Two decimal places on the display object turns that into 81.80; setting places on a numeric object is the same operation described in show decimal flow values on an HMI numeric display.

Digits that match neither form point to a data-format mismatch in the register, the condition behind an HMI panel showing nonsense numbers from a PLC BCD analog register. Fix the format first: a wrong point position and a wrong factor produce different numbers, and this check tells you which one you have.

Does the full tank overflow the double register?

A full tank at 30,000 gallons stores 24,540,000, which fits the eight BCD digits a double register holds, a maximum of 99,999,999; the same tank multiplied by 8,180 stores 245,400,000 and overflows, so 818 is the factor to keep.

The arithmetic: 30,000 × 818 = 24,540,000, eight digits, inside the range. Interpreted at two decimal places that displays 245,400.00 lb, and the hand check agrees: 30,000 gal × 8.18 lb/gal = 245,400 lb.

The tempting upgrade is a factor of 8,180, four implied decimal places, finer bookkeeping. At this tank size it fails: 30,000 × 8,180 = 245,400,000, nine digits, past 99,999,999, so the product rolls over and a full tank shows a small nonsense number. Two implied decimals is the finest form ×818 supports here, and at 30,000 gallons that is exactly what the factor 8.18 needs. Put the width arithmetic where the next person reads it, for example in the rung comment: MUL K818 (8.18 x 100; full scale 30,000 gal = 24,540,000, fits 8 digits).

Worked example: what does the screen show at 10,000 gallons?

At 10,000 gallons the sensor sits at 1,365 counts, the scaled register holds 10,000, the product register holds 8,180,000, and the screen shows 81,800.00 lb, which you can verify by hand as 10,000 × 8.18.

Three checks close the example. The hand check matches: 10,000 gal × 8.18 lb/gal = 81,800 lb. The width check passes: 8,180,000 is eight digits, inside 99,999,999. The display check discriminates: on the same stored value, one decimal place would show 818,000.0 and zero places would show 8,180,000.

How much of the displayed number is real?

One analog count is worth about 7.3 gallons here, 30,000 ÷ 4,095, and 7.3 gallons of this liquid converts to about 60 lb, so the two decimal places on the screen are fixed-point bookkeeping and the sensor resolves tens of pounds.

The hundredths exist so the integer math has somewhere to put the factor, and showing them reports the arithmetic honestly. The full statement is: the display resolves 0.01 lb, the measurement moves in steps of about 60 lb.

For this tank, publish whole pounds. A screen reading of 245,400.00 lb carries six digits of arithmetic behind a number that steps in 60 lb jumps; 245,400 lb says the same thing with less ceremony.

Resolution moves with the span-to-tank ratio. The same 4,095-count electronics on a 3,000-gallon tank resolves 0.73 gal per count, about 6 lb, and then two decimal places on the screen become worth showing. Tightening the sensor's teaching span to the working level range has the same effect with no hardware change.

Where should the multiplication live, in the PLC or in the display scaling?

Both places work and you pick one: a multiply in the PLC keeps pounds available to the ladder logic and to any screen that reads the register, while folding 8.18 into the operator interface scaling leaves the registers in gallons.

• In the PLC. Pounds reach comparisons, totals, and every screen that reads V2014. The cost is two registers of width and the overflow check above.
• In the scaling table. Map counts straight to pounds: 0 counts = 0 lb, 4,095 counts = 245,400 lb, because 30,000 gal × 8.18 lb/gal = 245,400 lb. Whole pounds, no implied decimal anywhere, no PLC multiply at all. A scaling table that accepts decimal factors can apply 8.18 per gallon directly; the counts-to-pounds mapping works on any table.
• Never both. Run the factor twice and 10 gallons reads about 66,912 lb, because 81.80 × 818 = 66,912.4. A doubled conversion is the failure this setup cannot survive quietly, so pick the path and then run the 10-gallon check.
• Label everything. V2012 gallons, V2014/V2015 hundredths of a pound, or V2014/V2015 unused. The next shift reads the program cold.

Recommendation: keep the multiply in the PLC when any logic or a second screen needs pounds, and put it in the operator interface scaling when one display is the only consumer of the number; on either path, write 10 into the gallon register and expect 8,180 stored and 81.80 lb shown, and confirm 30,000 × 818 = 24,540,000 stays inside the double register before the screen goes live.

What changes on a CPU that has floating point?

A CPU with floating-point support takes 8.18 as a real constant, so the decimal point lives in the stored value and no implied-decimal display setting is needed; 30,000 × 8.18 = 245,400 stores with no width gymnastics.

The overflow discipline stays: know the widest value your program produces and check the display scaling against the stored format. When the operator interface expects integer registers, send the real across as a register pair; the method is written out in display a PLC float stored in two word registers on an HMI.

If the plant holds this CPU family for spare-parts commonality, the ×818 integer path above runs unchanged, and both paths land on 245,400 lb at the full tank. The choice comes down to the spare on the shelf, and the integer path needs no hardware purchase.

Questions