Items from the collective wisdom of the VEE user community.
As of early 2016 word (albeit third-party) from Keysight is that there would be a Windows 10 compatibility release sometime in 2017. As of nearly 2 years later (January 2018) there have been no updates and no participation in the forum or VRF by Keysight VEE developers. While there may still be some small hope for a Windows 10 compatibility release, it is very unlikely that we will see any new features or enhancements from Keysight. Given that, VEE works just fine and Microsoft has said (ca 2015) that Windows 10 is the last Windows version so there's good reason to believe that VEE will function as is for years to come.
HOWEVER, as soon as IOLIB no longer supports 32-bit software, then while VEE itself will be fine with Windows 10, it will no longer be possible to migrate to newer IOLIB versions. When this happens control of newer instruments may become an issue.
<opinion>Fall 2017: While Windows as a
desktop OS is still widely used, it is
also in a shrinking market and is therefore unlikely to see much investment in
the future. VEE will see no development and minimal or no support. It has been a
great 25+ years and not too many tools last that long. Since Keysight will not
be providing a practical replacement for VEE, and will not
turn over the code to the user community, it is probably time to look at other solutions
such as Python.
</opinion>
January 2018: Keysight confirms via VRF and on the Keysight Web: "VEE will not be officially supported on the Windows 10 platform".
<opinion>
January 2018: The worst-case scenario has come to pass. Keysight
will no longer develop or support VEE nor will it release source to the user
community. While existing code will continue to work for a while, it is time to
move to another platform. One slight hope: Keysight (aka HP, Agilent) has in the
past sold application source to outside groups so the precedent exists. Maybe
someone has deep pockets or would like to explore crowd funding for source and
then utilize the user community to migrate to modern platforms. Migration is
quite feasible given that Objective C has become mainstream.
As it turns out there are some other interesting alternatives that work on
many/most modern platforms. Examples include:
When you look closely at math involving real numbers, you may notice that some answers appear to be incorrect. For instance a simple statement like (0.1+0.1+0.1)==0.3 returns FALSE, though on the surface it is of course a TRUE statement. Vee is obviously broken, right? Well no- this is related to the fundamental fact that since all digital computers have finite precision, there are only a given set of real numbers that can be exactly represented. VEE, like most modern programs/programming environments uses IEEE 64-bit (or 32-bit) standard representations of real numbers. All other modern programs that use IEEE Standards show this same behavior unless they take steps to mask it by truncating the answers. This is the correct behavior and it is why the ~= operator is provided. A good explanation of the details is given in a document discussing this same behavior inside of Matlab. Another useful reference by Greg Goebel discusses various aspects of number formats. This dates from the turn of the century but is still quite valid.
The general answer is YES, but there are some definite limitations since various revisions of VEE have added new features and have changed save formats. This means that while many programs will run, anything using the new features will NOT work and would need to be expunged before the program will load and run. A good way to check potential issues is to run your program in compatibility mode with the target version in mind. For instance if you want to run VEE9 code in VEE7, set VEE7 execution mode in your VEE9 development and make sure it runs correctly.
Assuming that the program in question does not contain any features that are incompatible with the targeted older version of VEE, then save the program in ASCII format and edit the program with a plain ASCII text editor. Do NOT use Microsoft Word, or Open Office or any other such editor, but rather use Notepad or vi or a similar ascii editor.
The first few lines of each VEE program look similar. What you
need to do is to make a few changes to these lines as outlined below.
Be VERY CAREFUL when you edit a VEE source file since the syntax is VERY
SENSITIVE. Leave all punctuation exactly as is unless you are completely confident
with your changes.
VEE Program Line | Vee 3(2) | Vee 4 HPUX | Vee 5 HPUX | Vee 6 HPUX | VEE 6 Windows | VEE 7 | VEE 7.51 | VEE 8.0 | VEE 9.0 | VEE 9.2 | VEE 9.32 | VEE 9.33 |
(saveFormat "2.3") | 1.2 | 2.3 | 2.3 | 2.3 | 2.3 | 7.0 | 7.0 | 7.0 | 7.0 | 7.0 | 7.0 | 7.0 |
(date "Fri 29/Jul/2005 07:26:59 PDT") | same for all | |||||||||||
(veerev "6.0") | not used | 4.0 | 5.0 | 6.0 | 6.01 | 7.01.6721.0 | 7.5.7714.0 | 8.0.9625.0 | 9.0.11705.0 | 9.2.13522.0 | 9.32.17704.1 | 9.33.1808.2001 |
(platform "HP9000s700") | not used | HP9000s700 | HP9000s700 | HP9000s700 | PC | PC | PC | PC | PC | PC | PC | PC |
(execMode v6)(1) | not used | fast | ole | v6 | v6 | v6 | v6 | v6 | v6 | v6 | v6 | v6 |
(prefExecMode v8)(3) | not used | v8 | v9 | v9 | v9 | v9 | ||||||
(filterNAN 0) | same for all |
If the edited VEE program doesn't load then odds are you have made a syntax error or there are items in the VEE program which don't exist in the targeted version of VEE. In some cases the problem lies in object attributes that don't exist in the older VEE. For instance recent VEE "helpfully" adds RTF to Notepad text. If The older VEE objects to such attributes they must be (very carefully) removed.
The short answer is "NO". Think of VEE as you would Java. When a programming language is structured with a separate execution engine it becomes possible to port user programs to a new platform by simply porting the execution engine. Hence Java code will generally run on any platform for which the execution engine exists. The downside is that one indeed needs the execution engine. VEE works the same way. For both VEE and Java at minimum the execution engine (which thankfully is free) is needed along with user code. But only one copy of the execution engine is needed on a given machine.
After you download VEE from Keysight and install it, you may notice that it is branded "Agilent VEE" (or even HP VEE) rather than "Keysight VEE". This is due to company splits and mergers. VEE was first developed by Hewlett Packard, so versions up until 6 are branded "HP". When Hewlett Packard split (computers vs instruments) ca 2000 , VEE went with Agilent and was rebranded as Agilent VEE. In 2013 Agilent produced what turned out to be the final version of VEE (9.32) and then shortly after split (instruments vs chemistry/medicine), with VEE going with the new Keysight. Since Keysight did no new development they did not rebrand the code and it remains as Agilent VEE even though it is sold as "Keysight VEE".
Update for version 9.33 - January 2019 - Now that the 9.33 version has been released, most of VEE code has been rebranded to "Keysight". If you look closely you'll still find some Agilent marks, but most everything visible now says Keysight.
Over the years there have been various offerings of VEE that are a subset
of the full VEE Pro. The biggest difference between these various editions is
the presence or absence of an OEM Matlab Engine.
Feature | Pro | Run | Student | OneLab | Express | Eval |
Matlab Script | yes | yes | only for installed Matlab | yes | no | no |
Creating Runtime version of VEE programs and Secured version of VEE objects | yes | no | no | yes | no | no |
The Callable Server feature, i.e. calling VEE as an ActiveX automation server | yes | no | no | yes | no | no |
The Remote Function feature, i.e. importing a UserFunction that runs in another VEE process on a remote host computer | yes | yes | no | yes | no | no |
Importing Compiled Functions | yes | yes | yes | no | yes | no |
Internal Web Server | yes | yes | yes | no | yes | no |
Other features | yes | yes(2) | yes | yes | yes | yes(1) |
A fairly common programming task is to create a program that presents the user a series of choices that can be chosen at random. Each choice activates some particular functionality. A typical Panel view is shown below. This panel activates when the program is run and the end user can select from a number of different actions.
Spaghetti Coding. A common approach for new users is to just start programming each of the functions on a large flat design. Typically each section will have a START button so that the section can be run by itself. The user quickly finds that at run time this doesn't do what is needed since
As of VEE 8 there is a memory leak associated with automatic type conversion of numerical values (int or real) to boolean. This leak still exists in the final VEE 9.33. In particular, expressions such as
"FALSE OR PI"
generate leakage as they require automatic type conversion. This is not seen prior to VEE 8 since the boolean type did not exist. While the leak is small, if your code repeats many times it will become quite noticeable. The suggested workaround is to avoid logic expressions using both booleans and non-booleans, since then no type conversion is needed. Two such alternative expressions are:
"FALSE OR asboolean(PI)" avoids the leak, but should be noted is not backward compatible with VEE 7
"asint(FALSE) OR PI" also avoids the leak and IS suggested since it is backward compatible.
UPDATE: As of Windows 10 20H2 (and probably before that) VEE 7 installs cleanly with no tricks involved.
VEE 7 and 8 are not supported in Windows 7+ and by default do not install cleanly. However that doesn't mean that you can't be quite successful anyhow. Here's some hints that have worked for many:
UPDATE: VEE 9.33 is supported under Windows 10 and installs cleanly.
VEE is not supported under Windows 10, but that does not mean that it won't work. There are various issues with different versions of VEE, but with a little effort it is possible to make VEE 6,7,9 all work under Windows 10 32 or 64-bit. You may well find various issues, but so far most reported issues have been relatively minor or have good workarounds. Since VEE 9.32 is the final version, it is generally recommended that it be used in lieu of any older version.Various unsupported modifications to VEE behavior can be made using a config file that is read by VEE at startup time. This file (vee.exe.config) is a plain text file that is to be placed in the VEE install directory and should only be edited with an ascii text editor. In most cases if you utilize runtime vee, there will be similar veerun.exe.config file.
NOTE: if you have an existing vee.exe.config (or veerun.exe.config) file be sure to create a backup copy before editing and only use an ascii text editor.
NOTE: make sure that the config files do NOT have a .txt suffix (i.e. vee.exe.config but NOT vee.exe.config.txt)
<runtime> <generatePublisherEvidence enabled="false"/> </runtime>
<startup useLegacyV2RuntimeActivationPolicy="true" ><supportedRuntime version="v2.0.50727" /> </startup>
<?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="Agilent.Vee.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" /> <section name="Agilent.Vee.DefaultPreference" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" /> <section name="Agilent.Vee.Customization" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" /> </sectionGroup> </configSections> <userSettings> <Agilent.Vee.Properties.Settings> </Agilent.Vee.Properties.Settings> <Agilent.Vee.DefaultPreference> </Agilent.Vee.DefaultPreference> <Agilent.Vee.Customization> </Agilent.Vee.Customization> </userSettings><startup useLegacyV2RuntimeActivationPolicy="true" > <supportedRuntime version="v4.0.30319"/> </startup> <runtime> <generatePublisherEvidence enabled="false"/> </runtime> </configuration>
<supportedRuntime version="v3.5.30729"/>
or
<supportedRuntime version="v4.7.02053"/>
or
<supportedRuntime version="v4.8.04115"/>
and this variation is also reported to work
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.8"/>
While VEE ships with a version of Matlab (accessed via the Matlab Script object) , this version comprises the core Matlab and Signal processing toolbox. Matlab of course has many other toolboxes available, but they are not part of this install. To use the rest of Matlab, one must purchase Matlab separately and then link it to VEE. Once Matlab is installed, then the VEE Default Preferences contain an option for selecting which Matlab engine to use. Note that this is a global VEE option so is not configurable per VEE program.
HOWEVER VEE is 32 bit code, so you must install 32-bit Matlab in order for VEE to link with it. The biggest downside here is that since Matlab 2015B there have been no 32-bit versions released. Hence using the Matlab Script object one can only use older versions of Matlab.
If you want to take advantage of more recent Matlab (or other 64-bit engines) then you should look at VEE Scripting which comes with VEEOS.
Depending upon the version of VEE you have and the way that your Windows system is administered, you may find that the Matlab Script object does not work in a fresh VEE install. The typical error message is "Could not start Matlab Script engine". If you see this it is most likely due to the needed registration of the Matlab library which isn't occurring properly.
Fortunately there is an easy workaround that only has to be done ONCE.
Find VEE in your start menu, and RIGHT CLICK to find the "run as administrator" option. This will force VEE into an elevated permission and allow the Matlab libraries to get registered. After VEE starts go ahead and exercise any Matlab Script object. All should proceed properly.
That's it! Once this is done you can go back to running VEE normally.
VEERUN has a similar issue but a slightly more complicated workaround. In particular, since you can't interact with veerun.exe after it starts, you can't instantiate and run a Matlab object. So using "Run as Admin" on the executable does not help. Instead there are two paths that should work. Start by creating and saving a simple VEE program with a Matlab script object.
<path>\veerun.exe
<path>\savedVEEProgram
. Then execute this script
using "Run as Admin"Like most applications, you will likely start VEE from a menu or automatically by selecting a VEE program. However, there are many useful things you can do by executing VEE with one or more command-line options. Some of these options are documented, some are not. Note that various versions of VEE may or may not recognize all of these and that vee development and runtime versions will have different options. To get the list for your version use the "-help" option.
VEE Command line available options: --custom_option -- passed through to the user's program -addMenu <name.mnu> -- loads the specified menu file IN ADDITION TO the installed menu file -d <directory> -- set the install directory -disallowclose -- disallow closing of execution window -enablewarnings -- enables the display of warnings -geometry -- set the initial window geometry (e.g. 300x500+50-200 is 300x500 window offset from lower left) -help -- print list of exposed command line options -iconic -- start up the window minimized -maximize -- start up the window maximized -menu <name.mnu> -- loads the specified menu file INSTEAD of the installed menu file -ioconfig -- edit the I/O configuration only -prefconfig -- edit the Default Preferences configuration only -noerrdisp -- don't display errors (use with -r) -nologo -- don't show copyright/Logo box -r <filename> -- load and run a program file -secure <filename> -- create secured program -veeio <filename> -- use veeio info from this file <filename> -- load a program file
Here's a few useful things you can do with a command line:
Starting with VEE7, the Description field editor use RTF rather than plain text. This enables more readable documents. The savvy user might note that RTF allows embedded graphics, which means that one can start creating documents that are more than just text.
However there are two stumbling blocks:
CAUTION: While UF's have a Description like any other VEE object, and the Function and Object Browser presents the Description to the user, the Browser also doesn't grock RTF. Hence if you have anything more than plain text it will not be very readable. See How to create a plain-text "Description" for a solution.
In most contexts, a true "constant" is a value that is set and cannot be changed. This allows the programmer to rely on the certainty of this value.
The Native "Constant" in VEE enables one to enter a value that is then accessible through normal data lines. However this is not really a constant since it is simply a value entered into a dialog and it can easily be changed.
There is at least one true constant in VEE, that being pi which is universally available. Since this is natively defined it is unchangeable and can be used anywhere. What would be very useful is to have the ability to create a similar named constant, but as of this writing there is no known way to do this.
Perhaps the next best thing is to have an object that is similar to the Data | Constant objects, but is not changeable. For instance, here is an object that defines a constant and that is not editable.
To create such as object is a little bit of a cheat. What this entails is a secured User Object with VEE data inside of it. Since the object is secured it cannot be edited (from within VEE at least). A key difference between this constant object and a native Data Constant is that this one can be a value of any type, size, and shape, whereas the native constant is restricted to a scalar or 1D array.
To create such an object takes several steps, though it can also be easily automated from within VEE.
The User Function library dataConstantLib.vxe contains a User Function that will directly create a secured UO with any data embedded
createDataConstant(data,dataName,fileName)
"data" is anything you would like to be in your constant.
Note that unlike the native Data Constant this one is not limited to scalars and
vectors
"dataName" is whatever label you would like on the end object
"fileName" is the file into which your object will be written
Run this to create the data constant object, then MERGE that object into your
program
User Function constants
Another approach that can also be automated is to create a User Function library
for constants. Each constant is a single user function with the name of the
constant. The advantage of this approach is that the constant may be used
anywhere a regular variable is used, as in pi*eps()^0.5
. A minor disadvantage is that the function syntax eps0()
needs to be used rather than just a variable name eps0.
As with User Objects the User Function constant can be any type, size, and shape
If local User Functions or imported (non-secured) User Functions are used then once again the values are easily editable from within VEE.
If imported secured User Functions are used then as with secured User Objects the values are not editable. However as with any imported library note that this creates a dependency.
-menu *.mnu -- loads the specified menu file INSTEAD of the installed menu file
-addMenu *.mnu -- loads the specified menu file IN ADDITION TO the installed menu file
Fast forward to 2024 when new desktops tend to have lots of cores. More is better, right? Well VEE is single-threaded so maybe not so much, but there's another issue lurking that may catch you:
The embedded Matlab in VEE 9 is multi-threaded but is old enough that it has problems if there are too many cores. In particular it can hang if there are 24 or more cores. When this happens VEE will lock up when Matlab is called. Matlab in VEE 7 appears to not have this issue.
The workaround suggested by Keysight is to set the affinity of VEE to a single core. This is inherited by Matlab and all is well.
The problem: MatLab functions will not run. Causes VEE to lock. However, VEE itself runs just fine as long as the VEE program doesn't flow into a MatLab function. The Reason: MatLab does not run if there are 24 or more cores. The Fix: Run VEE using the Windows affinity command to limit the number of cores available to the VEE process. Example Batch File: cd "c:\Program Files (x86)\Keysight\VEE Pro 9.33\" Start /affinity 1 vee.exeAffinity can also be set using dotnet in your program, as in
System.Diagnostics.Process.GetCurrentProcess().ProcessorAffinity=A This would of course be set before any Matlab usage.Another option if you have access is to use a more modern version of Matlab or migrate to the open source Octave. This has the added benefit of being able to use 64-bit Matlab/Octave. While this isn't possible with VEE's Matlab Script object is is quite doable using the VEEOS Library's scripting capability.
VEE is augmented by an embedded (OEM) version of Matlab. This version has changed through the years.
Note that up through R2015B, Matlab offered a 32-bit version and using VEE Script one can replace the embedded Matlab with the full Matlab. This enables access to all of Matlab functionality. After 2015B only 64-bit Matlab was available so it could not be used directly with VEE. However using the VEEOS Library's scripting capability one can communicate with any recent version of Matlab. Note that the scripting also provides the ability to use Octave instead of Matlab.