Moving to the Current Version

Your VTScada license entitles you to upgrades for a period of time after purchase. (Maintaining a Support Plus contract provides unlimited upgrades.) You can find the end date of your SupportPlus period in the About dialog, accessible from the VTScada Application Manager. Each new version of VTScada introduces new tools and sometimes changes how older features work.

Notes:

  • Please review the lists of changes for each version of VTScada between the one you are upgrading from and the current one, to find additional tasks that you may need to perform.
  • If your application runs on a single server, create a backup before starting.
    (With multi-server applications, it is always better to let VTScada look after backups and redundancy.)
  • In general, it is better to install a new version on top of an older version.
  • VIC clients from version 11.3 or before must be updated.
  • Text in expressions or custom modules is not added to your languages CSV file automatically. In a multilingual application you must add your own phrases to the language file.
  • If your VAM has an instance of the Training Simulator, uninstall it. The simulation code is subject to change from one version to another and older versions are sometimes not compatible with the current version of VTScada. If you are still using the simulator, then after upgrading reinstall from the newest .Snapshot file in the Examples folder.

General Upgrade Procedure:

In a networked system, upgrade one workstation at a time.

You are advised to update the primary historian last.
                You must update I/O clients before I/O servers. Check that the machine you are updating is not a server for any driver.
                  These two warnings may mean that you will need to adjust your server lists temporarily. The original list may be restored after all servers have been upgraded.

Test the conversion process on an application clone, reviewing the effects in the version log.

If auto-deploy is on at this server, turn it off before stopping the older version of VTScada.

  1. Shut down VTScada on the server you are updating.
  2. Run the installation program, installing to the existing folder.
  3. Restart VTScada and run your application.
    Confirm that the application runs as expected.
  4. Deploy the changes.
    (Auto-deploy may be switched back on if you are using it.)
  5. Proceed to the next workstation.

  6. If you adjusted your server lists (as per the first caution statement), then after all workstations have been upgraded, restore the server lists to the original.

VTScada 12.1

  • As of release 12.1.42, logging of I/O tags has changed as follows: Values will be logged on interval OR on change but not both. If both are needed, create a second (free) I/O tag using an expression that watches the value of the first tag. Log the first on interval and the second on change. Attempting to do both on the same tag introduces a small but important risk of values being recorded out of sequence if the remote device is sending timestamped data and its clock is not synchronized with the server.

  • The "V12 Training Simulator.ChangeSet" application is not compatible with version 12.1.
    Do not use. Delete all copies.
    The "V12.1 Training Simulator.snapshot" application should be used in its place.
    You are advised to replace this application with the newest snapshot after each upgrade.

  • The DNP3 driver has been updated to default to event-based scanning for addresses without a suffix. Refer to notes in

  • (12.1.30) The ThinClient/Server Setup dialog has been redesigned to separate servers and connection addresses. When upgrading, the default address list and associated connection parameters will be populated automatically from the existing server list and connection parameters. Existing VICServerList variables or subroutines at OEM or application layer are still supported. Those will be used preferentially over any coming from the new GUI.
    The ManualVICServerLists option is no longer supported.

  • If an alarm is unacknowledged before being shelved then it will still be unacknowledged when no longer shelved, even if it normalized while shelved.
    This was changed to be consistent with the behavior when disabling / re-enabling or suppressing / unsuppressing an alarm.

  • The Setup.INI property, ThinClientFraming, restricts sites that may place a thin client within an iframe. Reasons to do this include mitigating possible UI redress attacks (clickjackingClosed An attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page). The default value of 'none' may affect customers who were relying on exactly that behavior.

  • Nested expressions are now limited to 200 levels by MaxNestedExpressionDepth. IfElse expressions with more than 200 cases will not run. (12.1.15)

  • UTF-8 Byte Order Mark (BOM) now added to CSV output (12.1.07)

    CSV output files created from the Reports page and Historical Data Viewer now include a three-character BOM at the beginning of the file to ensure correct display in Microsoft Excel. This may interfere with some third-part programs, which will need to be modified to account for the additional characters at the beginning of the file.

  • Shared Security (Security Provider selection) is flagged as a deprecated feature and will be removed in a future version of VTScada. Windows Security Integration is suggested as an alternative.

  • All analog tags are subject to a new filter on I/O drivers, designed to prevent system noise from slowing your system. This defaults to 1/10 of one percent of the scaled range. Review DefaultDriverDeadbandFractionOfFullScale

  • Drivers other than those in the following list cannot share a port with the updated Modbus driver:
    Enron Modbus, Delta Driver, Bristol Driver in BSAP mode.

  • The WksStatus function can report values greater than 100% for percentage counters such as "\\@\Process(VTS)\% Processor Time" when (for example) a total of more than one CPU core is being used by the process.

  • In VTScada 12.1 the VTScada Internet Client can be launched from any browser. Customers who have a branding arrangement with Trihedral and wish to hide the VTScada Internet Client from the list of connection options should refer to branding page for additional options. In particular, look for the new option, showDisplayVIC.

  • The POC-Weatherford and POC-Unico pump-off controller tags from the Oil & Gas Solutions contained a large number of unused disabled alarms. These alarms have been removed (decommissioned) in 12.1. If you had enabled any of these alarms in order to make use of them, you will need to add (commission) these alarms again by setting the alarm priority to an appropriate value. Otherwise these alarms will never activate.

  • The VTSCPU address from the Workstation Status tag will report 100% when all logical processors are being used their fullest by VTScada. In previous versions, VTSCPU was capped at 1 divided by the number of logical processors.

  • The CIP/ENIP driver has been replaced by the Rockwell driver. All legacy CIP/ENIP tags will be converted automatically.

  • The VTSIO driver is no longer included in the installation file. It will continue to exist in legacy installations that are being upgraded. This affects the following functions, all of which relied on the VTSIO driver and therefore should not be used in new code: Beep, CopyIn, CopyOut, In, InWord, MemIn, MemOut, Out, OutWord.

  • The Parameter View security privilege has been renamed to Tag Parameter View.

  • To update a Roster contact list without the full Tag Modify privilege, you must have the Edit Roster Contacts privilege.
    Legacy applications used the Manual Data or Tag Parameter View privilege. Accounts with those privileges will be granted the Edit Roster Contacts privilege on upgrade. The older privileges will no longer serve to modify the roster.

  • The RosterDelay property no longer sets a delay between contacts in a Roster. Delays are now set explicitly within each Roster's contact list and the RosterDelay property now serves only to provide a default value when defining delay rules.

  • The upgrade process will modify the version log if a workstation was renamed after your application was installed on it. (i.e. the application was installed on a legacy version of VTScada, the machine was later renamed, and now you are upgrading to 12.1)
    What you will see in the application's Version Log will differ as follows: There will be a new entry in the Workstations list for the renamed workstation. The old application history will still be available, but it will be listed under the name the workstation had when the application was first run on it.
    More importantly, if the workstation was on a local branch at the time of the upgrade, then the upgrade process will cause an automatic switch to the most recent deployed revision, discarding the local changes. Those changes will still be available in the version log under the old workstation name, so they can still be merged into the local workstation if needed. If the renamed machine does not have any local changes, then the configuration on the local machine will not change, other than the workstation name, as noted.

  • If upgrading a machine that has local changes and if you suspect that the machine may have been renamed, then examine the version log before running their application. Merge in the local changes listed under the old workstation name, if any.

  • If using OAuth 2.0 ensure that all servers are using 12.1 or 12.0. OAuth tokens will not be handled properly if your servers run a mix of these two versions.

