FrameworX 10.1 Update 5f is the current release in the 10.1 platform, delivered September 9, 2026, as a free upgrade for every FrameworX 10.x customer. Update 5f replaces Update 5e and contains everything Update 5e delivered, together with further corrections. Installations running Update 5e should move to Update 5f.
Release Notes → Update 5f
Update 5f replaces Update 5e. It carries the complete content of Update 5e (August 31, 2026). If Update 5e is installed, replace it with Update 5f. No migration or rework is involved. See Upgrading from Update 5e below for the one behavior that differs between the two. |
The Update themes:
/TimeAutoSwitch.See Update 5f - Detailed Release Notes for the complete item-by-item list.
Update 5f replaces Update 5e and carries its complete content. One behavior differs. On alarm historians reached through an ODBC or OleDb connection to Microsoft Access, Microsoft Excel, or CSV files, alarm history queries worked on Update 5e and do not on Update 5f. Those connections behave as they did in 10.1.4, which is the behavior described under Alarm historians over ODBC or OleDb below. Alarm historians reached through a native connector are not affected.
Viewing alarm history from a Trend Chart, a Drilling Chart, or the Alarm Viewer completes without a database syntax error. This covers alarm historians on PostgreSQL, Oracle, and MySQL reached through their native connectors, and ActionNet-branded installations, where the query could previously be rejected by the database. Where the query failed, the chart kept drawing the data it already held, so the failure was easy to miss, but the alarm markers were missing or out of date and the query failed again on every refresh. The correction covers the Alarm Viewer in both Alarm History and Audit Trail modes, and applies to the rich client and the HTML5 client alike.
On a redundant pair whose history database is very large and uses TimescaleDB compression, Tag Historian data no longer stops reaching the standby node. Rows still waiting to be replicated when their portion of the database was compressed could no longer be read by the replication process. Each cycle attempted to read the whole table, exceeded the connection time limit and restarted, so the backlog never drained and no history reached the standby. Alarm replication was unaffected, because alarm rows are replicated before compression takes place. A second condition affecting Tag Historian data in normalized configuration is also corrected. A small number of rows could arrive at the standby without a tag name, and the standby rejected the entire batch, so a few unresolvable rows blocked all the remaining valid rows on every cycle. The standby now imports the rows it can resolve and reports the ones it cannot, and the active server records which tag index it could not map.
On a redundant pair, the active server's runtime process no longer grows without bound under alarm-history load. A server-side ceiling, Alarm.HistoryQueryMaxRows in TServer.json, bounds how many alarm-history rows a single query may load. Redundancy settings are now applied when the runtime auto-starts as a Windows service after a computer restart, with a new optional /redundancywaittimeout:<seconds> argument for machines whose network stack comes up slowly. See Breaking Changes and Deprecations below for a change in replication behavior around handovers.
On an alarm historian reached through an ODBC or OleDb connection, every query that separates alarm records from audit trail records is rejected by the database, so the Trend Chart and Drilling Chart show no alarm markers and the Alarm Viewer's Audit Trail view returns nothing. The Alarm Viewer's Alarm History view is affected only when Audit Trail is enabled. With Audit Trail off it works normally, and the combined Alarm History plus Audit Trail view is unaffected.
This covers Microsoft Access, Microsoft Excel and CSV files, and Oracle, MySQL, or Firebird when connected through ODBC or OleDb rather than their native connector. Alarm historians on SQL Server, SQLite, or on PostgreSQL, Oracle, and MySQL through their native connectors are not affected.
The HTML5 web client starts significantly faster, with the largest gains on internet and high-latency connections. The connection sequence runs its steps in parallel, the browser opens its communication channel while the page loads, and repeated round trips were removed from the startup path. Server responses now reach remote clients in a single network round trip, which improves the responsiveness of displays, trends, and reports over remote connections. Upgrades remain compatible with servers and clients from earlier 10.1.5 updates. Large array and matrix tags populate immediately again when a Display opens, and symbol Rotate animations no longer accumulate memory in the client.
With DebugMessages logging enabled, the runtime trace log records a SCRIPT PROFILER entry each time a Script Task runs and each time a Script.Class method is called, so you can see which scripts are slow and which ones started but never returned. Durations are now measured with a high resolution timer, so a method taking a few microseconds is timed accurately where short running scripts previously reported a duration of zero. The reported time covers only the script execution itself. Every started entry is followed by exactly one matching terminator entry, including when the script raises an error, and a Script.Class method that raises an error is reported as failed rather than finished. Method parameter values written into the log entry are limited in length, and a parameter that cannot be converted to text no longer truncates the rest of the entry.
Two notes for anyone enabling DebugMessages. Parameter values passed to Script.Class methods are written to the trace log as they are, so avoid passing passwords, tokens, or connection strings to a script method while this log level is on. And each entry is written according to the log level in effect at the moment that entry is due, so if you turn the level off while a script is still running, its started entry can be left without a matching terminator. Entries for Script.Class methods are recorded when the method is invoked from a client session.
Saving a Script Class no longer freezes the Designer in solutions where script classes reference each other.
Symbol mapping for tags is consistent across the Displays tag panel and the Unified Namespace Tags list. In the Drag Tags to Display panel of the Display editor, the Map a Symbol button opens the picker for tags of a basic type, Digital, Integer, and Text, and not only for tags of a User Type. A tag that already carries a symbol mapped through the Tags list is shown as mapped in that panel, with its preview rendered, and dragging it onto a Display inserts the mapped symbol. A symbol mapped on a User Type is reported as mapped in the Tags list and on the instances of that User Type, so the same tag no longer reports two different states depending on where it is viewed. Clearing a mapping from the tag panel takes effect for basic type tags and is reflected in the Tags grid, and dragging a tag whose mapped symbol can no longer be resolved inserts a default component instead of failing silently.
Display geometry is preserved on the import and export round trip across four separate paths, custom symbols survive a migration from FrameworX 10.1.4 to 10.1.5, and popup displays imported with a fixed custom position keep that position. Display parameters used as part of a larger expression track live values again, in pages and popups alike. Dynamics Get and Apply keeps its theme binding on transferred colors, the Asset Tree control no longer raises an exception when Localize is enabled, and enumeration-driven colors resolve correctly.
Ontology import now reports what it actually created rather than what it planned to create, keeps member names consistent for the same property across UserTypes, classifies a class correctly instead of converting it into an Enumeration, and resolves a relationship to an object that is not declared in the file instead of silently storing it as plain text. Exported knowledge-graph visuals render in Firefox, show instance-of relationships in the Markdown diagram, and refer to UserTypes by their product name. Import Solution brings Templates and Tags in correctly.
Re-importing a file or solution over existing content updates the existing objects instead of silently skipping them. The LinearGauge label, tick, and scale-bar colors are exposed on the JSON / MCP write path, so gauges authored from automation can match a legacy HMI palette. TK.PreloadObject preserves the object name's letter case.
The Modbus master reads device identification data using function code 43. On the mobile client, the Settings screen connection fields are readable when the device is in Light mode. Clients that connect while the runtime is still starting no longer come up unlicensed on a correctly licensed machine, AutoStartClient detects a Rich Client that is already running instead of opening another window, and a runtime running as a Windows Service no longer starts the Run Tools as hidden background processes.
Solutions running on .NET Framework 4.8 can sign users in through OpenID Connect. Sign in previously worked only in multi-platform solutions. A logon is refused when the server's user check fails internally, instead of being accepted. Stored credentials can no longer be read or overwritten through the AI tools' grid edit path. A security guard built on a parameterized display disables as configured.
The handover replication drain barrier has been withdrawn. Alarm and Historian replication behavior around a redundant-pair handover is unchanged from 10.1.5c. The change introduced in Update 5d, which held a handover open until Alarm and Tag Historian replication finished draining, has been withdrawn together with its SwitchDrainTimeoutSeconds configuration key. A configuration file that still contains that key is accepted and the key is ignored. Rows recorded on the active node in the moments immediately before a handover may therefore not reach the other node.
On redundant pairs started with /autoswitch, use the existing /TimeAutoSwitch:<seconds> startup argument (default 60) to give replication time to finish before the restarting Primary reclaims the Active role. Increase it beyond the default for large Solutions, slow networks, or high alarm and data-logging rates.
Update 5f ships on September 9, 2026 as a free upgrade for every FrameworX 10.x customer, with the platform's standard within-major-version 100% compatibility commitment. Every 10.1.x solution opens and runs without migration or rework.
Update 5f replaces Update 5e. Installations running Update 5e should move to Update 5f. See Breaking Changes and Deprecations above for a redundancy behavior change that may require a startup-argument adjustment on affected installations.
The full lifecycle policy, version support phases, and end-of-support dates for older FrameworX and FactoryStudio versions are documented on the Product Lifecycle and End of Support page.
This release contains security-relevant corrections. Upgrading is recommended for all installations.
One item requires action beyond upgrading: if you used the AI or MCP tooling against solutions that hold stored passwords, API keys, or database logon credentials on 10.1.5d or earlier, rotate those credentials.
Customers who need per-item detail, meaning affected versions, severity, and required action, for patch management or supplier-assurance purposes can request it from support@tatsoft.com, along with the component manifest (CycloneDX) for the version they are running.