The operator sees 87.55 seconds in the report instead of a table covering the recording one second at a time. That value is meaningful: the DAT file begins at 12:01:01 and ends at 12:02:28. The whole-second timestamps describe about 87 seconds, while the displayed duration can include subsecond timestamp precision. The current variable data type is therefore doing its job. The missing rows point to the report’s data context, iteration, or time-grid configuration.
What is the screen actually telling you?
The report is successfully reading data and calculating or displaying a duration. That proves the DAT file is accessible and that the expression can produce a value. It does not prove that the table is iterating through signal samples.
| Screen result | What it confirms | What to inspect next |
|---|---|---|
87.55 seconds appears once |
The file span or duration expression evaluates | Table row source and time iteration |
| Different numeric values appear, but not as continuous rows | The report can resolve at least some data | Whether cells use a scalar, cursor value, or series value |
| The desired table has one row per second | The output needs a regular time grid | Interval, start boundary, end boundary, and value-selection policy |
Changing the variable type because the duration appears as a number attacks the wrong layer. The tag may be valid while the table binding remains scalar. Row creation belongs to the repeating data region, not to the cell’s display format.
Which reporting approach fits the requirement?
Three common report arrangements can display DAT-file information, but only one directly satisfies a continuous one-second table.
| Approach | Row basis | Result | Fit for this job |
|---|---|---|---|
| Scalar summary | One file, calculation, or report context | One duration or aggregate value | No; this resembles the current output |
| Raw-sample table | One row for every recorded sample | Preserves acquisition timestamps but may produce irregular or subsecond rows | Works for raw-data export, not a fixed one-second presentation |
| One-second time grid | One row for each generated timestamp | Regular timestamps with signal values evaluated at each second | Recommended because it matches the requested output |
Raw-sample and time-grid configurations can both produce valid tables. Use the time grid here because the requirement is explicitly one-second spacing across the entire recording, not one row per acquisition sample.
Why does one valid value not create many rows?
A report cell evaluates inside a context. A scalar context represents the file, report, group, or calculation once. A repeating context advances a row cursor through records or generated timestamps. Placing a time expression inside a table cell does not automatically turn a scalar table into a repeating table.
The duration also must not be used as though it were the current row timestamp. It describes the span. The repeating row needs its own time value, while each signal cell must evaluate the selected tag at that row time.
Fixed-interval reporting introduces a value-selection decision when the requested second does not coincide with a stored sample:
| Signal type | Typical selection rule | Pitfall |
|---|---|---|
| Discrete state | Use the last recorded state at or before the row time | Linear interpolation creates states that never existed |
| Continuous analog value | Use an approved interpolation, nearest value, or interval statistic | The rule can conceal peaks between report rows |
| Counter or total | Use the stored cumulative value or calculate an interval difference | Averaging cumulative totals changes their meaning |
Select the rule from the signal’s engineering meaning. The report layout cannot decide this safely by itself.
How do you trace the problem from screen to controller?
-
Confirm the file boundaries. Read the first and last timestamps from the DAT data view. For this file, use
12:01:01and12:02:28as the visible boundary check. - Inspect the required tag as a time series. Confirm that values exist throughout the file, not only at one cursor position. If the series is already correct, leave the acquisition data type unchanged.
- Check the report cell binding. Determine whether it references the signal series at the current row time or a single calculated/current value. A scalar reference can display valid data while producing only one row.
- Check the repeating region. Locate the table’s data source, detail rows, grouping, or iteration controls. The repeating region must be driven by timestamps or records rather than by a single report variable.
- Trace farther back only when the DAT values are wrong. Compare the stored tag with the acquisition driver value, then compare the driver value with the controller variable. A correct DAT trace shifts the fault boundary toward the report; a bad DAT trace shifts it toward tag mapping, communication, or controller logic.
This sequence prevents a report-layout problem from being misdiagnosed as a controller or driver problem.
How do you configure one-second report rows?
- Create or select the report table region that can repeat for a dataset or generated sequence.
- Set its time range to the DAT file’s start and end timestamps rather than binding it to the single duration value.
- Set the row interval to
1 second. - Bind the first column to the current row timestamp.
- Bind each data column to its tag evaluated at that timestamp. Do not bind every row to the report’s fixed cursor or one scalar variable.
- Choose the value-selection rule for each signal class. Use state retention for discrete signals and the approved sampling or aggregation rule for analog signals.
- Define the endpoint convention. For start-inclusive samples separated by interval
Δtand having timestamps no later than the end, the expected count isfloor(duration / Δt) + 1. With a duration of87.55 secondsandΔt = 1 second, this convention produces88timestamps at offsets0through87seconds. - Generate a preview and confirm that the time column advances by exactly one second per row.
If the report instead uses an end-exclusive range, the row count will differ at an exact boundary. Record the chosen convention so later files produce predictable results.
How do you verify the finished report?
| Check | Expected result | Failure meaning |
|---|---|---|
| First timestamp | Matches the selected start boundary | Range or timezone context is wrong |
| Adjacent timestamps | Each advances by 1 second
|
Iteration interval is wrong |
| Last timestamp | Follows the selected endpoint convention | Boundary handling is wrong |
| Row count | Matches the duration-and-interval calculation | Rows are skipped, duplicated, or filtered |
| Signal values | Match DAT values at several beginning, middle, and ending timestamps | Tag binding or value-selection rule is wrong |
Also test a timestamp where a signal changes. A discrete value should switch according to the selected state rule; an analog value should follow the configured interpolation or aggregation rule. Repeated identical values are not automatically a fault because the process value may remain steady across multiple seconds.
Frequently Asked Questions
Can I fix the table by changing the duration variable type?
No. The 87.55-second value already represents the file span correctly. Configure a repeating row context and bind the cells to values at each row timestamp.
Does a valid number prove that the tag binding is correct?
It proves that an expression resolves, but it may resolve only once. Compare the cell binding with the table’s current-row timestamp and confirm that it references a series rather than a scalar value.
Can I use every raw sample instead of one-second rows?
Yes, a raw-sample table preserves acquisition timestamps. Use a one-second time grid for this report because fixed spacing is the stated requirement.
Does one-second reporting preserve every transient?
No. Events between report timestamps can be omitted or transformed by the selected sampling rule. Review the raw trace when transient capture matters.
Can I verify the expected number of rows before export?
Yes. For start-inclusive timestamps at 1-second spacing through a 87.55-second span, calculate floor(87.55 / 1) + 1 = 88, then verify that the preview contains 88 rows and that the final timestamp is the start plus 87 seconds.