VTScada 12.0

  • 12.0.42 - If an Historian tag was using a machine-specific expression for the Storage Name parameter, the uptime data would only be available for the local machine. This could present an incomplete view of the overall system uptime. In this release, a parameter was added to HistorianConnect that is always set to the Historian tag’s unique ID to avoid this problem. A side effect is a loss of access to uptime data for customers who were using a workstation-specific expression in the “Storage Name” setting of the historian tag.
  • 12.0.38 - The AutoLogon property no longer exists. Those relying on that property for kiosk installations should use more secure method as described in Securing a VTScada Thin Client Server
  • 12.0.29 and all later versions - If upgrading directly from a version of VTS prior to 10.1.03, any users with a password containing either 31 or 32 characters will NOT be able to sign in and will require a manual password reset by a manager.
  • 12.0.22 - Localhost addresses are no longer permitted in the Thin Client Server configuration dialog.
  • 12.0.20 - TCP and UDP ports with neither address nor port number will now do nothing. This differs from the previous behavior where the port would automatically become a listener on a default port.
    TCP and UDP ports that were using the default port numbers (3001 for TCP and 3123 for UDP) will no longer use these port numbers automatically and will no longer function as a listener or a client. To resolve this, they will need to be edited to use these port numbers explicitly.
  • The VTSIO driver continues to be included with VTScada, but is no longer installed. On older systems, this provided support for direct I/O and hardware such as the PC speaker. On modern systems .DLLs are used to access hardware interfaces.
    In the event that you do need the VTSIO driver, you can install it using the following command, using an elevated prompt. Replace the paths as needed for your installation folder. Use an absolute path to the install log and ensure that it is in a writable location.
path\to\VTSIOUpdate.exe -i <path\to\VTSIO.inf> -f <path\to\install log>
  • Support for Windows Vista has ended. Do not attempt to run VTScada on that operating system.
  • For your security, Windows DDE is disabled by default. Sites that make use of this technology may choose to enable the feature. Do so by starting VTScada with the command line switch, /D
  • Historian records now contain an addition field to track edited historical data. If you roll back or synchronize with an older version, you may lose access to the history that was generated by the new server. It is recommended that you update the primary historian last.
  • If creating an AlarmConfiguration structure, which is done by calling GetAlarmConfiguration, note that the Custom field may no longer contain a dictionary.
  • In the redesigned security dialogs, "security realm" replaces "user group". Realm sign-ins can now be enabled using dialogs rather than editing properties.
  • Security rules can no longer be applied to (or, for legacy applications, removed from) roles.
    If your legacy application contains roles, to which rules have been applied, you must remove those rules before moving to the current version. After updating, existing rules will still apply to the roles, but you will have no means of editing those rules.
    Security rules can now be applied only to privileges, gathering those together into appropriately named roles.
  • To avoid breaking any existing ODBC or SOAP interfaces to VTScada data, the new security privilege, "Remote Data Access" is automatically granted to existing accounts. You may wish to remove this privilege from some accounts.
  • As of 12.0, VTScada supports Unicode, UTF-8. Any displayed text that contains special characters (byte values above 127) will be converted to Unicode (UTF-8). The vast majority of installations do not use special characters, therefore there will be no change. Of the sites that do, the most common special character is a degree symbol in a description or engineering unit field. ( °C ).
  • All text in the VTScada user interface (including your tag descriptions, areas, page names, etc.) is stored as phrases in the default language file (<application folder>\Languages\EN.CSV) where each is given a unique identifier. Use the tools provided in the Application Configuration dialog to change this file if needed. Do not edit the file directly.
  • You will not notice any difference while working within VTScada, but those who work with source code will now see the phrase identifier key instead of the text. For example, the title of a new page if viewed in source code, will be similar to:
    Title = "De7DTnP";
    Operators will see the assigned title and never the phrase identifier key.
  • Expressions that refer to text parameters of tags or application properties will be updated for you. For example:
