Log two-decimal values from a trend graph to USB

Why does the USB file ignore the two decimals on the screen?

The screen and the file answer different questions. The display object formats the value it is handed, while the trend control is fed from a tag or a data log and records that value as it receives it, decimals and all.

Panel documentation reads the same way: a trend control takes its values from a tag or from a data log and plots what arrives. Formatting lives on the display side. A numeric display object places the decimal point wherever you ask and shows 8.42, because it formats on the way out of the screen. The trend object works on the way in, taking the tag's value and writing it to the log. The two numbers drift apart, and the fix belongs upstream of both objects, in the PLC. Showing a decimal value on an HMI numeric display is its own topic with its own settings, and no display setting reaches the log file.

What do the symptoms in the USB file point to?

Each symptom names its own cause. A value of 8.416666 in the file beside 8.42 on the screen means an unscaled float pen, a column of bare counts under a times-100 legend means the pen is already scaled, and a line pinned at 327.67 means a 16-bit integer overflowed.

• 8.416666 in the file beside 8.42 on the screen: the pen carries the raw float, and the screen formatting never touched the log.
• A column of 841s under a legend that says times 100: the pen is already on a hundredths tag, the file is right, and every reader divides by 100.
• Values like 7.1999999 or 0.3000001: binary float storage; the probe and the wiring are fine.
• 8.41 where the work needs 8.42: the conversion truncates, so replace it with a rounding one.
• A pen pinned at 327.67: the scaled value overflowed a 16-bit integer, so move the tag to 32 bits.

Why can't the panel round a stored float to two decimals?

A 32-bit float keeps its digits in binary, and most two-decimal numbers have no exact binary form. Store 0.33 and the format holds 0.3300000131, the nearest value it can represent, so no amount of rounding makes the stored number exactly 0.33.

One third has no finite decimal form, and 0.333333 is the approximation you accept at whatever length the page allows. Binary hits the same wall one step earlier: tenths and hundredths fall between two representable values. The error of 13 billionths never shows on a graph, and it is why the request has no setting to find: the format carries a fixed number of bits, so the value reaching the pen has to change instead.

Counts dodge the whole question, because 33 is exact in binary and the decimal point becomes an agreement between writer and reader. Scaled integers are the established tool for this, and the same arithmetic runs scaled integer math on panels with no floating point at all.

How do you log hundredths when the trend cannot format them?

Do the conversion in the PLC: multiply the float by 100, round the product to a whole number with the PLC's rounding conversion, and point the trend pen at the new integer tag. The log carries hundredths as plain counts and 333 reads back as 3.33.

1. Keep the source float tag where it is: displays, alarms and other math keep reading full precision from it.
2. Create one integer tag per pen, eight in the case above, and name each one so the scale is obvious, for example with a suffix that says times 100.
3. Add the conversion per pen: multiply the source by 100 and pass the product through the rounding conversion the PLC manual lists for this, never the plain move, which chops the fraction off.
4. Point each trend pen at its scaled tag and set that pen's data type to match the tag.
5. Move the pen's graph limits into counts: a 0 to 85 °C zone plots 0 to 8500.
6. Write the scale where the operator looks: the pen name, the legend and the axis note all say hundredths.
7. Convert every pen that writes to the same file in the same session, so every column follows one contract.

The pattern is the same one used when trending a calculated value by doing the PLC math first: the PLC does the arithmetic and the panel plots the result. The pen's sampling interval, limits and appearance stay where they were; the source tag and the units of the stored number change.

Which rounding rule turns the scaled value into an integer?

Round to nearest, with the tie case settled by one written rule. The value 8.415 printed on a screen looks like an exact halfway value, but stored as a 32-bit float it becomes 8.41499996, so times 100 and rounded gives 841 counts, 8.41 in the file.

Truncation biases the file low. A move that chops the fraction turns 8.419 into 841 counts, and the lost part is always positive for positive values, so means computed from the file sit up to 0.005 units low per sample. Round-to-nearest spreads the error evenly in both directions, which is what a log that feeds averages wants.

Negatives need the tie rule named: half away from zero sends -333.5 to -334, half toward zero sends it to -333. Pick one, write it in the log book, and push -3.335 through the real instruction before the changeover. The stored float of 3.335 sits at 3.3350001, a hair past halfway, and that hair decides the count.

Check the tag's range against the engineering span. A 16-bit signed integer stops at 32767 counts, which is 327.67 units, and a 32-bit signed integer stops at 2147483647 counts, or 21474836.47 units. A zone temperature sits far below either ceiling. A totalizer running at one unit a minute crosses the 16-bit one in under six hours, so totals belong in 32 bits.

If the source value itself comes from a raw converter count, run that scaling with the multiply first and the divide last, so the hundredths survive the intermediate: scaling works best with the multiply before the divide.

What changes on the panel after the PLC does the rounding?

The pen source, the pen data type and the label change; the display objects stay as they are. A numeric display can keep showing the decimal point in place while the log file holds counts.

Give the numeric display the scaled tag and set its decimal-point position for two places, and the operator keeps reading 8.42 from a tag that holds 842. Write hundredths, or times 100, into the pen name, the legend and the axis note, because an axis printed in bare counts reads like engineering units to whoever opens the file cold.

A pen that still writes the old magnitude after the changeover is still pointed at the old tag; the general case, a trend graph plotting raw integer tag values, has its own walk-through. Note the changeover date and time and keep the last pre-change file, so readers treat rows before that moment as floats.

How do you check the USB file before you trust it?

Push known values through the chain and read the file on the stick, because the display proves the tag and the file proves the log. A source value of 8.416666 must come out as 842 in the file, and 842 divided by 100 is 8.42.

The 1.005 row is the boundary case: a 32-bit float stores 1.005 as 1.0049999, the product is 100.4999, and nearest-rounding keeps it at 100 counts. The binary value decides, and the printout follows it.

• Push a known value into one source tag and follow it through all four stops: float tag, scaled tag, screen, file.
• Read the file on the stick, in the program that will live with it: the spreadsheet, the reporting script, the historian import.
• Count the pens. One pen left on its float shows a long decimal in a column of counts; one pen left unscaled shows a column 100 times off.
• Run the negative row and the boundary row before calling the changeover done.
• Mark the first scaled row in the file or in the log book, so readers know where hundredths begin.

What does a worked example look like from source tag to file?

A filling line logs eight pens to USB at a 1-second sample interval: six product temperatures and two holding times in seconds, all 32-bit floats with three or four decimals in the raw value. The QA sheet needs two decimals.

The raw fill-temperature float reads 8.416666 °C after the analog scaling. In the PLC, 8.416666 x 100 = 841.6666, the rounding conversion makes it 842, and the 32-bit integer tag holds 842. The pen samples the tag once a second, and the USB line reads 842. The QA sheet computes 842 / 100 = 8.42 °C, and the gap to the raw value is 8.42 - 8.416666 = 0.003334 °C, inside the half-hundredth bound of 0.005.

The holding-time pen runs the same chain in seconds: 12.3456 x 100 = 1234.56, rounds to 1235, and the sheet reads 12.35 s, a gap of 0.0044 s.

The range check closes the example: the hottest zone on the line is 85 °C, so the largest count is 8500, inside a 16-bit integer's 32767 with room to spare. The line still uses 32-bit tags, because a totalizer pen in hundredths passes 327.67 units inside one shift.

Recommendation: when the reader of the USB file needs two decimals, scale in the PLC and log integers: multiply by 100, round to nearest with the tie rule written down, keep the raw float tag for displays and any math that wants full precision, and convert every pen on a file in the same session.

Questions