changes
Highlights for spec release 6.04
January 12, 2017 - RELEASE 6.04.07
FIXES
Fix For Defining Macros Using eval()
A bug introduced in the recent 6.04.05 release broke the ability to define macros using eval(). Since the standard scan macros define a _scan_on macro, eval() couldn't be used to do scans. Also, since a spec server invokes the same internal code as eval() to run remote commands, client-initiated scans in a spec server broke. The bug is fixed in this release.
January 11, 2017 - RELEASE 6.04.06
FIXES
Fix For vxi11_put()
A bug introduced in spec release 6.02.01 that broke sending strings with vxi11_put() has been fixed.
Fix For Terminal Settings On Forced Quit
A bug introduced in spec release 6.02.08, where terminal settings were sometimes not properly reset if spec was quit using SIGQUIT or SIGTERM signals, has been fixed.
December 18, 2016 - RELEASE 6.04.05
IMPROVEMENTS
Files Opened With -l logfile No Longer Reopened On Restart
Log files opened or created on the command line with the -l logfile option will not be included in the list of files saved to the session's state file. Thus, those files will not be reopened when spec is restarted. This change accommodates sites that use scripts to create uniquely named log files for each spec invocation. Unless such files were specifically closed, they would be automatically reopened in subsequent spec sessions.
array_read() Now Assigns Lines Of Text To String Array Arguments
The array_read() function, which can assign values to data array elements from text files containing rows and/or columns of values, now treats assignments to string arrays differently. When passed a string array argument, array_read() will assign each row of text from the file to successive rows (or columns) of the array. Previously, the text file was scanned for number values, which would be assigned to consecutive bytes in the string array, just as if it were a byte array. See the arrays help file for details.
Updates To eval() and eval2()
A new built-in global variable named EVAL_RESULT will be assigned a value after each call to eval() or eval2(). Its value will be -1 if there is an error parsing the argument. If the last statement of the parsed string is an expression, EVAL_RESULT will be zero. If the last statement of the parsed string is a statement, EVAL_RESULT will be set to 1.
If there is an error parsing the argument string, a new built-in global variable named EVAL_ERR will be set to the error message. Previously, if there was an error message, eval() and eval2() returned the message string, and if there was no associated message, returned false. The functions will now always return false if there is an error.
The eval() and eval2() functions will now accept and return the value of an input string containing a single number, literal string or a variable. Previously, such input would generate a "Not a command or macro" error, as it does at the main spec prompt.
See eval in the functions help file for details.
splot Updates
The Python splot utility is now at version 3. The code has been substantially reorganized. The better supported matplotlib 2D plotting library is now preferred over PyQwt. The new version includes many fixes and improvements. See the updates notes in the splot distribution docs subdirectory for further details.
MACROS
Updated Counting During Scans Displays Full Row Of Counters
The standard _upd_cnt macro, which displays updated values of the counters during scans if the corresponding option is selected, now displays as many counters as fit in one row on the screen. Previously, only the time, DET and MON channels were displayed.
Changes To Motor/Counter Configuration Saved To Data File
The standard _head macro, used in all the standard spec scans, now includes a call of the new macro chk_datafile_head which does a quick test to see if the motor or counter configuration has changed since the datafile was opened. If there has been a change, the data file is updated with the new motor and counter configuration.
New Option To Save Motor/Counter Configuration In Each Scan Header
The standard _head macro, used in all the standard spec scans, now implements an option to write the complete motor and counter configuration (names and mnemonics) within the header section of each scan. Normally the information is only included in the file header. The new global symbol _sav_mne signals whether or not to save the information. The mstartup macro prompts for the configuration. The default mode is to only write the information in the file header or when there is a change in the hardware config file.
Time Scans Can Now Be Resumed
The _timescan macro, used by timescan and loopscan, has been updated to remove unnecessary code and to maintain sensible values for the _n1 global variable, which generally holds the total number of points in a scan. The changes allow the resume macro to restart a time scan halted with ^C.
HARDWARE
MDrive Support Updates
Support for the Schneider Electric Motion (formerly IMS) MDrive motor controller has been updated to work with firmware versions 5 and greater. The newer firmware uses a different command to set the mode of the input switches. In addition, spec doesn't initialize the input switches for firmware version 5 or greater. An initialization sequence for the switches can be included in the hardware config file, though. For firmware version 5 or greater, the initialization sequence can include the commands IS, OS and D#. As before, for earlier firmware the sequences can include S# and D# commands. Also in this spec release, the communication between spec and all versions of the MDrive controller has been made more robust.
FIXES
Fix For Disappearing OUTFILES When Started With -l logfile
A bug, where the built-in associative array OUTFILES disappeared when the -l logfile start-up option was used has been fixed. The OUTFILES array contains information about all the open output files.
Fix For Truncated Strings With syms -v and show_state
The values for string values displayed with the -v option to the syms command and with the shell utility show_state were previously truncated to approximately 600 characters. This spec release will display the entire string.
Fix For array_read() Crash
A bug, where calling array_read() with certain subarray arguments and with a file having fewer lines than the array could fit would cause a segmentation fault, has been fixed.
Fix For TANGO_ERR Behavior
The built-in TANGO_ERR symbol, used when spec is linked with the TANGO libraries (see spec's tango help file), now behaves as expected when used with syms -v, whatis("TANGO_ERR", "info") and conditionals, such as:
if (TANGO_ERR) ...
The above will be false if TANGO_ERR has a number value of zero or is the null string, "". TANGO_ERR has a special property as a spec built in symbol in that it is allowed to be either a number or a string. Other built-in symbols can be only one or the other. Previous spec releases didn't properly accommodate that and the above usages didn't always result in what would be expected.
Fix For Memory Leak When Using Macro Hardware Motors
A bug, where memory allocated for macro-hardware macro-functions calls during the reconfig command was not freed, has been fixed. The memstat command would show the memory allocated for "Parse Tree" growing after every reconfig in previous spec releases.
Fix (Again) For Debug Level 512 Crash
A bug that resulted in spec crashing on start up if the debug level was set to include 512 (memory allocation and freeing) has been fixed. (A similar bug was fixed in release 6.00.05, but subsequent modifications in the code reintroduced the problem.)
November 17, 2016 - RELEASE 6.04.04
HARDWARE
Issue With MDrive Limit Messages Fixed
The MDrive motor controller firmware has changed many times over the years and not always in a backward compatible manner. The spec MDrive support parses the firmware string returned by the motor controller to determine what commands will work correctly with the firmware in use. At some point, the format of the firmware string itself changed, which broke spec's parsing of the firmware version. The most noticeable result to users was that spec no longer displayed messages when the associated motor hit a limit switch. This spec release fixes the parsing of the firmware version string and restores the display of limit messages.
Fix For Disabled PCI/PCIe Boards
An issue where PCI/PCIe cards supported by spec at user level would be disabled at the Linux kernel level at boot time has been addressed. The disabled cards would be unusable by spec. The spec code now sends commands to enable such cards during initial hardware configuration (provided spec has suitable permissions).
Updates To Support For Using Linux setcap
The feature for using the Linux setcap utility as an alternative to spec being a set-user-id-root executable that was introduced in spec release 6.04.01 has been updated. The initial support only dealt with the "raw io" capability, which grants access to I/O ports. In order for spec to access /dev/mem, which is needed for mapping PCI/PCIe memory space to the spec process, the "dac override" capability is required. ("Dac override" overrides discretionary access control, that is, bypasses file access permissions.) Also, in order for spec to enable PCI/PCIe cards that were disabled on boot by the Linux kernel, spec requires "sys admin" capability. To protect the system from spec users with such enhanced capabilities, spec turns off all capability modes immediately on program start up (just as it does with set-user-id root privilege) and only enables the capabilities around the few lines of code used to gain access to the otherwise unavailable resources.
This current release still installs spec using the traditional method of changing ownership of the spec executables to root and the mode to u+s. A forthcoming spec release will instead execute the following command:
setcap "cap_dac_override=ep cap_sys_rawio=ep cap_sys_admin=ep" spec
The command can be used on this and subsequent spec releases as an alternative to the set-user-id-root mode. Do not use the command on older spec releases, as the older releases do not disable the privileged capabilities within the code.
November 14, 2016 - RELEASE 6.04.03
IMPROVEMENTS
array_read() Now Does Tilde Expansion
The array_read() function, which takes a file name as its first argument, will now do tilde expansion of the argument. Tilde expansion means that the tilde character ~ will be replaced with the path of the user's home directory. The array_read() function is used in the new fscan "file scan" macro.
fmt_read() and fmt_write() Now Do Tilde Expansion
The fmt_read() and fmt_write() functions, which take a file name as first argument, will now do tilde expansion of the argument. Tilde expansion means that the tilde character ~ will be replaced with the path of the user's home directory.
whatis() Now Recognizes Number Constants
The built-in whatis() function will now return the value 8 if the string argument represents a numerical constant in any format (decimal, octal, hexadecimal, exponential).
MACROS
Scan Heading Reverted To Show ascan For dscan
In the initial release of the new array-based scans (see newscans.mac), for delta scans the macros displayed the names dscan, d2scan, etc., in the headers saved to the data file and shown on the screen. In this release, ascan, a2scan, etc., are displayed for the delta scans, which is the traditional behavior.
Updated scan_data_init() Works Better With splot
The macro code for scan_data_init() has a few small changes to work better with spec's Python splot utility.
FIXES
Fixed Scan Heading For Multi-Motor Delta Scans
A bug in the new scan macros that showed the wrong start and end motor positions for delta scans of more than one motor (th2th, d2scan, d3scan, d4scan, d5scan, dmesh) has been fixed. Only the text of the scan header was incorrect -- the scans were done as commanded.
Fixed Issues With plotselect Assigning DET and MON
Two issues in the plotselect macro related to assigning values to DET and MON have been fixed. If either DET or MON were set to values that did not correspond to an enabled counter when entering the macro, changes made in the macro wouldn't stick. Also, new values might not have stuck if the multiple plot window feature was active.
Fix For whatis("")
A bug where the whatis() function identified an empty string as a macro has been fixed.
HARDWARE
Smaract Sensor List Updated
The built-in table of supported sensor types for the Smaract SCU and MCS motor controllers has been updated to match the additional sensor types now available from Smaract. See the spec smaract help file for details.
October 14, 2016 - RELEASE 6.04.02
FIXES
Fix For tango_io() "source" Command
The "source" command option for the tango_io() function, although documented in the spec tango help file, was not fully implemented until this spec release. The "source" command can now be used to set or get the TANGO option that specifies whether to obtain data directly from a device or from a polling cache.
HARDWARE
Support For CLS EPICS Motor Record
The alternative EPICS motor record developed and used at the Canadian Light Source (CLS) is now supported. See the notes in spec's epics help file for details.
September 12, 2016 - RELEASE 6.04.01
IMPROVEMENTS
The for (var in assoc_array) Syntax Now Sorts Elements
The syntax:
for (var in assoc_array) { ... }
will now return the elements in lexicographical order. Previously, the order was unspecified. The sort order is the same as used by the print and syms +v commands when displaying associative arrays.
Custom Optional Parameters Now Available With image_par() and mca_par()
Previously, custom optional parameters added to the config file for MCA- and image-type devices have only been accessible from within macro hardware functions as elements of the associative array prefix_CONPAR[] where the array elements are indexed by the parameter name and prefix is the macro function prefix. With this spec release, the parameters are generally available using image_par() and mca_par().
Integration With Linux "capabilities"
The default spec installation on Linux makes the spec executable a set-user-id root process in order for spec to have access to I/O device resources for hardware control. In this release, the Linux command setcap can be used as:
sudo setcap cap_sys_rawio=ep /usr/local/bin/spec
That command gives spec the I/O privileges necessary without having to make spec a set-user-id root program. See the Linux man pages capabilities(7) and setcap(8) for more information.
(Note, even when spec is set-user-id root, spec runs with an effective ID of the actual user except around the limited calls to gain access to I/O resources. It isn't possible for a spec user to do anything else that requires root access.)
MACROS
New Array Scan Engine Now the Default In the Standard Macros
The updated scan macros, included in spec release 6.03.04 distribution in the file macros/newscans.mac, are now the default scan macros. The "newscan" macros are a significant update to the long-time standard spec motor scans. Whereas the traditional scan macros calculate new motor positions at each point as the scan progresses, the new scans take an array containing motor positions (and possibly count times) precalculated for each point of the scan.
The new macro source file replaces macros/scans.mac, which is still included in the distribution but is not installed. The array scan engine enables new scan types and creates a more consistent scan behavior, but remains backward compatible with the existing user definable hooks.
The _ascan macro, previously used by the motor scans, is not used with the new scan engine, but remains as an installed macro for the benefit of locally defined scan macros that rely on it.
Redefined scans include ascan through a5scan, dscan through d5scan, lup, th2th, mesh, hscan, kscan, lscan, hklscan, hklmesh, hkcircle, hlcircle, klcircle, hkradial, hlradial and klradial.
New scans that use the new array scan engine are:
- fscan
- Does motor scans based on positions in a file. The beginning of the file needs a line starting with #M that contains a space-separated list of motor mnemonics. The following lines contain space-separated motor positions corresponding to the mnemonics. Each line of the file corresponds to a point in the scan. The data file can optionally contain a per-point count time as the last item on each line.
- dmesh
- A delta mesh scan, similar to a delta motor scan. Endpoints are specified relative to the starting positions and motors are returned to the starting positions as the end of the scan.
- hklscanarr
- An HKL scan that takes a 2D array of HKL positions and an optional count time as arguments. Each row of the array corresponds to a data point. If no count time argument is specified as an argument to the macro, the last column of the array contains the count time for each point.
- vscan and v2scan
- Variable step-sized scans with densest points at a specified "center" position. The spacing density is calculated using parameters for an exponent and a minimum step size. The parameters will use default values or can be specified either as optional arguments to the scan or in global variables. See a complete description in the comments of the vscan.mac file.
- xascan through xa4scan and xdscan through x4dscan
- Expanded motor scans that have a configurable number of points at the beginning and end of regular motor scans at a lower point density. These scans are similar to local scans at ESRF.
- rscan
- A region scan named that allows specifying a single motor scan with various point densities in consecutive segments. This scan is similar to a local scan at ESRF.
Geometry-Specific Scans Updated To Use Array Scan Engine
Scan macros associated with specific geometries, namely aziscan in fourc, fivec and sixc; alphascan and betascan in zaxis; and abscan, abmesh and r2scan in surf, have been rewritten to use the new array scan engine. The macros in newscans.mac include a few small revisions to accommodate the new scan types. Also, the twoc geometry no longer includes separate scan macros, as the macros in newscans.mac will work with the two-circle planar geometry.
FIXES
Fixes For ^C Response On Server During Execution Of remote_* Commands
A fix in spec release 6.03.05 to eliminate the double echoing of text typed at the keyboard to a spec server while the server was executing a command from a spec client inadvertently disabled recognition of a ^C typed at the server keyboard during execution of the command. This spec release restores that functionality. Note, the problem appeared to exist only on Linux platforms when spec was linked with the default libedit libraries. There were no issues if using libreadline on Linux or either libedit or libreadline on Mac OS X.
Fixes For Printing Long Strings
Issues related to printing long strings (greater than 9000 bytes) when debugging was enabled that could lead to program crashes have been addressed. In addition, debugging messages printed from multiple threads when running in server mode should now be more robust.
Macro Hardware Polling Now Only For Active MCA and Image Devices
Previously, the "get_status" key for the _cmd() functions for macro hardware MCA and image devices would be called for all MCA instances even if only one was active and for all image instances if only one was active. This spec release will make "get_status" calls only for active devices.
HARDWARE
Preliminary Implementation Of "Server Hardware" Feature
Although the spec binary generally includes built-in support for hardware controllers, to accommodate devices that require vendor libraries that don't integrate well into the spec binary, a new generic "server hardware" interface is part of this spec release. Currently only MCA-type devices are supported. See the server_hdw help file for details.
Encoder Mode Update For Trinamic TMCL Motor Controllers
By default, the spec support for the Trinamic TMCL motor controllers uses relative move commands for encoder motors (TMCL_E) and absolute move commands otherwise (TMCL). A new custom optional motor parameter encoder_move_mode can be assigned values "absolute" or "relative" to set what kind of moves to use for encoders. Use the p command from the standard Motor screen to access the custom parameter screen.
Encoder Mode Update For Phytron PhyMotion Motor Controllers
The Phytron PhyMotion motor controller support will now use relative moves for a motor configured to use an encoder (motor type PHYMO_E). Otherwise, spec will use absolute moves. In addition, a custom optional motor parameter encoder_move_mode can be assigned values "absolute" or "relative" to set what kind of moves to use for encoders. Use the p command from the standard Motor screen to access the custom parameter screen. Finally, spec will use parameter 22 as the position when configured with an encoder. Previously, spec used parameter 19.
Revised and Updated Support For Princeton Applied Research Model 283
The existing code to support the Princeton Applied Research Model 283 Potentiostat/Galvanostat as an MCA-type device has been substantially rewritten to use current spec conventions and to fix issues in the code. The support now works with data arrays. The native data type is float with 98304 channels. Data can be read in three modes, selected using a subaddress in the selection argument to mca_sget(). No subaddress or a subaddress of 0 interprets data as 16-bit signed integers. A subaddress of 1 interprets data as 12-bit signed integers and is appropriate for reading measured currents with auto-ranging mode off. A subaddress of 2 interprets data as 12-bit signed integers with a 4-bit signed exponent and is used for reading measured currents with auto-ranging mode on. Use the roi_beg and roi_end arguments to mca_get() and mca_put() to transfer data from or to specific "curves" in the 283.
The mca_par() command pass-through options "read" and "send" can be used to program the device parameters and operating mode. The mca_par() "status" command returns the GPIB status byte, which is the same value as returned by the "ST" command. User code should make sure the status indicates the device is finished with an acquisition before the user code reads the data.