Concat(..\Area, " ", ..\Description),  " position control")

becomes

Concat(..\Area, " ", PickValid(\GetPhrase(..\Description), ..\Description),  " position control")

Note that in this example, " position control" remains English text. If you intend to make your application available in other languages you must create a phrase for those words and substitute the phrase key, or a parameterized phrase (\ParmPhrase).

  • New expressions that refer to text parameters of tags must use \GetPhrase(key). See Multilingual Expressions.
  • Labels and other text that were stored in application properties are now stored in the language file. This includes commonly-used properties such as AlarmDialerTemplate, DialerLocation, AlarmEmailTemplate and others. It is possible (but discouraged) to use these application properties rather than the language file in uni-lingual applications, but to do so, you must now insert them rather than search for the OEM-layer instance to copy and modify.
  • When running a legacy application in 12.0 or later, tag parameters that store text (description, engineering units, etc.) are updated to use phrases. For child tags of user-defined types, these fields will be shaded orange when viewed in the properties dialog, but the tag is not considered to have overrides unless you close the dialog by pressing OK.
  • Anyone who has used the VTScada scripting language to write a custom tag is advised to update their code to use the new phrase functions.
  • When writing VTScada script code, make sure that the text (typically special symbols or non-Latin scripts) are entered in UTF-8. Many editors will allow you to specify that the file be saved in UTF-8 but may default to a different standard.
  • Ensure that your files do not include a byte-order-mark (BOM).
  • All variables names in VTScada script code must continue to use ASCII-standard characters.
  • Any function displaying or accepting text input assumes UTF-8. Functions that work with sub-strings remain unchanged and continue to count bytes, not characters.
  • Displayed text will compress horizontally by up to 35% before being clipped.
  • If you roll back to a pre-12.0 version of VTScada, you will need to re-enter all text. (Or, use the repository to roll back to a version before the 12.0 upgrade.)
  • It may happen that encryption keys and special strings are improperly converted when an application is first imported to 12.0.
  • Code that uses MatchKeys to watch for particular symbols should continue to work but should be tested. (Note that under Unicode, there can be more than one encoding for some characters and symbols.)
  • UTF-8 will allow text to display correctly in non-Latin scripts, but may cause problems if you roll back to an earlier version of VTScada.
  • If you need to roll back to an earlier version, use the version control system to revert the repository changes that were made automatically as a result of upgrading.
  • The VTScada Internet Client (VIC) is not compatible across versions before and after 11.5 / 12.0. If connecting to an 11.5 / 12.0 server, you must use the 11.5 / 12.0 client. If using the 11.3 or earlier server, you must use a pre-11.5 client.
    Clients will function, but symbols and certain characters will not display properly.
  • The [Labels] section of configuration files will become a hidden <Labels> section. Do not work with labels in this section as your edits will be ignored. All labels are now stored as phrases in the default language file.
  • SlippyMapRemoteTileSource1 is no longer a property in the System section of Setup.INI. It is now a section in its own right, containing a set of properties that define the tile source. [SlippyMapRemoteTileSourceN] Section

VTScada 11.3

  • WatchForTagChanges is now marked as deprecated. Use WatchTags in new code.
  • The Profiler is now integrated into the Source Debugger. Users who are upgrading from earlier versions of VTScada are advised to delete the stand-alone Profiler application from their VAM.
  • Version 11.3 introduced support for IPv6. Note the following changes:
    • Network Status tags should be reconfigured to refer to Network Adapter Names instead of Machine IP values.
    • The variable, WkStnIPList, is deprecated but maintained for backward compatibility. It contains only IPv4 addresses.
    • BinIP2Text and TextIP2Bin are deprecated but maintained for backward compatibility. Do not use in new code.
    • TCPIPReset is deprecated and non-functional.
    • Two new options have been added to SocketAttribs for use with UDP datagrams.
  • Version 11.3 introduced support for IPv6. Note the following changes:
    • Network Status tags should be reconfigured to refer to Network Adapter Names instead of Machine IP values.
    • The variable, WkStnIPList, is deprecated but maintained for backward compatibility. It contains only IPv4 addresses.
    • BinIP2Text and TextIP2Bin are deprecated but maintained for backward compatibility. Do not use in new code.
    • TCPIPReset is deprecated and non-functional.
    • Two new options have been added to SocketAttribs for use with UDP datagrams.

VTScada 11.2

  • Activation is now required for all versions of VTScada.
  • Any declarations of TRUE or FALSE as constants in custom code must be removed.
  • Version 11.2.22 improved the performance of network values. All custom application code that makes use of network values should be tested to ensure its correct operation with the new service.
    In particular, the network values service formerly set its "Started" flag after the PC became either a server or a client, at which time a tag could call the Register() function, after which all of its variables setup as network values would be set to match the server’s values. This is no longer the case as the Started flag is now set after the service running with no guarantee that values are setup to match the server’s values. If you custom code requires this still then you may need to monitor the RPCStatus value of the service to ensure synchronization
  • VTScada logo images are now protected by a checksum. VTScada will not start if these files have been removed or modified. If you wish to create a custom-branded application, contact Trihedral Engineering for licensing.
  • The updated SHA-256 signing certificate used for Trihedral drivers will be recognized by older Windows® operating systems, but they will not be able to save your response to the "Always trust content from Trihedral?" prompt. The question will be repeated during each installation.
    This is a known problem with Windows 7 and Windows Server 2008 workstations. A hotfix is available from Microsoft at: https://support.microsoft.com/en-us/kb/2921916
  • The IVONA voice engine is no longer supplied with VTScada. Customers who have this engine from earlier releases may continue to use it with version 11.2 and beyond. Your license will not expire.
  • Wide Area Protocol (WAP) support has been removed from VTScada.
  • CIP driver addressing has changed. All I/O tags with the older style, which used formatted bit addresses, must be manually reconfigured to use the new format. This is a one time only process.

