Release notes

What changed, and whether it affects your records

ProcessView+ runs in validated environments, so these notes are written to answer one question first: does this release affect a report you have already filed? Where it does, each entry says how to recognize an affected document and what it means for it.

Version 1.39

9 September 2026

This release changes what a signature says about who made it. Every electronic signature now records the signer's printed name, taken from their account at the moment of signing, and signing is refused when an account cannot supply one. Three certificate types previously showed something other than the signer or the signing instant, and the entries below say what that means for documents already filed. A new installation's audit records are protected under a key belonging to that machine alone, so ProcessView+ now asks for a recovery file — held elsewhere — before it will write an audit entry, sign, or switch the audit trail on. Installations upgraded from an earlier version are not affected by that and need no recovery file. The 21 CFR Part 11 compliance statement is reissued at Revision F, which re-verifies every clause against the software rather than carrying rows forward.

Affects records produced by earlier versions

A run could be flagged for review against tolerance limits nobody configured

Reported outcome may be wrong

What was wrong: The direction first, because it decides whether you need to act at all: the outcome could only be raised from Pass to Flagged for review, never the reverse. No run was passed that should have failed; what could happen is a run whose data supports a pass being reported as flagged. Simulation Mode seeds five demonstration monitor channels — thermocouples with warning and alarm limits of 310 and 320 °F — so the built-in virtual chamber has something to demonstrate, and two faults let those rows escape the demonstration. They were stored against profile slot 1 and the tolerance runtime matches saved configuration by slot number before name, so any real profile in slot 1 on the same COM port inherited them; and nothing removed them when Simulation Mode ended, because they are written to the shared process database rather than to the simulation settings that are swapped out on exit. The Tolerance setup screen loads by profile NAME, so it correctly showed every analog input as Off at the same moment the runtime was alarming on them — the screen and the runtime answering two different questions.
Affected versions: Versions 1.37 and 1.38, and only where Simulation Mode was actually run at least once — an installation that has never entered it has no demonstration rows and cannot be affected. Four conditions had to hold together, and any one of them ruling you out settles it: (1) Simulation Mode was run on that machine; (2) a real profile occupied slot 1 on the same COM port the demonstration used; (3) readings on the affected analog inputs crossed 310 or 320 °F during the run; and (4) a QA report was produced for that run.
How to recognize an affected report: A QA report reading Flagged for review whose excursions sit on analog inputs that the Tolerance setup screen shows as Off, at warning and alarm limits of 310 and 320 °F that nobody at your site configured. Those three together are the signature, and the 310/320 pair is the distinctive part: it is the demonstration's own limits, not a value the software would derive from anything you entered. A run with no such excursions is unaffected, whatever its verdict.
What it means: A report carrying that signature states a verdict its own data does not support, in the cautious direction. The process data, the logged readings and the audit trail are unaffected and remain accurate; what is wrong is the conclusion drawn from limits that were never yours. If such a report has been filed as evidence the run can be re-judged against the limits actually configured for it, because the logged data is intact and a report can be regenerated; and if a deviation was raised on the strength of one, it was raised against an excursion that does not describe your process. From 1.39 the demonstration rows are stored against a reserved slot number that can never match a real profile, and are removed when Simulation Mode ends — including rows left behind by an earlier version.

Calibration certificates named a Windows account, not the signer

A value on the record is affected

What was wrong: An Analog Input Calibration certificate showed the Windows account the calibration wizard had been launched under, and the time the PDF was produced. Neither is the signer, and neither is the moment the signature was executed. 21 CFR Part 11 §11.50(a)(1) asks for the printed name of the signer; a login identifier is not one.
Affected versions: All versions up to and including 1.38, on every signed Analog Input Calibration certificate.
How to recognize an affected report: A calibration certificate whose signature block shows a Windows login (for example "glenn" or "DOMAIN\\svc_lab") rather than a person's name, and whose stated time is when the PDF was generated rather than when the signature was applied.
What it means: The signature itself is intact and verifiable in the audit trail, which has always recorded the authenticated user. What the certificate REPRODUCES was incomplete: it did not carry the printed name, the meaning of the signature, or the signing instant. A filed certificate is therefore not self-contained evidence of who signed and what they meant, and the audit trail must be consulted alongside it. From 1.39 the certificate carries the printed name, the account, the meaning, the signing instant and a reference to the signature in the audit trail.

