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 paid upgrade 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.

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.0

  • 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 50% 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 ActiveX 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 Internet 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

  • 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.