Old system:

  1. Array Tags Of INT or DINT -> TagName[n][b]
  2. Array tags of BOOL -> TagName.n
  3. Simple tags of INT & DINT -> TagName[b]/BIT

New system

  1. Array Tags Of INT or DINT -> TagName[n].b
  2. Array tags of BOOL -> TagName[n]
  3. Simple tags of INT & DINT -> TagName.b

  • Widgets that are invisible (Opacity == 0) no longer start. Some applications may have used invisible widgets to control the trend view that would open in response to a click in a certain area. That technique will no longer work. You can work around this by changing the opacity to an extremely small, but non-zero value for widgets that you do not want to see, but do want to continue to respond in the user-interface.
  • The following punctuation characters are now defined in the speech lexicon to be pronounced as if they were a space character. (That is, treated as a break between words.) Users may define alternate pronunciations, if desired.
    _ @ # $ % + = < > & / \ * ; |
  • Fonts with a weight less than four (4) will be extremely faint on an Anywhere client. Fonts with a weight greater than seven will extremely dark. If using font weights less than four or greater than seven, you may need to adjust these for use with the Anywhere client.
  • The Alarm Manager module, SetShelved, has a new parameter list. All legacy code that used this function must be updated before being used in 11.2
  • Special handling for orange 241 and transparent black is no longer supported for .PNG format files. These colors will work as they always have for .BMP files.
  • The "." character now serves as the equivalent of Scope( , , TRUE). Thus, Obj.Value is equivalent to Scope(Obj, "Value", TRUE).
    Note the following:
    • When writing expressions, the "." character should now be used instead of the backslash operator when the intent is to reference a value that should be in the referenced scope.
    • In earlier versions of VTScada, the "." character was legal within variable names. (No longer true.)
    • To avoid problems that would occur if a legacy application with the "." character in variable names was loaded into version 11.2, the property declaration "LocalScopeSyntax = 0" will be added to Settings.Startup when those legacy applications are added to an 11.2 installation. This will prevent the "." character acting as a local scope operator in those applications.
    • If you are certain that your legacy application does not contain variable names that include the "." character, you may set LocalScopeSyntax to 1 to make use of the "." character as a scope operator in new code.
  • The AlarmManager server list is no longer used in 11.2. You should now use the SystemAlarmHistorian server list in its place.
  • When you first start your legacy application in 11.2, VTScada will copy the "Default for Workstation" section of the AlarmManager server list into the server list of SystemAlarmHistorian. It does not copy the workstation-specific settings because they will probably not apply within the new paradigm. It is not necessary to have workstation-specific lists of servers now that Historian client-storage is enabled in the System Alarm Historian tag.
  • For custom tags, the use of GetAlarmObjVal is now obsolete, as is the requirement to place multiple built-in alarms into their own submodules of the tag structure.
  • Any overrides of Alarm Manager modules may continue to work, but should be tested thoroughly. As of version 11.2, the technique of overriding an Alarm Manager module to add extra functionality has been deprecated in favor of custom hooks.
  • Several Alarm Manager functions are deprecated in favor of new functions and work-methods. Refer to the following in the VTScada Programmer's Guide and Function Reference:
  • Any custom code that is using "AlarmManager" as an RPC service name will no longer work. The AlarmManager no longer has its own service. This code should be updated to use "SystemAlarmHistorian" as the service name.
  • For the sake of backward compatibility, \AlarmManager\ThisService remains but is now set equal to "SystemAlarmHistorian". Similarly, \AlarmManager\RPCStatus is now a pointer to the SystemAlarmHistorian’s RPCStatus.

Alarm History Conversion:

The alarm and event history of your existing application must be converted to use the new alarms database, introduced with version 11.2. Before starting the process, consider the following:

  • The conversion must be run on an Alarm Manager Server.
    • If your application has not been configured with a server list for primary and backup servers, then you can and should run the process on the current workstation.
    • If your application does have primary and backup servers (and, possibly workstations that are not on the server list) then ensure that you are working on an Alarm Manager server.
    • You do not need to run the process on the current primary server, except that the primary server might have a more up-to-date list of alarms.
    • It is not a good idea to change the server list just before running the conversion as VTScada may take a few moments to transfer all records from the old primary to the new one.
    • To be sure of the server configuration, you may leave the conversion dialog open while you open the Application Properties dialog and review the information in the page, Edit Server Lists.
  • Does your application require more AlarmDatabase tags?

Alarm and event history is now stored using the VTScada Historian. In part, AlarmDatabase tags link alarms to Historian tags. There are two main reasons why you might consider adding more:

  • Security in applications that use Realm Filtering. If your alarms are linked to separate databases, Realm Filtering can be applied to the database tags. Operators will be able to see only alarms in databases that they are permitted to see. This is not a requirement for Realm Filtering, merely a possible convenience. Realm Filtering rules still apply based on each tag's area or tag hierarchy.
  • Efficiency in very large applications. The fewer alarms there are in a database, the faster the Alarm Page will load those alarms. This also results in smaller history sets, which means synchronizing and filtering will be faster.

If either of the above is true, then it is possible (but not necessary) that you may want extra Alarm Database tags. If neither is true, then do not add extra Alarm Database tags.

If adding new Alarm Database tags, note that the only method for linking alarms to databases is to make the alarm tag (or status tag containing an alarm) a child of the Alarm Database tag.

The Alarm DrawList widget is obsolete. Any custom code that used this widget must be replaced with the replacement Alarm List. The Alarm List can be extensively customized through code.

Obsolete Alarm Manager Variables