Certificates showed when the record was written, not when it was signed

A value on the record is affected

What was wrong: Temperature Uniformity Survey and System Accuracy Test certificates showed the moment the record was written or the document produced, rather than the instant the signature was executed. On the System Accuracy Test certificate the meaning of the signature was also not the one the signer had chosen.
Affected versions: All versions up to and including 1.38, on TUS and SAT certificates carrying a signature.
How to recognize an affected report: A certificate whose stated signing time matches the file's creation time rather than the entry in the audit trail, or a SAT certificate showing a meaning the signer did not select.
What it means: The two times are usually close and occasionally are not — a document regenerated later carried the later time. Where the distinction matters, the audit trail holds the authoritative signing instant and always has. From 1.39 the certificate reproduces that instant, and the SAT certificate reproduces the meaning actually chosen.

The report editor opened when it could not tell whether a signature was required

A value on the record is affected

What was wrong: When the digital-signature setting could not be read, the report editor opened and behaved as though signing were optional. A setting that cannot be read is not the same as a setting that is switched off.
Affected versions: All versions up to and including 1.38, on installations where that setting was unreadable at the moment a report was produced.
How to recognize an affected report: This leaves no distinguishing mark, which is the substance of the problem: a report produced under those conditions cannot afterwards be told apart from one that never needed a signature.
What it means: Where mandatory signing was configured and the setting could not be read, an unsigned report could be produced and would not announce itself as such. From 1.39 the editor refuses to open rather than assuming the permissive answer.

Security

The audit folder is protected against deletion by ordinary users

Security fix

The audit trail's integrity checks detect a record being ALTERED. They cannot detect the trail being DELETED, because the checking data lives inside the file that would be removed, and a deleted trail is replaced by an empty one that looks like a new installation. ProcessView+ now applies Windows permissions to the audit folder so a standard user account cannot delete or rename the audit database, and writes a note into that folder explaining the permissions and who to contact. The note is written whether or not the protection could be applied, and states which of the two happened.

Audit records on a new installation are protected under a key unique to that machine

Security fix

An audit database created by version 1.39 or later is protected under a key belonging to the machine that created it, rather than a value carried in the software. Because such a key can be lost with its machine, ProcessView+ requires a recovery file — held outside the machine and protected by a passphrase you choose — before it will write an audit entry, apply a signature, or switch the audit trail on. An audit database created by an earlier version keeps the protection it was created with, is never converted, needs no recovery file, and displays a standing note in Audit Trail Setup saying so.

Corrections

Every password an administrator created was exactly 12 characters, whatever length was asked for.
On a new installation the profile list was disabled and no profile could be chosen. First installations only; an installation already set up was unaffected.
A reminder on the Audit Trail Setup screen was drawn underneath the Cancel and Save buttons and was cut short by its own box.

Improvements

A System Accuracy Test can no longer be completed or abandoned while audit logging is switched off. A Temperature Uniformity Survey already refused to start under those conditions.
A new installation walks you through creating the first administrator, including the printed name and the audit recovery file, on one screen. If the recovery file step fails, the account is not created twice on a second attempt, and the identity fields lock so a name already in the audit trail cannot be quietly edited.
An installation with a single administrator account says so, once. Losing the only administrator account means losing administrative access. The reminder can be dismissed and stops appearing as soon as a second administrator exists.
A new installation's trend chart is named for the controller rather than opening as "My Chart Title", and the profile list opens on the profile used last.
Passwords and user names may be up to 20 characters on every screen that creates, changes or accepts them.
The user manual gains First-Run Setup, The Audit Recovery File, and a Troubleshooting appendix. Analog Input Calibration and Tolerance Band Monitoring have moved to the chapters they belong in. The 21 CFR Part 11 compliance statement is reissued at Revision F.

Version 1.38

30 August 2026

This release closes the gap the audit trail's own integrity checks could never cover: the folder holding the audit database is now protected so an ordinary Windows user cannot delete it. Deleting a logging session now requires an administrator and a reason, and audit verification now states what it checked rather than reporting an unqualified pass. Several entries below change what an earlier version had recorded, or what it reported about a file — including a data-log column that was written empty on automatic-login installations, and a backup verification that could report TAMPERED when the check had simply not run. Note before upgrading: the audit trail database is upgraded automatically on first launch and earlier versions cannot open it afterwards, so take a copy first if you may need to go back. The FTP upload has also been removed — it sent credentials and file contents in clear — and is replaced by a copy to a folder you nominate.

