How do TIA Portal table functions store measurements?

A measurement task needs a PLC-side table, but the table functions under Extended instructions / Table functions do not by themselves define how long the results survive or when a new value is recorded. Treat the function as an operation on an existing collection of values. Define the storage object, write event, capacity, overflow policy, and restart behavior separately.

Storage-class decision

The term table here means a bounded collection of elements with one declared element type. It may hold individual measurements or records containing a value, quality state, sequence number, and time information. A table function reads, searches, copies, or otherwise processes that collection according to its parameter contract; it is not automatically a historical archive.

1. Check 1: classify the required lifetime. Expect one of three requirements: a runtime buffer that may be cleared at restart, retentive PLC data that must survive the configured restart conditions, or durable history intended for long-term reporting.
2. If runtime storage is sufficient, continue with a PLC array or equivalent bounded collection.
3. If values must survive a restart, verify the controller memory and data object are configured for retention; then continue to the table-layout check.
4. If the requirement is long-term history, transfer records to a suitable external logging system. Retentive PLC memory is operating memory, not an unlimited archive.

The project identifies Totally Integrated Automation Portal Version V13 SP1 Update 3. Use the instruction help supplied with that installation to determine the accepted operand type and the exact effect of each listed table function. Do not infer persistence from the function’s location in the instruction library.

Table-operand and layout check

A table operation can only process a compatible memory layout. The element type, bounds, and destination must agree with the selected instruction interface. Mixed measurement types are better represented as records than as unrelated arrays because each result then moves with its associated status and time information.

1. Check 2: inspect the selected function interface. Expect the help page to identify the table operand, any source or destination operand, limits, result output, and status or error indication.
2. Check 3: compare declared element types. Expect the stored measurement type to match the type accepted by the table operation. A conversion performed before insertion must have an explicitly selected range and precision.
3. Check 4: compare collection bounds. Expect every permitted index to fall within the declared table limits. If the instruction accepts a count or length, keep that value no greater than the allocated capacity.
4. If a type or bound differs, correct the declaration before testing execution. If both agree, continue to the write-event check.

Wrong practice is treating adjacent variables as a table without confirming that the instruction accepts that layout. It creates a project that may compile differently after a declaration change and obscures which values belong to one measurement record.

Write-event and index check

A cyclic PLC scan can execute the same write logic repeatedly while a condition remains active. Measurement storage normally needs an event: completion of a conversion, arrival of a new sample, or a deliberate periodic trigger. Without event qualification, one physical measurement may fill several entries.

1. Check 5: observe the write trigger online. Expect one storage action for one new measurement. A continuously active condition must not advance the table on every scan unless scan-rate sampling is the stated requirement.
2. Check 6: observe the current index before and after one event. Expect the write to target the current valid position and the index to advance exactly once.
3. Check 7: force the capacity boundary through controlled testing. Expect a defined result: stop accepting data, report a full condition, or overwrite the oldest entry as a ring buffer.
4. If the trigger repeats, add event detection or a completion handshake. If the index leaves the declared bounds, correct the comparison and update order before using any table function.

For a ring buffer, the write position wraps to the first element after the last valid element. Keep a separate valid-entry count so startup code and consumers can distinguish unused elements from stored values. For a stop-when-full table, inhibit further writes and expose the full state to the consuming logic.

Retention and restart check

Retention describes preservation by configured controller memory across specified restart conditions. It does not mean that every download, initialization, memory reset, hardware replacement, or program change preserves the values. The decisive reading is the data object’s retention configuration together with an observed restart test on the target controller.

1. Check 8: inspect the storage object’s memory configuration. Expect the object to be marked according to the selected runtime or retentive requirement.
2. Check 9: inspect initialization logic. Expect table clearing and index reset only when the operating requirement calls for a new dataset. Unconditional startup initialization defeats retention.
3. Check 10: perform the applicable restart test. Expect runtime-only data to follow its configured initialization behavior and retentive data to preserve both records and table-management state.
4. If records remain but the index resets, treat the table as inconsistent. Retain or reconstruct the index and valid-entry count with the records.

Retaining only the measurement array is insufficient when the write position, entry count, or full state controls interpretation. Store and validate the complete table state as one design unit.

Measurement-table procedure

1. Define the measurement record. Include only fields required by the consumer, such as the measured value and any available validity or sequencing information.
2. Allocate a bounded collection with capacity derived from the required number of records and the controller memory budget.
3. Select runtime-only or retentive storage from the lifetime decision. Use external logging when the capacity or history requirement exceeds appropriate PLC memory use.
4. Create a single-event write path. On each accepted event, place the record at the current valid position.
5. Advance the position once, update the valid-entry count, and apply the chosen full-table policy.
6. Add a status path for invalid input, rejected writes, full-table state, and any status reported by the selected table instruction.
7. Apply a function from Extended instructions / Table functions only after matching its documented operands to the declared collection. Use the function for its documented transformation or lookup, not as a substitute for storage management.

Controlled verification readings

1. Check 11: first insertion. Expect the first accepted result in the first valid position, a valid-entry count of one, and the next write position selected.
2. Check 12: repeated trigger state. Hold the initiating condition active. Expect no additional entry until another measurement event occurs.
3. Check 13: ordered insertions. Submit distinguishable results. Expect each value to appear once and in the intended order.
4. Check 14: capacity behavior. Fill the collection. Expect the configured stop or overwrite policy, with no out-of-range access.
5. Check 15: consumer operation. Run the chosen table function. Expect its result and status to match the known test records and the parameter rules shown in the installed help.

FAQ