From 7b7bdb82a64136da40eef6f01e917ebe100adc1f Mon Sep 17 00:00:00 2001 From: Andrew Johnson Date: Mon, 13 Nov 2006 21:32:06 +0000 Subject: [PATCH] libCom/test, Breakpoints, vxWorks 6, postFix/calcPerform, calc/calcout/asLib, recGblAlarmHook, raw simulation mode. --- documentation/RELEASE_NOTES.html | 127 +++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) diff --git a/documentation/RELEASE_NOTES.html b/documentation/RELEASE_NOTES.html index 605c41f14..f1c6f59f7 100644 --- a/documentation/RELEASE_NOTES.html +++ b/documentation/RELEASE_NOTES.html @@ -13,6 +13,133 @@ +

libCom/test

+ +

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.

+ +

Breakpoint tables

+ +

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.

+ +

Support for vxWorks 6

+ +

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.

+ +

postfix and calcPerform

+ +

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.

+ +

calc and calcout record, asLib

+ +

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.

+ +

recGblAlarmHook

+ +

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.

+ +

ai, bi, mbbi and mbbiDirect records

+ +

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.

+

dbpr

The TIME field of a record is now displayed in a human readable format. TIME