Affects records produced by earlier versions

Refused actions were not recorded when audit logging was switched off

A value on the record is affected

What was wrong: The audit trail has a setting that switches routine change logging on and off. That setting also suppressed the record of a refused action — an attempt to do something the signed-in user does not have rights to — along with the application-exit entry and entering or leaving Simulation Mode. A record the person it concerns can switch off is not a record.
Affected versions: Versions up to and including 1.37, on installations where the audit setting was off for any period.
How to recognize an affected report: A period with no regulated entries during which the audit setting was off. A gap of this kind cannot be told apart from a period in which nothing happened.
What it means: For those events the earlier trail is incomplete and its silence is ambiguous. Records already written remain intact and verifiable. From 1.38 all three are recorded regardless of the setting.

Audit verification reported an unqualified pass for records it could not fully check

A value on the record is affected

What was wrong: Records written before version 1.30 carry an earlier integrity check that does not use a key. Verification accepted them — correctly, because that is how they were written — but reported the result as an unqualified "intact" and said nothing to distinguish them from records verified against the integrity key.
Affected versions: Any database holding records written before version 1.30.
How to recognize an affected report: A verification report reading "Audit chain: intact" on a database in service before version 1.30.
What it means: Nothing has changed about your records and nothing has been found wrong with them. From 1.38 the report states how many records carry the older check and that the remainder were verified against the key — something that was always true and was not previously said. The wording changes on the day you install this version. A database whose records were all written on 1.30 or later still reports "intact".

A backup that could not be checked was reported as altered

A value on the record is affected

What was wrong: When verifying a data-log backup, if the integrity file protecting it could not be read — because it was open in another program, because permissions denied it, or because it was incomplete — the result was reported as TAMPERED, in red. Nothing was wrong with the backup; the check had not been able to run.
Affected versions: Versions up to and including 1.37.
How to recognize an affected report: A backup reported TAMPERED that you have no other reason to doubt, particularly one verified while it was open elsewhere or held on a location with restricted permissions.
What it means: The file was not shown to be altered and the report should not have said so. If a deviation was raised on such a result, the finding was about the check, not the data. From 1.38 the result reads NOT CHECKED with the reason, and says plainly that it tells you nothing about the file's contents. A backup that genuinely has no integrity data is now reported differently again.

The data log's User Name column was written empty on automatic-login installations

A value on the record is affected

What was wrong: On installations using automatic login the data log's User Name column recorded no value. The signed-in user was shown on screen, but the column was written empty for every reading.
Affected versions: Versions up to and including 1.37, on installations using automatic login only. Installations where an operator signs in manually were not affected.
How to recognize an affected report: An empty User Name column throughout a logged session.
What it means: Data logged before 1.38 on an automatic-login installation has no operator recorded in that column and it cannot be added retrospectively — the value was never captured. You will see the column change from empty to populated on the date this version was installed. That change of date is this fix, not a change of operator.

A newly installed system could end up unable to keep an audit trail at all

A value on the record is affected

What was wrong: On the very first run of a new installation, before any audit settings existed, ProcessView+ could create its audit database in a state it would never be able to open again. Nothing appeared wrong at the time — the application started and ran normally and signing in was unaffected — but the audit trail on that installation was permanently unusable, and switching it on reported only "Audit trail could not be initialized". This was introduced by another change in this same release, and we would rather say so than leave it unexplained: making refused actions, application exit and Simulation Mode transitions impossible to suppress meant a brand-new installation wrote its first audit record earlier than before, at a point where the audit database was not yet ready to be created correctly. That change was right and it stays.
Affected versions: First-run installations of pre-release 1.38 builds only.
How to recognize an affected report: A new installation whose audit trail reports that it could not be initialized when you switch it on.
What it means: If you have installed 1.38 already and see this, contact us before uninstalling or deleting anything. The audit database also holds your user accounts, so removing it to clear the problem would remove those too. The situation is recoverable and we would rather do it with you. ProcessView+ now declines to create the audit database until it is ready, so a first run leaves nothing behind and the next start sets it up correctly.