The following publicly-accessible variables within the Alarm Manager became obsolete as of VTScada version 11.2

General

DBSysVal 

The current alarm database. This can be used to obtain information from the database using DBListGet and DBListSize.

CurrentServer 

 A text name indicating the workstation acting as the Alarm Manager server.
RPCStatus 

The current RPC connection status. A value returned by the RPC Manager's Register subroutine.
Remote 

Set to true when the alarm source is from a remote workstation. This workstation is not the Server.
BitmapDatabase 

The object pointer to the Bitmap Database. This is where preloaded images are stored. (For more details, see the "Bitmap" keyword description above.)
ListChange 

Value changes or can be changed to indicate a change in the database. It should be set to any valid value that is different from the current value.

AckAll 

When set to a non-zero value, all unacknowledged alarms are acknowledged. AckAll is reset to zero after this takes place.
AckFilter

 If set to a valid field filter, all alarms meeting the filter condition will be acknowledged. AckFilter is reset to invalid after this takes place.

Alarm Sounds

Silence  When true, alarm sound is turned off for the alarm generating a sound.
SoundPriority  The priority of the alarm generating a sound.
SoundAlarm  The object value of the alarm generating a sound.
Cycles  The number of cycles for which to play tones (< 0 means continuous).

Record Configuration

FieldCount  The number of fields in the alarm.
FieldNames  The names of the fields.
FieldSizes  The field sizes as defined for the Alarm Manager's database.

Filter Dialog Configuration

FilterCount  The number of filters in the filter dialog
FilterName  The text names for the filters
FilterIndex  The field indices for the filters

VTScada 11.1

  • For custom drivers, note that CoalesceRPC is obsolete and has been removed. DriverRPCOptimization should be used instead.
  • If you are using LogNTEvent in custom code, and have been using "VTS" as the third parameter, you should revise this to use "VTScada" instead.
  • If your application has an OEM layer that is marked, "Do not start", the upgrade process will hang. To avoid this problem, do the following:
    • Temporarily allow the OEM layer to be started, then start your application. This enables both the application and the OEM layer to be upgraded.
      After the upgrade you may restore the Do not start property of the OEM layer.

Alternatively, you could skip the upgrade of the OEM layer by manually marking the OEM layer as having been upgraded. Do this by adding the property, "MenuItemsAutoGenerated = 1" to the Application section of Settings.Dynamic. Note that one consequence of not upgrading the OEM layer is that custom images and widgets in that layer will not appear in the palette unless added manually at a later time.

  • The ModifyBitmap function now uses a second bit in the Antialias parameter. Bit 1 controls whether feathering should be applied to stretched images that are also anti-aliased (bit 0 set to TRUE). You may need to set this parameter value to "3" when using ModifyBitmap to keep certain images from bleeding outside their bounding boxes.
  • Improvements to the code underlying the Alarm Notification System have the following repercussions:
    • If your VTScada network includes workstations running versions prior to 11.1 and workstations running version 11.1 or later, then changes to the active roster will not be synchronized across that version divide.
    • If there is no Default area roster, alarms that do not have matching rosters will no longer call out using a randomly selected roster.
    • Support for the area, "GeneralAlarm", has been removed.
  • Operator notes are transferred automatically to the new Operator Notes tag.
  • If using the ODBC interface to perform SQL queries on VTScada data, note that new table structures with UTC timestamps are now available. Legacy tables still exist but are hidden by default using the property, SQLQueryHideLegacyTables.
  • Custom modules for exporting tag data now require the parameter, DataMode, to be added after the TimePerPoint parameter.
  • Calculation tags now have a built-in link to Historian tags. If your legacy system used Logger tags to record the value of Calculation tags, those loggers will still be present, even though the Calculation's configuration panel no longer shows them. Do not attach an Historian to a Calculation tag that is already being logged by a Logger tag.
  • New calculation tags will have logging enabled by default. Existing calculation tags that were not previously logged will continue to not be logged until you decide to attach an Historian.

VTScada 11

  • If you are running Microsoft Vista, and no text appears in the VAM, ensure that you have installed the platform update. See: https://msdn.microsoft.com/en-us/library/windows/desktop/ee663867(v=vs.85).aspx
  • Windows XP™ is no longer supported. Version 11 requires features that are available only in more modern operating systems.
  • The VTScada layer has been fully merged into the standard layer.
    The legacy VTScada layer still exists as a hidden layer, and will be used by legacy VTScada-based applications that are being updated to release 11. One widget (Duplexes) and one font (Notes) have not been merged into the standard layer, but can be found in the legacy layer if required.
  • If you have an OEM layer, and if that layer has custom widgets (formerly called "drawing methods"), then you must run the OEM layer once in version 11 before running applications that use it. This will happen automatically, even if the OEM layer is flagged as "never run."
    This is required to allow VTScada 11 to create menu item tags for the widgets, thus making them available within the palette.
    The OEM layer should not be left running. When started automatically, it will also be stopped automatically.
  • The Call-Out List Page is no longer included. Any page, of your own creation, may be used in its place. Legacy applications that have the Call-Out List page will continue to have that page when imported into VTScada 11.
  • Many legacy images have been dropped from the palette in favor of modern images. The original image files are still included for the sake of backward compatibility.
  • The Mobile Browser interface has several improvements, including the ability to show page graphics. With this new functionality, the mobile client is now licensed as being equivalent to a Internet Client (VIC) connection.
    Customers who need to limit page graphics to conserve bandwidth or server CPU may set the application property, MobileBrowserDisablePageGraphics.
    Existing customers who wish to continue using the older, limited mobile interface and its matching license calculation should contact Trihedral's Technical Support for relevant information.
  • The Thin Client Monitor log is now stored in the file VICMonitorLog.txt, located in the installation folder instead of Log.txt located in the BrowserMon folder.
  • Hand-coded, custom widgets may not look or work correctly until they have been opened in the Idea Studio.
    Click the widget's Set Parameters button, within its Menu Item tag's configuration folder, then click OK.
    The recommended method for defaulting the parameters of a custom-coded widget is to add default values to the parameters in the widget's .SRC code. For example:
