These test programs are no longer installed into the bin/arch +directory. Running all these programs on any host architecture should be as +simple as:
+ +++ +cd /path/to/base/src/libCom/test/O.arch +make test+
The above make target uses Perl's Test::Harness module to execute all of the +test programs and summarize the result. It is also possible to run individual +tests as desired; the output is designed to be comprehensible to humans.
+ +For vxWorks and RTEMS, a test harness has been created that will run all of +the test programs in a suitable order. At a vxWorks target shell, type:
+ +++ +ld arch/vxTestHarness.munch +cd "/path/to/writable/directory" +epicsRunLibComTests+
On RTEMS, boot the bin/arch/rtemsTestHarness binary.
+ +You may wish to capture the output from running these to a file to more +easily check the results, since there is no wrapper program to collect and +summarize the results of the individual test programs.
+ +The handling of breakpoint table data has been reworked. It is now possible +to give table data in either ascending or descending order, and the breakpoint +data may have a negative slope such that the engineering values increase while +the raw values decrease and vice versa. The only restriction on the data is that +is must be monatonically increasing or decreasing, so you can't use a breakpoint +table for curves that have local minima or maxima. This restriction is checked +for when the breakpoint table is loaded.
+ +The build configuration support for vxWorks 6.x has changed significantly, +having been recombined with the older vxWorks 5.x support. The two target +architectures vxWorks6-mv2100 and vxWorks6-mv5100 have been +removed; IOCs built under vxWorks 6.x using these architectures must revert to +the original vxWorks-ppc603_long and vxWorks-ppc604_long +architectures instead. The configuration file CONFIG_SITE.Common.vxWorksCommon +now specifies the vxWorks version number, as well as the filesystem path to +the installation of vxWorks using the WIND_BASE variable.
+ +The calc expression parser and exective have undergone a signficant overhaul, +although the API and expression language supported are backwards compatible with +one minor exception, described below. Significant improvements have been made to +both the API and the expression language: Multiple values can be calculated and +assignments made in a calc expression; Error reporting for humans is now +supported by the expression parser, and code can discover what inputs and +outputs are needed and generated by an expression.
+ +Assignment operations are now possible, using the new := operator +which must have an expression variable (A through L) to its +immediate left. Multiple expressions can be included in the calculation string, +separated by a semicolon ;, all but one of which must be assignments. +The value of the whole string is determined by the single non-assignment +expression, which may appear anywhere in the string. For example, the following +string causes a single CALC record to output the successive values of a sine +curve: sin(a); a:=a+d2r
+ +Previously any expression that performed an invalid operation which would +generate a NaN or Inf result would be stopped immediately and return an error to +the caller. Now it is possible to perform operations that generate NaN or +infinite results, and the results are returned as normal. The result of the +expression or the value assigned to a variable may thus be a NaN or an +infinity. To permit this to be checked within the expression, the new operators +finite(), isinf() and isnan() have been added to the +expression language. The literal values Inf and NaN are also +now supported in expressions.
+ +The incompatible change to the expression language was to change the +NOT operator from performing a unary minus operation to an integer +bitwise not; the former meaning is illogical and as a result was probably not +used much, if at all — nobody complained when I discussed this on +tech-talk...
+ +The extended API and the expression language are now discussed in detail in +chapter 19 (libCom) of the R3.14.9 version of the IOC Application Developer's +Guide.
+ +As a result of the above changes to the calc expression parser and executive, +both the calc and calcout records and the Access Security library have been +modified to take advantage of the new error diagnostics. The Access Security +library has been made to reject any expression that contains an assignment +operation, to prevent any possible security holes that might be caused by this +significant change to the expression rules.
+ +The calc and calcout records have had some subtle changes applied: To +mitigate the effects of the Inf/NaN behaviour change, the result of an +expression is checked for NaN, which will result in the UDF field being set and +an Undefined/INVALID_ALARM being raised as a result.
+ +An empty string is no longer a legal expression, therefor the CALC and OCAL +fields have been changed so that their default value is a literal "0" +string. Also any calcout record device support must now add the line +#include "postfix.h" before the +#include "calcoutRecord.h" line in the source code.
+ +The recGblResetAlarms() routine (which is called by all record types +towards the end of record processing) now optionally calls a single hook routine +via the function pointer recGblAlarmHook after it has updated a +record's alarm status and severity. See regGbl.h for the hook routine prototype +definition, the routine is also given the previous values of the record's status +and severity. The hook routine must not block, since this would hold up record +processing.
+ +These record types now support raw simulation mode. If the value of the SIMM +field is 2 (enum string "RAW"), the SIOL link value is placed into the RVAL +field and passed through the raw to engineering units conversion process just +like the real device support's raw value would be.
+The TIME field of a record is now displayed in a human readable format. TIME