Security

The audit trail is now protected against deletion by ordinary users

Security fix

The folder holding the audit trail (C:\ProgramData\ProcessView\Audit Trails) is now protected so that ordinary Windows users cannot delete or rename the audit database. Reading, and the application's own recording, are unaffected. Why it matters: the audit trail's integrity checks detect whether records have been altered, but they cannot detect a trail that has been deleted, because the checking data is stored inside the file being deleted — a deleted audit trail is replaced by an empty one on the next start and looks like a new installation. This change closes that gap. Whether it succeeded is now visible: the audit trail configuration screen shows a Folder protection row alongside the record count, and if you switch the audit trail on while the folder is unprotected the application says so at that moment — the point at which somebody has decided to rely on the trail. It applies automatically, the first time ProcessView+ runs after updating, and on a new installation the installer applies it before the first run. Nothing is prompted and no action is required. What administrators should know: the change alters NTFS permissions on that one folder. Members of the local Administrators group and SYSTEM are unaffected and retain full control. Any tool running as a standard user that needs to delete or move files in that folder — some backup and archiving agents — will no longer be able to; a move counts as a delete. Tools that only read the folder are unaffected, as is anything running as SYSTEM or an administrator. ProcessView+ also owns that folder's permission list from now on: any entry added to it by hand is removed the next time ProcessView+ starts, and each removal is named in the startup diagnostics log and recorded in the audit trail. Grant the access on a parent folder instead, or use an identity that already has it. A README-permissions.txt file in the folder explains the same thing to whoever finds the permissions first. If the protection cannot be applied, that is recorded in the audit trail and reported on screen — treat it as a finding rather than a nuisance, because it means the trail is recording while unprotected. Reversing the protection requires an elevated command prompt, removes a control rather than adjusting a setting, and is undone again at the next start.

The FTP upload has been removed, and replaced

Security fix

Up to and including 1.37, ProcessView+ could upload a completed data file to an FTP site. It transmitted the user name, the password and the contents of the file in clear, where anyone able to observe the traffic could read them, and our secure deployment guidance had advised against using it. Rather than continue to ship it with a warning attached, 1.38 removes it — the upload, the credential screen, and the stored FTP address, user name and password. What replaces it is a copy to a folder you nominate, described under Improvements below: a local folder, a mapped drive, or a network path. Authentication is Windows', no credential is stored by the product, and the destination is protected by your own permissions. If your site was using FTP, the upload stops at 1.38 and nothing prompts anyone — set a destination folder as part of the upgrade, and check the audit trail afterwards, where each copy is recorded. In practice very few installations can have been affected: the screen for entering the FTP address and credentials was reachable only from a configuration screen superseded some releases ago, so on a current installation those details could not be entered or changed, and an installation with the option ticked was uploading to whatever an older version had left behind. If you find FTP settings in a settings file they are now unused, and the password in them should be treated as one that has been transmitted in clear.

The MQTT broker password is no longer stored in plain text

Security fix

Up to and including 1.37 the MQTT broker password was written into the settings file exactly as typed, in a directory every Windows account on the PC can read — so anyone able to open a file could read it, whatever their role in ProcessView+. From 1.38 it is encrypted with Windows DPAPI before it is written. The conversion is automatic: an existing password keeps working and is re-saved in protected form the next time the MQTT settings are saved. Two things to know. First, the boundary: the protection is tied to the machine rather than to one Windows account, because every account that runs ProcessView+ has to be able to use it — so reading the settings file is no longer enough, but running code on that PC still is. It removes the casual exposure; it does not make the password safe on a machine you do not trust. Second, and more important on upgrade: the old password has been readable in a file for as long as it has been configured, so change it at the broker rather than treating this release as protecting it retrospectively. ProcessView+ tells you so when it opens a password stored the old way. A settings file moved to a different PC loses the password by design — it can only be read on the machine that saved it — and ProcessView+ says so and asks for re-entry rather than connecting with a blank password and reporting it as a rejected login, which can lock out a broker account.

The web dashboard is no longer published to every network

Security fix

