[Mx-mailing-list] MX 1.1.1 is available

[Bill Lavender]

Versions 1.1.1 of MX, MP, and MxTcl are now available at the MX web site 
from the download page

    http://mx.iit.edu/source.html

The changes for this release are described in detail below.

Bill Lavender

********************************* MX *************************************

Version 1.1.1 (01/11/06):
	A new build target 'win32-mingw' has been added for building MX
	with the MinGW compiler on Win32.  This target has been tested
	using MinGW 4.1.1 and MSYS 1.0.10 on Microsoft Windows.

	The source for the 'mxserial' program, which was previously 
	distributed separately, has now been folded into the main MX 
	source code distribution.  The source may now be found in the file
	'mx/util/mxserial_fork.c'.  The name of the file reflects the fact
	that it still only works on platforms that fully support the fork()
	system call.  We expect to add a version for Win32 at some later
	date, although the Cygwin version _may_ work now (untested).

	MX has added a new device class called PTZ for Pan/Tilt/Zoom camera
	controllers.  Note that these drivers only move the camera or change
	its settings such as focus or zoom.  They do not read out the actual
	picture image.  The following devices have had drivers added for
	this release of MX:

	    Hitachi KP-D20A/B cameras:
		hitachi_kp_d20 - MX PTZ driver.  The hardware only allows
				the zoom to be controlled.

	    Panasonic KX-DP702 cameras:
		panasonic_kx_dp702 - Interface driver for the controller.
		panasonic_kx_dp702_ptz - PTZ driver for an individual motion.

	    Sony VISCA cameras (tested with the EVI-D100):
		sony_visca - Interface driver for the controller.
		sony_visca_ptz - PTZ driver for an individual motion.

	    MX network PTZ controllers:
		network_ptz

	    Software emulated PTZ controllers:
		soft_ptz

	    Motor driver:
		ptz_motor - Controls the pan, tilt, zoom, or focus of
				an MX-controlled PTZ as an MX motor.
				This allows you to do things like step
				scan the pan, etc.

	MX has added initial support for communicating with the Blu-Ice
	and Distributed Control System from SSRL described at
	http://smb.slac.stanford.edu/public/research/developments/blu-ice/
	This initial version supports running MX as what Blu-Ice calls a
	"GUI client", although there is nothing on the MX side that requires
	the use of a GUI.  Additional support for acting as a Device Hardware
	Server (DHS) will be added in a future release.
	
	The Blu-Ice related drivers added to this release include:

	    Servers:
	    	bluice_dcss_server - Manages the connection to a Blu-Ice
				DCSS server.
	    Devices:
		bluice_ion_chamber - Reads out values from a Blu-Ice ion
				chamber as an MX analog input device.
		bluice_motor - Operates a Blu-Ice motor as an MX motor.
		bluice_shutter - Operates a Blu-Ice shutter as an MX relay.
		bluice_timer - Acts as an MX timer for Blu-Ice controlled
				ion chambers.
	    Variables:
	    	bluice_command - Sends a raw Blu-Ice command to a remote
				DCSS.
		bluice_master - Used to request that the MX client either
				become a Blu-Ice master or a Blu-Ice slave.
		bluice_string - Reads the value of a Blu-Ice string.

	Added optional timeout functionality to MX network connections
	using non-blocking socket I/O.  The timeout is turned on by setting
	flag 0x10000000 in the server_flags field of the MX server database
	record.  If the timeout is turned on, it currently is set to 5 seconds,
	although this can be changed at run time with a motor command like
	'set field 10id.timeout 2' to change the timeout to 2 seconds.

	Non-blocking socket I/O has been disabled for Solaris 10 for now
	since performance testing showed that it was _really_ _slow_ for
	some unknown reason.  By contrast, Solaris 8 has no such problem.
	I do not have access to a Solaris 9 machine to check this on, so
	I have disabled non-blocking socket I/O there as well just to be
	safe.  I will check into this issue further at some later date.

	New socket I/O functions mx_socket_set_non_blocking_mode() and
	mx_socket_ioctl() to consolidate the rather platform specific
	code related to these functions in one place.

	Added a new function mx_initialize_runtime() to consolidate all of
	the non-database related initialization of MX into one place rather
	than having copies of this initialization duplicated in all of the
	MX application programs.  This change was motivated by the need
	to make calls in all MX program to _control87() and _matherr() for
	the 'win32-borland' build target to disable floating point exceptions
	enabled by the Borland C++ compiler that are not enabled by the
	Microsoft compiler.

	The directories of test files bundled with MX have been reorganized
	to all live under a single directory called 'test'.  The old 
	directories have been renamed as follows:

	    test       ---> test/drivers
	    testserver ---> test/server
	    testupdate ---> test/update

	In addition, there is a new directory called 'test/features' which
	currently contains test cases for the interval timer, mutex,
	semaphore, and thread support described further below.

	The 'xia_handel' driver has now been successfully tested with the
	DXP-2X based multielement detector system at MR-CAT (APS sector 10).
	It appears that the main reason we were having problems with this
	before was that we were using configuration files that had the gain
	for some detector channels set to 0.  Apparently this happened since
	we did not realize that certain error messages generated by the
	Mesa2X configuration program meant that the Mesa2X-generated
	configuration file would contain some channels with gains set to 0.
	This has now been fixed.

	For XIA Handel controlled MCAs, starting a run in a single detector
	channel does not necessarily start the run in all channels.  For 
	this reason, a new MX timer driver has been added for use only
	with Handel:

		xia_handel_timer - Uses xiaStartRun() to start the MCA
				counting in all detector channels.

	MX interval timer support is now available on all MX platforms.  Bear
	in mind that on most platforms the timer callback is implemented
	in a separate thread, so the timer callback needs to be thread safe.
	However, some platforms have significant limitations on the
	support:

	1.  The MacOS X, BSD, and DJGPP targets currently use setitimer()
	    based interval timers using ITIMER_REAL since they do not support
	    Posix realtime timers.  This is bad since there can only be one
	    such timer per process.  Even worse, on MacOS X and BSD the timer
	    is SIGALRM based, which is _very_ bad since many different
	    systems, features, and libraries on Unix-like systems all try to
	    use SIGALRM, so there is a significant danger that different pieces
	    of code will fight over the control of SIGALRM.  For a future
	    release, I will investigate whether the underlying Mach system
	    provides a way around this problem for MacOS X.

	2.  The Solaris, Irix, and VxWorks targets use Posix realtime timers
	    with SIGEV_SIGNAL notification which restricts the number of
	    interval timers to the value (SIGRTMAX - SIGRTMIN + 1).  On
	    Solaris this value is only 8, while on VxWorks it is only 7.

	The following related MX driver has been added:

		interval_timer - An MX timer driver that uses the new
			interval timer functionality.  It is primarily
			intended for testing MX interval timers, but it
			may be used as an alternative to the 'soft_timer'
			driver as well.

	A set of functions called mx_signal_allocate() and mx_signal_free()
	for managing the allocation of signals has been added.  These 
	functions are advisory only since in general the underlying operating
	systems do not support such a feature.  At present, these functions
	are only used by the MX interval timer support.

	MX now includes support for threads in a platform independent fashion.
	This includes support for stopping threads, killing threads on some
	platforms, and waiting for a thread to terminate.  In addition, 
	support for thread-specific data is included.  Support for threads
	is available on all MX platforms except DJGPP.

	MX mutex support is now available for all MX platforms except 
	DJGPP.  Since DJGPP does not support threads, the mutex lock,
	unlock, and trylock functions are all stubs that return 
	MXE_SUCCESS on that platform.

	MX now includes support for counting semaphores.  In principle,
	both named and unnamed semaphores are supported.  However, not
	all features of the MX semaphore implementation are supported on
	all platforms since the underlying operating systems do not 
	uniformly provide the necessary features.  I will attempt to
	clean this up better in a future release.  See the file
	'mx/libMx/mx_semaphore.c' for the details of the current
	limitations which are too complicated to describe here.

	The Struck SIS3801 MCS has now been successfully tested with
	firmware version 9 using both the 'sis3801' driver and the
	'epics_mcs' driver.  This change increases the maximum time per
	point from 1.67 seconds to 26.8 seconds.  We have also found that
	the SIS3801 external next pulse feature finally works with firmware 
	version 9, whereas it did not work for us with earlier firmware
	versions.  We have now successfully tested using the SIS3807 pulse
	generator with version 4 firmware as an external next pulse source
	for the SIS3801 using version 9 firmware.  When using this
	combination, the maximum time per point becomes 14.27 years (!)
	which should be long enough for anyone.  The largest time per
	point that I have actually tested the system with is 1000 seconds.

	Added a bug fix for the 'epics_mcs' driver when used with recent
	versions of the EPICS MCA record.  We have encountered a problem
	where the initial connection to the 'Acquiring' PV times out, but
	subsequently works fine after the connection is made.  The typical
	symptom was that the first quick scan run in a given copy of 'motor'
	would fail with this error, but subsequent quick scans would work.
	For now, we are dealing with this by intentionally reading the
	value of the 'Acquiring' PV during MX startup to get the timeout
	out of the way before running the first user commands.  We also
	now send a stop command before starting acquisition, since starting
	an already started MCS did not always work correctly.  In addition,
	the driver now sets the preset real time to 0 when the number of
	MCS measurements is selected.  This is to stop MX MCS scans from
	terminating early.

	Previously, the MX 'monochromator' driver was invoking the function
	mx_motor_save_speed() during its open routine.  You should _never_
	do this.  If you do, then if you happen to start 'motor' when a
	quick scan is in progress in another copy of 'motor', you will
	overwrite the saved motor speed with whatever speed the motor 
	happens to have at that moment.  This has now been fixed.  Hopefully
	this will get rid of the cases where the monochromator has the 
	wrong motor speed after a quick scan completes.

	In a related change, MX scans now only save the motor speeds for
	quick scans at one single place in mx_perform_scan().  In addition, 
	mx_scan_restore_speeds() is now also invoked for quick scans near
	the end of mx_perform_scan() to guard against the possibility that
	a lower level routine did not already restore the speeds.

	The 'aps_gap' driver for Advanced Photon Source insertion devices
	has been modified to add the ability to change the undulator taper
	in units of mm or keV.

	The 'pm304' motor driver has been modified to add an extra
	'minimum_event_interval' field for testing the maximum rate at
	which commands can be sent to the controller.

	Applied Jim Fait's patch that modifies the 'pmac_cs_axis' motor
	driver for PMAC coordinate system axes so that it better handles
	aborts.  We also added a 'set position' function to that driver.

	Fixed a bug for the 'compumotor' driver in the 'set_position'
	function.  Previously, a 'set_position' command for one motor
	would screw up the positions for all the other motors controlled
	by a given Compumotor controller if those other motors used MX
	scale factors that were not 1.0.  The driver has now been fixed
	so that it uses the correct raw units rather than user units
	when redefining the position.

	Modified the 'mca_timer' driver so that it more correctly performs
	time normalization.

	Datafiles created by MX scans are now written in line buffered mode.

	MX scan databases whose names contain embedded spaces are now
	correctly updated by 'motor'.

	'motor' scripts now may use the '#' character as a comment character.

	A new function mx_info_entry_dialog() has been added along with 
	matching set and default functions.  This function is designed
	to display a prompt to the user and then read in a line of response.
	It has provision for suppressing echoing of characters typed in
	response.  This feature was added to support prompting the user
	for a username and password when connecting to Blu-Ice servers,
	but will obviously be useful in other circumstances as well.

	The driver arrays for MX classes and superclasses have been split
	off into a new file 'mx/libMx/mx_driver_class.c', while the driver
	arrays for MX types have been left in 'mx/libMx/mx_driver.c'.  The
	motivation for this change is to make it easier to link in only a
	subset of the MX drivers on a platform with constrained memory such
	as a VME crate.  If you are on a workstation platform and want to
	link in all the available drivers, you need not pay any attention
	to this change.

	There are several steps required to link in just a subset of the
	drivers:

	1.  The definition MX_LIB_SRCS in 'mx/libMx/Makefile' has been
	    split into three parts, namely MX_CORE_SRCS, MX_DRIVER_SRCS,
	    and mx_driver.c.  The makefile also provides a default 
	    definition of MX_LIB_SRCS that merely recombines the three
	    parts, namely:

	    MX_LIB_SRCS = mx_driver.c $(MX_CORE_SRCS) $(MX_DRIVER_SRCS)

	2.  Using VxWorks as an example, go into 'mx/libMx/Makehead.vxworks'
	    and create a new definition MX_DRIVER_VXWORKS_SRCS that lists
	    only the source code for the drivers you really want.  Then
	    create a new version of MX_LIB_SRCS like this:

    MX_LIB_SRCS = mx_driver_vxworks.c $(MX_CORE_SRCS) $(MX_DRIVER_VXWORKS_SRCS)

    	    Bear in mind that some driver files depend on other driver files.
	    For example, you can't have the motor driver 'd_compumotor.c'
	    without including the controller driver 'i_compumotor.c'.
	    If you leave out 'i_compumotor.c' in this example, the library
	    will successfully compile, but it will be impossible to create
	    a working database that uses Compumotor-controlled motors.

	3.  The last step is to create a new 'mx/libMx/mx_driver_vxworks.c'
	    that only contains references to the drivers you want.  The 
	    easiest way is to make a copy of 'mx/libMx/mx_driver.c' and 
	    just delete the driver table entries you do not want.  You
	    will want to delete the corresponding include files as well,
	    since they take up space too.

	If you do this correctly, you will end up with a version of libMx
	that uses up much less memory.  Nevertheless, on workstation
	platforms with hundreds of megabytes of memory or more, it is 
	simpler just to leave things as they are and link in all the drivers.

	This version of MX has started the replacement of buffer overflow
	prone functions with alternatives that are not prone to this problem.
	At present, this means the replacement of strcpy, strcat, strncpy,
	strncat, sprintf, and vsprintf with strlcpy, strlcat, snprintf,
	and vsnprintf.  The new functions are not universally available
	on all MX platform, so we have bundled slightly modified versions
	of strlcpy and strlcat from the OpenBSD people and fallbacks to
	sprintf and vsprintf for those platforms that do not yet have
	snprintf and vsnprintf.  There are a lot of uses of the old functions
	in MX code, so this change will not occur all at once.  MX already
	had some workalike functions called mx_strncpy and mx_strappend.
	These have been replaced with the corresponding strlcpy and
	strlcat calls.

	The old keyboard interface files key*.c have been folded together
	into a new file 'mx/libMx/mx_key.c'.  In addition, the new functions
	mx_key_echo_off(), mx_key_echo_on(), and mx_key_getline() have been
	added to provide a way of entering passwords without echoing them
	to the screen in a platform independent way.  Bear in mind that while
	the key echo on/off functions will affect all output on _some_ MX
	platforms, only mx_key_getline() is guaranteed to pay attention to
	the echo on/off state on _all_ MX platforms.

	A new file 'mx/libMx/mx_os_version.c' has been added to provide a
	platform independent way of getting the operating system version
	at run time.  This was done to allow programs to use one binary on
	multiple versions of an operating system in cases where different
	things have to be done on different versions.  It also provides a
	way of displaying the operating system version to the user for
	documentation purposes.

	On Win32, the implementation of mx_heap_check() has now been changed.
	When compiled to link with the debug libraries, it uses the function
	_CrtCheckMemory() as before.  However, when compiled to link with
	the release libraries, it loops over all the heaps returned by
	GetProcessHeaps() and invokes HeapValidate() on each heap.

	We have had a variety of problems with memory allocation functions
	when using the Borland C++ compiler on Win32 including both memory
	leaks and also things like programs hanging in malloc().  For this
	reason, we have written our own Borland-specific replacements for
	malloc(), free(), calloc() and realloc() which call directly to
	the underlying Win32 Heap() functions.  The source for this may
	be found in 'mx/libMx/mx_util_borland.c'.  Some new preprocessor
	tests in 'mx/libMx/mx_util.h' are used so that calls to malloc, etc.
	are redirected to the functions bc_malloc(), etc. instead when
	compiled with Borland C++.  We have not yet had a chance to see 
	if this makes the memory leak problem go away, but it definitely
	makes the hanging in malloc() problem go away.

	The 'mx/libMx/os_rtems*.h' header files have been revised to work
	better with RTEMS 4.6.5.  There are still some outstanding issues,
	so we have more work to do on this.

	The 'sunos4' and 'linux-kylix' build targets have now been declared
	obsolete since the original vendors no longer support them and the
	software no longer works on recent systems.  The files used by these
	targets have been moved to the 'mx/misc' directory and will be
	removed in a future release.

	Added a new function mx_string_split() that allows us to split
	a string into tokens.  It is similar to strsep() except for the
	fact that it treats a string of several delimiters in a row as
	being only one delimiter.  By contrast, strsep() would say that
	there were empty tokens between each of the delimiter characters.

	A couple of functions in the file 'mx/libMx/mx_util.c' have been
	split off into a new file 'mx/libMx/mx_util_cfaqs.c' to reflect
	the fact that they are covered by a different license since they
	were derived from the book 'C Programming FAQs'.

********************************* MP *************************************

Version 1.1.1 (01/11/06):
	Added support for the new MX PTZ device class for Pan/Tilt/Zoom
	camera base controllers.

	Added support for the new info_entry_dialog routines that prompt
	users for text input from core MX software routines.  Currently
	only used by the MX routine that prompts for a Blu-Ice username
	and password.

	MP now uses the new mx_initialize_runtime() function to setup
	the correct runtime environment for MX.

	Replaced calls to strcpy(), strncpy(), sprintf(), and vsprintf()
	with calls to strlcpy(), snprintf() and vsnprintf().

	Makefile updates for newer operating system versions and for minor
	changes to the build system.

********************************* MxTcl *************************************

Version 1.1.1 (01/11/06):
	MxTcl now uses the new mx_initialize_runtime() function to setup
	the correct runtime environment for MX.

	Replaced calls to strcpy(), strncpy(), and sprintf() with calls to
	strlcpy() and snprintf().

	Makefile updates for newer operating system versions and for minor
	changes to the build system.