(
   MyParm = 100;
   AnotherParm = "Default Text";
)

Alternatively, a GetParmDefaults subroutine could be added to the widget, which will return an array of parameter defaults. An example follows:

<
{======================= CommandButton\GetParmDefaults =======================}
{ Called to determine the default initial parameters for this widget. }
{ Note - this module gets launched with Code as its parent object.            }
{=============================================================================}
GetParmDefaults
[
  PROTECTED ParmDefaults      { Array of parameter defaults to return         };
]
Main [
  If 1;
  [
    { Get the parameter defaults that are used for existing (underspecified) widgets that lack some parameters. }
    ParmDefaults = ListVars(ParentModule(Self()), "*", 0, 0xFFFF, 0b100 {parms}, 0, FALSE, 2 {defaults},   FALSE);
    { Fill in parameter values to be used with new widgets if they differ from the defaults for existing widgets. }
    ParmDefaults[#UseLegacyButtonStyle] = FALSE;
    Return(ParmDefaults);
  ]
]
{ End of CommandButton\GetParmDefaults }
>
  • Pipes are no longer drawn as a separate function (GUIPipe). A variant of the Line (GUIPolygon) command is used instead. Pipes in legacy applications will be converted automatically when either their color or their width is changed. Legacy pipes are not converted upon import, or when moved or re-aligned.
  • The lexicon file, Lexicon.vlx, will not be copied from your older installation during the upgrade process. If you are installing to a new folder, and you have made changes to your lexicon that you want to keep, you must copy the file Lexicon.vlx from the old installation to the new.
  • Four font files will be installed with VTScada, for use by widgets and built-in text styles. Review labels and titles in your application pages for scaling and alignment issues after upgrading to version 11.
    The new fonts are:
    • Open-Sans
    • Sansation
    • Crystal
    • Register
  • The Gradient Color Change is deprecated. This was used to make pipes change color according to pump or valve state, but GUIPipes are no longer created.
    To replace this feature, link the color property of the pipe (or any other object) to an expression that monitors the value of the tag that was monitored by the gradient color change. For example, given a digital status tag, "Motor1_Status" and a color that should be green when on, red when off, the expression would be: [<Motor1_Status>] ? "<FF00FF00>" : "<FFFF0000>"
  • The \Editing flag is no longer used.
    The flag has been replaced by ParentWindow(Self)\Editing. All scripts that used the former version must be updated.
  • Because the toolbox has been replaced by ribbons, custom toolbox buttons are no longer available.
  • The F11 / F12 key now opens the FindPage dialog in all applications.
  • Custom driver code that used the group name, "VTScadaDriver" must now use the group name "LiftstationDrivers".
  • Changes to default property values:
    • AnswerCalls - Now defaults to TRUE.
    • AlarmLogFreq - Now defaults to monthly.
    • OperatorNotesSecurity - Defaults to none.
    • SiteRetries - Defaults to 3.
    • ModemManagerLogSize - Defaults to 1000.
    • AlarmEventDesc labels - Default labels are those used by VTScada rather than VTScada prior to version 11.
  • The following properties are obsolete:
    • AlarmEventDescX
    • AlarmRevUnack
    • AlarmStateDesc0 through Alarm StateDesc5
    • AlmColumn1 through AlmColumn7
    • AlmDBArea
    • AlmDBHPUnits
    • AlmDBHPValue
    • AlmDBMessage
    • AlmDBPointName
    • AlmDBPriority
    • AlmDBTimeStamp
    • AlmDBStatus
    • AlmDBType
    • AlmHdg1 through AlmHdg7
    • AlmPgLineStyle
    • AlmTagsOnly
    • ClientAlarmSoundOn
    • Cycles
    • DataFlowModuleName
    • HTTPWAPport
    • ReportXPos
    • ReportYPos
    • ReportXSize
    • ReportYSize
    • TrendDuration

VTS 10.2

  • PEditField() is no longer supported for tag Name parameter editing and PEditName() should be used instead. Custom tag configuration dialogs created prior to this version should be updated accordingly. If not, the OK and the Apply buttons will be disabled.
  • The ability to rename tags has the following side-effect: The character "]" is no longer legal in a tag name.  Existing tags that used this character will display using their immutable name rather than the short name.  You can mitigate this by changing TagNameDelimiter in Setup.INI to use an alternative character. ">" is recommended. Short names will then have the form [ShortName> rather than [ShortName]
  • GetSystemColor() and option 10 of VStatus() now return an RGB color string instead of a palette number. Custom code that uses this value as a number will need to be updated to use text instead. Code that simply passes the value to other VTS functions will continue to work.
  • The following functions have been removed. Code using them will still compile, but the functions will do nothing.
    • AnimateState
    • CollapseTree
    • DragState
    • HighlightedModule
    • HighlightState
    • HighlightTree
    • LastSelectedModule
    • LastSelectedState
    • ModuleCollapsed
    • Moduletree
    • ModuleTreeSize
    • MoveSelState
    • MoveSibling
    • MoveState
    • Palette
    • PickModule
    • PickState
    • ReadNum
    • ReadText
    • SelectStates
    • SetStateColor
    • ShadowTree
    • StateDiagram
    • StateHighlighted

VTS 10.1

  • All users will be required to change their password upon first signing in. This is done to ensure that their credentials are stored using the newer encryption algorithm. Note that passwords are now case-sensitive.
  • Tag names may not conflict with VTS function names.  When starting an older application in version 10.1, any tags with conflicting names will fail to start and will be listed in an error message. If this occurs, your recourse depends on which version of VTS you are upgrading from. Please contact Trihedral technical support.
  • Now that VTS includes Constructor and Destructor modules, any pre-existing modules that use those names should be re-named. Also, any code that uses the DBTrace Constructor API should be updated.
  • Alternate identification has been decoupled from user-passwords and is now a distinct property that may be assigned to designated users.
  • Tags in an OEM layer will now start in the dependent layer.  You may draw and otherwise use the tags in the dependent layer, and may override tag parameters.  If you would prefer that new applications based on your OEM layer have independent copies of tags from that layer, continue to use a Template.ChangeSet.
  • Tags that you or a developer have created using VTS script code must contain a refresh module and that module must be called.
  • In custom-coded tags, the statement, Root = Self() must occur before the call to Refresh().
  • Also in custom-coded tags, the expression "Scope(VTSDB, TagName) will still work if the custom tags are used in the same way that they had been. But, if you wish to use those tags in parent-child tag structures, include parameters that refer to tags that are not root-level tags, and wish to copy your tag to a new scope, then you must change the expression to read "Scope(Root, TagName)".
  • Page links, listed in the bottom navigation bar, will not be preserved when your application is upgraded to release 10.1
  • With the release of version 10.1.06, the IVONA™ Salli voice (American English) replaces the IVONA Amy voice (British English).  Customers who prefer the Amy voice may contact technical support for the required files.
  • Because tag names now reflect the tag's position in a parent-child structure, full alarm names may become long. This is reflected in the change of AlarmKeySize to 256. The template alarm message length has been increased from 80 to 128 characters. Changes to the Alarm Manager are as follows. Note that, should you choose to set your own values for any of these applications properties, you should do so only after the application has been updated to version 10.1.
    You will need to edit your Settings.Startup file for existing applications.  For the change to take effect, the alarm manager (or, more simply, the entire application) must be re-started after you have made the edits.
  • AlarmKeySize setting has been increased from 32 (and 64) to 256 in the VTS/VTScada templates.
  • The template alarm message length has been increased from 80 to 128 characters.
  • DBSystem can now re-size existing DB and LOG files when the Max Key or Text field sizes are changed.
  • The AlarmManager can synchronize between servers with different values for AlarmKeySize or message size or both. In earlier versions of VTScada, these applications would fail to synchronize properly.
  • Existing applications can modify the AlarmKeySize or alarm message size or both with only a restart required. This should always work when increasing the size(s), but might fail if attempting to decrease them should existing fields fail to fit in the decreased space.
  • Code that called HideWAM must be changed to call the newer HideVAM instead. HideWAM is maintained for backward compatibility but is now used only at startup, to set the initial value of HideVAM.
  • The use of the variable UserSession in a module to affect GetUserSession's behavior is no longer supported

VTS 10

  • No more Config.INI, SecurityManager.INI, workstation.INI, etc.

Configuration variables are now stored in Settings.Startup (loaded only on application start) and Settings.Dynamic (able to be reloaded while an application is running). Also note that the term "configuration variables" has been dropped in favor of "application properties".

  • User files are separate from working files.

The files located in an application's root directory and in the Pages directory are "user files". Developers may edit these files, but need to be aware that they must explicitly tell VTS to import the changed files before their edits become part of the working set.

Working files are under version control and are stored in a hidden system folder within the application directory. Any attempt to directly edit a working file will damage your application.

  • Points.MDB is obsolete

Developers can export their tags to a Microsoft Access™ (or other) database, or to Excel™ for offline editing, and may import a tag database into an application. Within a working application, tag instances are now stored in a proprietary database format.

  • In a networked application, all workstations must be running VTS 10. Remote configuration will not function across different versions.
  • The LogManager service is obsolete

Log storage is now handled by Historian tags. These powerful tags allow you to optimize data logging for load balancing and automatic fail-over, even between multiple database storage systems such as Oracle™ and MsSQL Server™.

By default, Trihedral's own proprietary database format will be used for logging. Older applications upgraded to version 10 will automatically be assigned to a default Historian tag.

  • Access to legacy tag history.

Data logging in VTS 10 is far more flexible and powerful than ever before. Because of fundamental changes to the way that logged data is stored, you must configure the application property, LegacyHistoryPath, to point to data logged while the application was running on an earlier version of VTScada.

  • Application template directories are obsolete.

Template information is now stored within specialized ChangeSet files.

  • Changes to the RateOfChange tag.

If you are using these tags, note that they must now reference a Source Tag that is configured for logging.

  • The application property OEMRestrict is no longer supported on the VAM.

For networked applications, note that the RPCManager-Inhibits configuration section is now obsolete.

  • If using the configuration file, RPCService.INI, this file will automatically be converted to the version 10 format, but you may need to re-enter your server lists.
  • There is a Font compatibility issue when the VTS Internet Client (VIC) uses an older version of the Windows™ operating system than the one on the server.

When running VTS 10 as a VTS Internet Server on Windows Vista/7/Server2008, any VICs that are run on Windows XP/Server2003 or older will have many texts clipped. To avoid this, the server must be told to use old fonts by setting UseXPCompatibleFont to 1 in the System section of Setup.INI. If the server is XP/Server2003, the setting is not necessary.

  • Configuration variables from Setup.INI are now read as the lowest priority settings for all applications. They will always be overridden by a matching property in the application's Settings.Startup or Settings.Dynamic.
  • The following script applications are obsolete and are no longer included with VTS:

ResetRemoteClients   DBConvert   ODBCBrowse

VTS Programmers should note the following changes, which may affect their custom code.

  • Config.INI sections have moved to Settings.Startup & Settings.Dynamic.

All application-level configuration files (those with names ending in .INI) have been replaced with the two files, Settings.Startup and Settings.Dynamic. Workstation-specific configuration files have been replaced by Workstation.Startup and Workstation.Dynamic in the WorkstationSettings folder of the application directory. See: Application Properties.

  • StartTag has a new flag which, if set, will update the tag database. By default, this flag is not set. See: StartTag.
  • If you have a custom tag type, ensure that the tag parameter metadata is in place. (This was not required in older versions and may not be present in legacy applications.)  See: Tag Configuration Parameters.
  • The SecurityManager is now in the VAM layer and overrides to it will not take effect for VAM access to security.
  • There is no longer a SecurityManager RPC service. All security accounts and settings are synchronized by the Configuration service.
  • AppRoot.SRC replaces AppMod.SRC & AppMod.Web. The AppMod file in an application that is upgraded to release 10 will not be used, but will be retained for use if the application is converted back to an older version.
  • In 9.1 and earlier, if you included any code for another module in the same source file as the Appmod.SRC, it would be used. Group modules were typically done this way. As of 10.0, the code for other modules must exist in a separate file other than AppRoot.SRC or they will be ignored without warning.
  • PlugIns that use default string values (as shown in the following example) will no longer work.
[ (POINTS)
  MyTag = "VarForGraphicsInMyTag";
]
  • EditLockoutManager functions such as "MarkTagForEdit" are now obsolete. The distributed version control system replaces the Edit Lockout Manager. Any custom code that calls the EditLockoutManager will result in an error dialog.
  • Libraries no longer combine code across layers and now only use the library at the highest defined layer. Widgets that link into libraries are not affected.
  • Web services have a different interface on the script code side. Please see XMLProcessor, and other XML functions for details.
  • ExternalValue is no longer supported in input tags.
  • OEM code references to Logger, LogManager or LogObjVar need to be changed to use the Historian interface. Of special note is any code that waits for LogManager\Started. See: Historian Manager.
  • Modules that are defined outside the scope of the application directory will need to be moved to within the application directory.
  • Security Manager plug-ins only work when the application is running.
  • Plugins that have references to variables in Code must be preceded by Code.
  • Template directories must be converted manually to template ChangeSets. See OEM Template ChangeSet for instructions.
  • DSNName no longer exists as a variable in Code
  • The Security Manager no longer supports OEMEncryptKey and SerEncryptOEM. These have been replaced by integrated higher level encryption.
  • The Notebook tag’s AddNote module interface has changed to support the new Historian.
  • SelectObject and PSelectObject have new parameters, adding new options for your code.
  • SQL module calls no longer allow writing to the default tag database.
  • EditIni and EditIniCheckBox widgets always update the RAM copy and ignore the "Update RAM Copy" parameter.
  • RPCManager\Register no longer supports specifying a file name to read the server list from.
  • RPCService.INI file contents have been transferred to Servers.RPC.
  • ToolExt.INI has been changed to ToolExt.CSV
  • WriteIni will first acquire the working copy lock and update the file asynchronously. Use Layer\RecordProperty instead.
  • ReadIni does not acquire the working copy lock. It is better to use ReadPropertiesFile instead.
  • LogFileName PLUGIN no longer supported.
  • LogAlarm PLUGIN no longer supported.
  • Files with the extensions of .DAT and .LOG that are accessed from custom code need to be moved to the DataPath directory and code modified to match.
  • The default window title will now be the application name rather than "Display".
  • Points.MDB is no longer the primary tag database.
  • The RPC manager now uses the VTS IANA registered port, 5780 instead of 1160.
  • The application property LegacyHistoryPath is required to access older data from upgraded legacy applications.
  • The RPCManager-Inhibits configuration file section is no more.
  • VTS Internet Servers on Vista with clients running XP will need to set the Tahoma font in their Setup.INI files.
  • OEMRestrict is no longer supported on the VAM.
  • Tag names that consist of only the period and space characters will no longer be considered valid.
  • RPCService.INI files will not be converted to the version 10 format automatically. Server lists may need to be re-entered.
  • Setup.INI variables are now read as the lowest priority settings for all applications.
  • The script applications, ResetRemoteClients, DBConvert and ODBCBrowse no longer exist.
  • After updating a legacy application to release 10 and compiling, a full re-compile under the previous version will be required to roll back to that version.
  • Unless AutomaticDeploy is added to the Layer section of Config.INI prior to conversion, all local changes will be deployed automatically when the application is converted to version 10.
  • Existing applications that use VTS as a DDE server and rely on the application window being called "Display" will need one of the following:
    a) Declare DisplayManagerTitle = Display in Settings.Dynamic
    b) Update the links to refer to the application name.
  • VTScada's ODBC interface was modified to use ODBC3.0 drivers, which may cause changes in returned data types and SQLState return codes.
  • Changes to the ODBCStatus function to take the ODBC handle to query for status. This is important to note as otherwise, you will just get the status of the last operation to complete which, given the concurrent nature, might not be the operation you have just executed.
  • The following files are obsolete since the release of VTS version 10.
    •  AlarmManager.INI -> now part of Settings.Dynamic
    • Config.DB
    • Config.INI -> replaced by Settings.Startup and Settings.Dynamic
    • GDI.WIF -> now part of Settings.Dynamic
    • Menu.TXT & Menu2.TXT -> replaced by PageMenu.TXT
    • Points.MDB -> replaced by a proprietary data storage system
    • SCT.MDB - obsolete
    • SecurityManager.INI -> now part of Settings.Dynamic
    • Sync.WIF -> obsolete
    • Workstation.INI -> replaced by Workstation.Dynamic
    • ReportTags.GRP -> replaced by a proprietary data storage system.