The optional web dashboard is off by default and we continue to recommend leaving it off. When it was switched on, though, it bound every network interface on the PC — on the dual-homed machine a chamber network deserves, that included the business network. From 1.38 it serves only the PC it runs on unless you tick a new box, Allow access from other computers, on the Web Server screen. If you were reaching the dashboard from another machine, it stops working at 1.38 until that box is ticked. This narrows who can reach the dashboard and changes nothing else: it is still plaintext HTTP with no authentication of any kind, so everything it shows — live readings, chamber names, profile status, alarm state — is visible to anyone who can reach the port. If you need it, restrict the port with your firewall as well. HTTPS and authentication are a separate piece of work and have not shipped.

Corrections

A user name containing a comma no longer shifts the following columns in the exported CSV.
A backup with no integrity data is now told apart from one that could not be checked. Where auditing was unavailable, every backup was previously reported as having no integrity data — including backups that were protected and whose integrity file was sitting beside them.
Correction to the manual's description of session deletion. The Session Manager section of the User Manual, and the matching in-product help, described deletions as being recorded when the two buttons in that dialog did not record them. Both are corrected in this release, and a separate notice is issued with it.

Improvements

A completed data file can now be copied to a folder when a profile ends — a folder on the PC, a mapped drive, or a network path — set per data-logging configuration on the Session Control tab. The copy never overwrites: a file of the same name at the destination is left alone and the new one is written alongside it. Where a run was recorded with tamper-evident logging, the companion verification file is copied with it, so the copy can still be verified. Each copy is recorded in the audit trail with where it was written, and so is each copy that could not be made, with the reason. It runs in the background, so a slow or unreachable destination does not hold up the end of a profile and does not interrupt the operator. The destination is outside the application's control: what protects those records is the folder's own permissions and your backup regime.
Deleting a logging session now requires an administrator and a reason, and both are recorded. This applies to single and bulk deletions. Installations using automatic login will be asked to sign in first — use Login on the menu bar; the application does not need to be restarted. Deleting every session before a chosen date now asks you to type that date before it will proceed.
Session Manager has a new Deleted Sessions view listing every recorded deletion — what it was, when, by whom and why. Where a deletion was started and its completion was never recorded, the view says so at the top rather than leaving it to be noticed.
Discarding a trend recording is now recorded too. It does not ask for a reason and does not require an administrator — you are declining to keep a recording you have just made — but the deletion is recorded in the same two places.
Exported audit trails now state which records are keyed. The CSV export gains two columns, HashVersion and CanonicalVersion, appended after the existing ones so that any spreadsheet or script reading the previous column order continues to work. The file also begins with a short description of what it is: that record linkage can be checked from the file itself, that the hashes cannot be recalculated from it, and that it is a copy rather than evidence of matching the database it came from.

Version 1.37

23 August 2026

A large release, and several of its corrections change what an earlier version could have written into a record — including cases where a reported PASS was not evidence that anything was checked. If you hold QA reports or logged sessions produced by 1.36 or earlier, the first section is worth reading. Note before upgrading: the audit trail database is upgraded automatically on first launch and earlier versions cannot open it afterwards, so take a copy first if you may need to go back.

Affects records produced by earlier versions

A tolerance verdict could read PASS with a zone that was never checked

Reported outcome may be wrong

What was wrong: A zone with no tolerance band configured was skipped silently, and the overall verdict was reported as a pass regardless of what that zone did. Nothing on the report said a zone had gone unjudged.
Affected versions: Versions up to and including 1.36, on any run where at least one logged zone had no band set.
How to recognize an affected report: On the tolerance page, a zone present in the run with an empty criteria cell, while the overall verdict reads PASS.
What it means: The verdict may be wrong — a pass was reported on evidence that did not cover every zone. From 1.37 the verdict reads INCOMPLETE, names how many zones could not be judged, and states why for each.

Tolerance bands could be applied to the wrong zone

Reported outcome may be wrong

What was wrong: Bands were handed out by position in the list rather than by the loop they belong to, so on a chamber with both temperature and humidity control a zone could be judged against the other loop's band. Separately, a zone could be paired with another loop's setpoint, making its setpoint error, overshoot and undershoot the difference between two unrelated quantities.
Affected versions: Versions up to and including 1.36, on chambers with more than one control loop. Where both loops used identical band values, no verdict was affected.
How to recognize an affected report: A humidity band value shown against a temperature zone, or the reverse; or a setpoint error figure far larger than the trend supports.
What it means: The verdict may be wrong in either direction — a wrong band can produce a false pass or a false failure. Bands and setpoints are now matched to zones by loop and by unit.

