A run that never left tolerance could be reported as a failure
Reported outcome may be wrong
- What was wrong
- Where a profile's End step followed a soak step with tolerance monitoring configured, the End step's drop to the static setpoint was scored against the soak step's tolerance band. The band was drawn around a setpoint the process was never chasing, so an alarm-tier excursion opened on a run that had not breached anything — and that excursion fed the run verdict.
- Affected versions
- 1.27 through 1.35, and only for profiles that both have per-step tolerance bands configured and have an End step immediately following a monitored soak step.
- How to recognise an affected report
- On the Per-Step Tolerance Bands page, an excursion recorded against the final monitored soak step, beginning at the moment the profile moved to its End step, with the process value still at soak temperature. The Session Trend on page 2 will show the process tracking normally through that window.
- What it means
- The verdict may be wrong. This is the only item in this release where the reported outcome, rather than its presentation, could be incorrect — a run reported as FAIL or FLAGGED FOR REVIEW on this signature may have been a passing run.
Monitor-only steps were labelled "Advisory" on the tolerance report
A value on the record is affected
- What was wrong
- The Configured Bands table tested a three-value setting with a two-value test, so any step set to Monitor only printed as Advisory. The two are not interchangeable: a monitor-only step never contributes to the verdict, while an advisory step can escalate a run to review.
- Affected versions
- 1.27 through 1.35, for any report whose profile used at least one monitor-only step.
- How to recognise an affected report
- The Criticality column shows "Advisory" for a step you configured as Monitor only. The report gives no other indication.
- What it means
- The verdict was correct. The stated criteria were not. A reader reconciling the verdict against the criteria table could reach a wrong conclusion about which steps could have caused it — a passing run looks lenient, and a flagged run lists candidate causes that could not have caused it.
The total duration was multiplied by the number of logged parameters
A value on the record is affected
- What was wrong
- The SUMMARY row of the Per-Step Statistics page summed each step's duration once per row rather than once per step. With three parameters logged, a five-minute run reported fifteen minutes. The multiplier varies with how many parameters the chamber logs, so two identical runs on differently configured chambers reported different totals.
- Affected versions
- All versions before 1.36.
- How to recognise an affected report
- The SUMMARY duration does not match the span of the Session Trend on page 2, and equals the sum of the per-row Dur(min) values instead.
- What it means
- The duration figure is wrong. Every other figure on that page is correct — maximum error, average error and sample count all aggregate correctly.
General Information could describe a different run
A value on the record is affected
- What was wrong
- The recipe, run start, run end, operators and initial process values were read from the chamber displayed on screen when the report was generated, rather than from the logging session the report covers. A report generated for a historical session could carry another run's details. The data file field was also blank for runs logged in Continuous mode.
- Affected versions
- All versions before 1.36.
- How to recognise an affected report
- The Run Start or Run End does not agree with the session named on the same page, or with the time span of the Session Trend. A blank "Data file" is the other indicator.
- What it means
- The measured data is correct; the header identifying it may not be. The trend, statistics and tolerance pages were always read from the session — this affects which run the document says it describes.
Excursion times were printed in UTC while every other time was local
Presentation only — data is correct
- What was wrong
- Excursion entry and exit times on the tolerance page were rendered in UTC, while every other timestamp in the report — the header, the trend axis — was local.
- Affected versions
- 1.27 through 1.35, on any machine not set to UTC.
- How to recognise an affected report
- The excursion time does not fall within the Session Trend's axis on page 2, and is offset from it by exactly your machine's UTC offset.
- What it means
- Presentation only — the excursion is real and its duration is correct, but it cannot be located on the trend chart it is meant to be reconciled against. Reports produced by 1.36 label these columns "(local)".
An interrupted run could be deleted, taking its batch information with it
A value on the record is affected
- What was wrong
- A run interrupted by a Windows restart never reached its normal stop, leaving the session unfinalised with no committed samples. On the next launch, orphan cleanup deleted zero-sample sessions outright — including the operator's batch information. A separate defect could wipe the batch grid when a false completion signal arrived mid-run.
- Affected versions
- All versions before 1.36.
- How to recognise an affected report
- A run you know took place that does not appear in the Historical Data Viewer or in the QA Report session list.
- What it means
- Affected sessions are not recoverable. Version 1.36 never deletes a session that carries batch information, and finalises logging on Windows shutdown as well as on normal application close.
