Log pass/fail bits with analog data on an HMI trend

What a pen accepts and what it refuses

A pen is one chart line bound to one tag. The Pen tab of a Line Trend Graph is where you enter and edit the pens and the tag names they chart. Those tags have to resolve to variable values. On a PLC family that addresses its registers as %r, %AI and %AQ, those are the families a pen takes. A discrete address, the kind a pass or fail bit lives on, is not a variable value. The pen setup rejects it. The PID trend graph logs loop values the same way, so the register pen is the route there too.

Three more behaviours matter for the file itself. The legend name you give a pen is the name that lands in the log file as the column heading. The logging feature tied to the graph saves rows to a CF card or a USB memory stick. And the start and stop tags arm and disarm the logging window; they have no power to turn a bit into a pen value.

What you need

• Access to the PLC program, to reserve one spare %R register and add the conversion rungs.
• The address usage or cross-reference list, so the register you pick is genuinely spare.
• The HMI project with the Line Trend Graph and its data logging enabled, plus a CF card or USB stick for the files.
• The part cycle time measured at the station, for example 45 s per part, because the log interval has to beat it.
• Legend names decided before you open the Pen tab: PASS, or PASS and FAIL for the two-register layout.

Convert the result bit into a spare register

1. Pick the register. Open the cross-reference in the PLC software. Choose a %r word that no rung reads or writes, and search the project for the address to confirm. Comment it in the program as the result register.
2. Write the conversion as level logic. When the pass bit is on, move the pass value into the register. When the pass bit is off, or the fail bit is on, move the fail value in. Level logic, not a pulse: the register holds each result until the next part replaces it. That holding is what lets a slow log interval still catch every result.
3. Decide what the register shows between parts. With the held result, every row carries the outcome of the most recent part. Clearing the register between parts would log an idle station as a streak of fails, so hold the last result. If the line truly needs a visible no-part-tested state, give it a third unmistakable code and print that mapping beside the file.
4. Carrying several results per part? Pack the bits into one status word and log the word as a single pen, then decode the bits in the spreadsheet. Packing discrete I/O states into one status word for a trend shows the packing step by step.

Before you test any of this, confirm the register is unused and force states only on a machine that is safe to exercise. When it is not, simulate the pass and fail bits in the logic instead.

Add the register as a pen and name the legend

1. Open the Line Trend Graph in the HMI project, go to its Pen tab, and add a pen whose tag points at the chosen %R register.
2. Type the legend. PASS is enough for a single register. The legend becomes the column heading in the file, so name it for whoever reads the file. Adding column headers to a trend log file on USB covers the naming in detail.
3. Keep the analog pens in the same graph. The whole point of the register trick is correlation: the result lands in the same row as the values sampled around it.
4. Choose the layout from this table and wire the logic to match.

Set the log interval below the part cycle

The logger writes one row per interval, and only the rows reach the card. The pen on screen redraws on its own refresh schedule. The file is the deliverable, so judge the setup by the file.

The rule: keep the interval shorter than the part cycle time. With the register holding each result for a full cycle, an interval strictly shorter than the cycle ensures every part spans at least one row write. At exactly the cycle time a part can straddle two writes and vanish from the record, so leave margin. A 20 s interval against a 45 s cycle has plenty. The example below uses a 30 s interval, which fits stations that take longer than that per part; a faster station needs a shorter interval, and the conversion logic stays untouched.

Give each run its own file as well, so a new shift writes a fresh file instead of overwriting the last one. Giving each data log a unique CSV file name has the setup.

Worked example: one pass and fail register logged at a fixed interval

Inputs:

• Log interval: 30 s, typed into the logging file setup.
• Encoding: 1 for pass, 0 for fail, chosen so the result reads at a glance beside analog numbers.
• Analog neighbours: raw counts in the hundreds to a few thousand, the range of the 12-bit analog inputs common on this class of PLC, where a full-scale input reads 4095. The example columns carry 510 and 2235.
• Day length: 86,400 s.

Rule in words: rows per day equals seconds per day divided by the interval. A part survives into the file when the interval is shorter than the time its result is held, which with level logic is one full cycle.

Arithmetic:

• 86,400 s ÷ 30 s = 2,880 rows per day, about 20,160 rows in a week (2,880 × 7).
• A station slower than the interval per part: every part's held result spans at least one row write, so every part appears at least once in the file.
• A station that turns parts around faster than one per interval: two results inside one interval collapse into a single row that shows only the later part, so parts go missing even though the conversion logic is correct.

Result: at that interval the file grows by 2,880 rows a day, with a Result column decoded as 1 = pass and 0 = fail sitting beside counts like 510 and 2235.

Decision: keep this interval for any station slower than one part per interval. For a faster station, set the interval below the measured cycle time before trusting the log as a per-part record.

Recommendation: Convert the result bit with level logic into one spare %R register, log that register as a pen whose legend names the file column, and set the log interval below the measured part cycle time. Code pass as 1 and fail as 0 when the analog columns carry counts of similar size. Switch to two registers with PASS and FAIL legends when the file must read plainly without a printed code. Move to a string logging route only when the column itself must spell the words.

Check the file, not just the graph

1. Produce a known pass at the station and watch the register online: it must show the pass value and hold it until the next part.
2. Produce a known fail and watch it take the fail value. If the pass and fail bits ever sit on together, correct the logic before trusting the log.
3. Let the logger write a few intervals, for example 10 minutes at 30 s, then read the file from the card or stick on a PC.
4. Read the header: the result column carries the legend name, the rows carry date and time fields, and the analog values sit beside the result as sampled.
5. Cycle a dozen parts and count the rows against the interval rule: at least one row per part.
6. Print the decoding beside the log procedure, so whoever reads the file next month reads it right.

When the column must say PASS, not 1

The pen route is numeric, full stop. A spreadsheet decodes 1 and 0 with one filter, and that is usually enough. When quality wants a column that spells the words, that is a string logging job. Logging ASCII text on an HMI panel covers it. Keep the trend log for the analog correlation and let the string route carry the words.

If the crew also needs the count on the wall

A trend file answers for the quality office; operators rarely open one mid-shift. If the line lives by its pass count, a shop-floor display driven by your own app can carry the running result where the crew sees it. Our shop-floor signage category is the place to start, and the logging setup above stays exactly as it is.

Questions