On cascade loops, readings and bands could follow the wrong sensor

Reported outcome may be wrong

What was wrong: A chamber using a cascade loop could log the inner sensor's reading under the outer sensor's name and the outer's under the inner's. Where the cascade was turned off with the Single SP setting, the loop controlled on the air sensor while the tolerance band stayed on the product sensor, so the run was judged against a sensor the loop was no longer controlling.
Affected versions: Versions up to and including 1.36, on cascade-configured loops only.
How to recognize an affected report: Two cascade sensor traces whose behavior is transposed against what the chamber did, or a band drawn against the product sensor on a run made with Single SP enabled.
What it means: Both the logged data and the verdict may be wrong for that loop. From 1.37 the band follows the controlling sensor, the setup screen names that sensor, and which sensor was judged is fixed when the run starts and recorded with the run.

A run that was never measured could be recorded as a pass

Reported outcome may be wrong

What was wrong: A brief false "profile complete" signal from the controller could end a run about a second after it began. No reading was ever checked, but the run was too short for anything to be recorded as unmonitored either, so every step looked clean and the run was written to the record as having passed. The same false signal could also stop tolerance monitoring for the whole of the run that followed, which was then recorded as not evaluated.
Affected versions: Versions up to and including 1.36.
How to recognize an affected report: A recorded run of a few seconds carrying a PASS, or a full-length run whose trend shows no tolerance shading and whose export has no tolerance columns.
What it means: A pass on such a run rests on nothing. From 1.37 a run with nothing measured is flagged for review and the record states that no reading was checked, and monitoring restarts with the new run.

A profile start could run a different profile without saying so

A value on the record is affected

What was wrong: On serial controllers the application waited for the controller's reply by counting rather than by time, so on a fast PC it could send the next command over one still in progress. A profile start sends three commands in a row this way, so the command naming the profile or the start step could be lost — and the run began anyway, possibly on the previously selected profile.
Affected versions: Versions up to and including 1.36, on serial-connected controllers.
How to recognize an affected report: A run whose trend does not follow the recipe the record names, or a start that reported a communication error and appeared to take anyway.
What it means: The measured data is correct; the recipe the record files it under may not be. From 1.37 a failed setup command stops the start and names the step that failed.

Readings were recorded while the controller was not answering

A value on the record is affected

What was wrong: During a communications outage the log continued to record, but the values written were the last value the controller supplied rather than fresh measurements. The trend drew them as a flat line, indistinguishable from a chamber holding perfectly steady.
Affected versions: Versions up to and including 1.36, on any run that included a communications outage.
How to recognize an affected report: A perfectly flat stretch in the trend, cross-checked against the Communication Event Log for an outage over the same period.
What it means: Those readings are not measurements of the chamber. From 1.37 the interval is shaded on the chart and marked COMMUNICATIONS LOST, beginning when the controller went quiet rather than when the loss was noticed.

Gaps in the data log were not marked

A value on the record is affected

What was wrong: If anything held up the application's screen — a dialog waiting on a slow network, or a lengthy operation — data logging stopped for as long as it lasted. Separately, with logging set to run during a profile only, a single due reading could be skipped when the running state was momentarily not recognized.
Affected versions: Versions up to and including 1.36.
How to recognize an affected report: An interval in the logged data with no rows, or a single missing sample interval, with nothing in the record noting either.
What it means: Missing readings were indistinguishable from readings that had not changed, and one missing reading is enough to prevent mean kinetic temperature being calculated for a run. From 1.37 logging runs independently of the screen and continues throughout.

Analytics temperatures were labeled °F whatever unit the run recorded

A value on the record is affected

What was wrong: Every temperature on the analytics view and in its export was labeled Fahrenheit, including for runs logged in Celsius.
Affected versions: Versions up to and including 1.36, for runs logged in Celsius.
How to recognize an affected report: Analytics figures labeled °F whose values match a Celsius trend for the same session.
What it means: The figures are correct; the unit stated beside them is not. Runs now carry the unit they were recorded in. Runs logged before 1.37 did not record a unit and are shown as unknown rather than assumed.

The QA report could drop or overprint text

A value on the record is affected

What was wrong: The report was drawn at fixed positions on fixed-size pages. A label wider than its column was painted over the value beside it, a note longer than the page width was absent from the PDF altogether, and anything past the bottom of a page was dropped.
Affected versions: Versions up to and including 1.36.
How to recognize an affected report: An "INCOMPLETE PAGE" warning printed on the report, text overlapping a value, or reviewer notes that stop mid-sentence.
What it means: A filed PDF may be missing content that was entered against the run. The report was rebuilt for 1.37 — text wraps within its column, and a table that outgrows a page continues onto the next with its headings repeated.

Security

No security fixes in this release.

Corrections

A controller's tab could stay marked Off-Line after communications were restored — in one case for more than five minutes — until a manual Refresh. It now clears as soon as the controller answers.
Communication errors no longer interrupt with pop-up dialogs. During an outage these appeared repeatedly and behind the Communication Event Log window, so the application seemed frozen with nothing visible to dismiss. Dialogs reporting the result of something you asked for are unchanged.
Communication Event Log corrections: outage durations are reported to the second rather than in whole minutes, one outage now produces one lost and one restored entry with the true duration between them, afternoon times no longer read "13:52 PM", and reopening the window no longer blanks what it was showing.
Changing a data logging setting now takes effect on Apply. Clearing "Only when a Profile is running" previously left logging switched off until the setting was changed again after a restart.
Starting a profile no longer raises a tolerance alarm against the previous run, and a failed stop no longer leaves the display showing the run as though it were still going.
Trend and overview corrections: tolerance shading no longer disappears when a profile finishes, a batch trend stops where its run ended, the overview strip draws part-length traces where they belong, dragging its edge moves the chart to match, and its time marks show seconds on short trends. The trend can also be resumed at the first attempt.
The QA report's trend chart now includes the analog inputs — a survey run previously charted the chamber and omitted the very thermocouples the report was about — and its time labels are thinned so they stay readable on short runs.
Two Report Editor settings that were saved and then never consulted now take effect. Reports set up before this version keep both sections, because a setting that was never acted on cannot say what was intended by it.
The tolerance alarm window no longer clips its text, and a four-sentence warning on the tolerance setup screen no longer runs off the edge of the form, leaving one sentence that reads as though it were complete.
Saving an F4 setup with a disabled loop, or adding a controller, could close the application. Tabs are now identified by controller rather than by position.

Improvements

Alarm email notifications now send. They were not delivered in earlier versions and the failure was silent. Emails now reach every configured recipient with names correctly matched to addresses, are sent in the background so charting and logging carry on normally, and their outcome is recorded rather than announced in a dialog waiting to be dismissed.
The email test button now exercises the same path alarm emails use and sends with your saved settings, reporting what the mail server said for each recipient — so a passing test means alarm emails will send.
Communications outages are shown rather than inferred: the chart shades the interval and marks it COMMUNICATIONS LOST, and the status bar warns, naming the controller, while readings the controller did not supply are being recorded.
Mean kinetic temperature is now reported for each zone in kelvin — on the analytics view, in its CSV export, and on the QA report, where it is shown to the signer and covered by the report's digital signature. Where it cannot be calculated the report says why rather than leaving the field blank.
An Error from Setpoint chart can be shown beneath the main chart. It plots each zone's reading minus its loop's current setpoint, so being on setpoint is a flat line at zero, and it draws the tolerance band as straight limits with alarm excursions marked. Both charts share one time axis. It is off by default.
Inputs that are watched but not controlled can now carry tolerance limits of their own, judged against absolute values rather than against a setpoint — for an exhaust thermocouple, a bearing temperature, or a chamber probe that is only being observed. Each has four limits, its own criticality and delay, can be checked step by step, and appears on the alarm window, in the audit trail and on the trend.
Each logging session now records how it ended — stopped by the operator, completed, or interrupted — so a run that ended unexpectedly can be told apart from one that finished normally.
The QA report's layout now follows its content: batch information has a page of its own under your template's headings, the trend, statistics and tolerance pages print landscape, the verdict appears as a badge carrying its reason, and a section with nothing to report is left out rather than printed empty.
Tolerance monitoring now says when it is not running. Starting a profile with data logging switched off — which leaves nothing to check against, however carefully the limits were set — is reported on the alarm display instead of appearing to monitor.
Simulation Mode arrives ready to demonstrate a complete run: a five-minute survey cycle, five charted and logged thermocouples, tolerance limits, a batch record, a prefilled QA report and a uniformity survey. Everything it produces is marked as simulated, on screen and on the printed report, and edits made during a demonstration are kept.
The status bar has been tidied, its mirroring and audit-trail indicators now explain themselves on hover, and the About window identifies the build you are running — so a question about whether a particular fix is present can be answered from the screen.
A full license agreement now ships with the product and is presented by the installer.

Version 1.36

5 August 2026

Corrects several defects that could have affected QA reports, temperature uniformity survey reports and logged sessions produced by earlier versions, and closes two gaps in what the audit trail recorded. If you hold reports generated by version 1.35 or earlier, the first section is worth reading.

Affects records produced by earlier versions

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 recognize 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 labeled "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 recognize 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 recognize 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 recognize 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 recognize 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 recognize 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.

A temperature uniformity survey report could overwrite one already issued

A value on the record is affected

What was wrong: Survey report filenames carried no timestamp, so a second survey of the same chamber wrote over the file holding the first. The replacement was silent.
Affected versions: All versions before 1.36.
How to recognize an affected report: A survey report file whose contents describe a different survey from the one it was issued for, or a survey you know was run for which no report file remains.
What it means: An overwritten report is not recoverable from the file — the underlying survey data is unaffected and the report can be regenerated. From 1.36 survey report filenames carry a timestamp.

Survey and QA reports disagreed with themselves on several figures

A value on the record is affected

What was wrong: The same quantity could be printed differently in two places in one document: the survey's verdict was computed from a different operand than the figure shown beside it, timestamps were rendered against more than one clock, and the recording window was bounded from the segment start rather than from stabilisation.
Affected versions: All versions before 1.36.
How to recognize an affected report: A maximum-deviation or duration figure in the summary that does not match the per-point table it summarizes, or two timestamps in one report that cannot both be right.
What it means: Which of the two figures was correct depends on the quantity, so a document showing this signature cannot be reconciled from its own face. The underlying logged data is unaffected and a report regenerated on 1.36 or later is internally consistent.

Changes to the Part 11 controls themselves were not recorded

A value on the record is affected

What was wrong: Changes made to the Part 11 settings were not written to the audit trail, and one audit setting could suppress records that must always be kept regardless of configuration.
Affected versions: All versions before 1.36.
How to recognize an affected report: No audit trail entry for a change you know was made to the Part 11 configuration, or a period with no regulated entries during which the audit setting was off.
What it means: The audit trail may be incomplete for those events. Records already written remain intact and verifiable. From 1.36 these changes are recorded, the gate can no longer suppress regulated records, and logging session start, stop and interruption are recorded as well.

Security

No security fixes in this release.

Corrections

The Simulation Mode splash described the simulator as "F4T with 2 PID Loops". The simulator uses a first-order lag model; it now reads "F4T simulator".
Warning-tier excursions were shown in the same color as alarm-tier ones on the QA Report screen. The text distinguished them; the color did not.
The data-logging master switch is relabeled to describe both of its effects.
The alarm menu now refreshes after an F4 setup edit without restarting.
The data-log indicator refreshes on Apply rather than on the next poll.

Improvements

Logging session lifecycle auditing. The start, stop and interruption of a logging session are now recorded, so a run that ended unexpectedly leaves a trace of having done so.
Batch Setup field templates. New installations start from a named field set — heat treat and aerospace, or pharmaceutical stability — rather than generic parameter names, and either can be applied as a starting point before customising. Existing configurations are untouched.
Temperature uniformity survey reports gain a maximum-deviation column beside the tolerance it is judged against, a single timezone throughout, corrected chart layout, and the signer's printed name alongside their user id.
Dark mode extended to ten further forms, with theme-aware alarm and status colors.
Status indicators on the main screen and digital inputs replaced with a clearer LED component.
Tuning screen: autotune status values no longer overflow, and the Autotune Setpoint buttons carry an explanation.
Zone panels show each control loop's mode in the title bar, and keep the Current SP row visible.
Email and SMS notifications redesigned, with a simulated outbox in Simulation Mode.
Auto-login corrections to menu state, role prefix and the current-user label.

Release notes begin with version 1.36. Earlier version history is available on request — contact us.