[Mx-mailing-list] MX 1.1.0 is available

Bill Lavender lavender at agni.phys.iit.edu
Fri Jul 22 15:30:18 CDT 2005


Versions 1.1.0 of MX, MP, MxTcl, Mxserial, MX MarCCD Interface, Imcagui,
Optimize, and Optimize Auto are available at the MX web site from the
download page

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

Probably the most important features of this release are significant
improvements in the speed of MX network communications, a new fix for
the EPICS 'virtual circuit unresponsive problem', many new device drivers,
and the usual collection of bug fixes.  Read the changelogs below for
more information.

Bill Lavender

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

Version 1.1.0 (07/13/05):
	The most important change for this release of MX is to the MX
	network communication protocol.  Previous releases of MX sent
	the ASCII 'record_name.field_name' at the start of each message.
	In this new release, the default behavior is request a binary
	handle that is then used instead of the ASCII name in subsequent
	messages.  This means that the MX server no longer has to look up
	the record and field name from scratch each time a message comes 
	in from a network client, which significantly improves the efficiency
	of the server.  In support of this, a new structure type called
	MX_NETWORK_FIELD has been introduced as a place in which to store
	both the ASCII record field name and the binary handles.  In 
	addition, the mx_get(), mx_put(), mx_get_array(), and mx_put_array()
	functions have been modified to make use of the new MX_NETWORK_FIELD
	structures.  The MX_NETWORK_FIELD structure must be initialized
	before use by a call to the new mx_network_field_init() function.
	The only reason now to use the old ASCII based mx_get_array_by_name()
	functions is if the specified network field will only be used once
	during the lifetime of the program.

	For most cases, the MX_NETWORK_FIELD structures will be defined
	in the type-specific structure for a given device driver.  Here
	is an abbreviated example of how this works for the 'busy' field
	as used by the MX 'network_motor' driver:

	    mx/libMx/d_network_motor.h:
	        In the MX_NETWORK_MOTOR structure, a MX_NETWORK_FIELD
	        structure is included for each remote MX field used by
	        the driver.  For the 'busy' field, this would look like

	        typedef struct {
		        ...

	             MX_NETWORK_FIELD busy_nf;
		        ...

		} MX_NETWORK_MOTOR;

	    mx/libMx/d_network_motor.c:
	        In either the finish_record_initialization or the open
		routine, you must initialize the network field.  The
		network motor driver chooses to do the work in the 
		mxd_network_motor_finish_network_initialization()
		routine as follows:

		    mx_network_field_init( &(network_motor->busy),
		    	network_motor->server_record,
			"%s.busy", network_motor->remote_record_name );

		mx_network_field_init() records the name of the network
		field and a pointer to the server record.  It also
		records the fact that the client has not yet received
		a binary handle for the network field from the MX server.

		Elsewhere in the program, the network field can now be
		used as follows:

		    mx_status = mx_get( &(network_motor->busy_nf),
		    				MXFT_INT, &busy );

		The first time that mx_get() is invoked for this field,
		it will notice that it does not yet have a binary handle
		for the field and will transparently ask the server for
		one.  If at some later date, the MX network connection
		is disconnected, the handles will be invalidated on
		the next call to mx_get() or mx_put() and an error status
		will be returned.  Subsequent calls to mx_get(), mx_put(),
		etc. will attempt to reconnect to the server and then
		acquire new binary handles.  This is the manner in which
		automatic reconnection to remote servers is currently
		handled.

	All of the existing MX network drivers have now been modified to
	make use of the new MX_NETWORK_FIELD and binary handle support.

	Unix-style man pages can now be found in the mx/doc directory in
	the source code tree for motor, mxdriverinfo, mxserver, and mxupdate.

	This version of MX contains a new test version of 'mxupdate' in
	the source directory 'mx/update_new'.  The new 'mxupdate' adds
	the ability to save and restore MX network fields and EPICS PVs
	of any type, which was not the case for older versions of 
	'mxupdate'.  It also can restore values to a different variable
	than they were saved from.  As a special case, it also knows how
	to successfully save and restore EPICS motor positions by correctly
	manipulating the .SET and .VAL PVs.  Finally, by use of command
	line parameters, it is possible to use this version of 'mxupdate'
	to manually do a save and/or restore if desired, rather than just
	the automatic mode of previous versions.  Read the new man page
	'mxupdate.8' in 'mx/doc' for more information.

	Note that this new version of 'mxupdate' is not installed by default,
	but is expected to become the default version in the next release of
	MX.  If you want to install the new version of 'mxupdate' for this
	version of MX, you must manually copy it from its build location
	'/opt/mxsrc/mx/update_new/mxupdate' to '/opt/mx/sbin/mxupdate'.
	The reason it is not installed by default in this release is
	that the file format for '/opt/mx/etc/mxupdate.dat' as used by
	this new version is significantly different than the format for
	previous versions.  Read the new man page 'mxupdate.5' for more
	information.

	The MX server has had some significant speed improvements.  The
	server now immediately handles many events that used to be put
	on a queue for later execution in older versions of 'mxserver'.
	In addition, MX server no longer has a call to mx_usleep(500) in
	the main event loop, since this mx_usleep() call often was expanding
	out to a time much longer than 500 microseconds.  If you find yourself
	needing to intentionally slow the MX server back down, there is a
	new -n option to 'mxserver' that allows you to manually specify a
	delay in microseconds for the event loop.

	Much of the event handling code that used to be in the MX server
	directory tree has been move to libMx.  This has been done since
	future versions of MX plan to make the event handling infrastructure
	useable from client or standalone programs, rather than just from
	servers as at present.  The class specific event handler code has
	been moved to files with names fitting the pattern 'mx/libMx/pr*.c'.
	More generic parts of the event handler infrastructure have been
	moved to a new file 'mx/libMx/mx_process.c'.  I expect there to be
	more changes to this code in MX 2.0, so do not rely on the details
	of the current behavior.

	As usual, a variety of new drivers have been added to this version
	of MX.  This raises the total number of drivers in MX to 417.

	New drivers:
		Keithley 2000 series multimeters:
		  These drivers have been tested with a Keithley 2010 unit.

			keithley2000 - This driver controls the multimeter.
			keithley2000_ainput - This driver reads out the
				measured input as an MX analog input.

		Keithley 2400 series multimeters:

			keithley2400_amp - This driver adds the ability to
				control the range of the multimeter to the
				already existing set of MX Keithley 2400
				drivers.

		Kohzu SC-200/400/800 series of motor controllers:

			kohzu_sc - This driver manages the operation of the
				controller as a whole.
			kohzu_sc_motor - This driver controls one motor axis
				of an SC-200/400/800 series controller.

		mcu2 - This driver controls an individual motor axis
			of an Advanced Control Systems MCU-2 controller.

		network_gpib - Used for communicating with GPIB interfaces
			controlled by remote MX servers.  It is analogous
			to the existing 'network_rs232' for remote RS-232
			ports.  At present, there is no GPIB analog of the
			'mxserial' program for serial ports.  However, the
			'motor' program has a 'gpib' command that can be used
			to communicate with the ports via a 'motor' prompt.

		p6000a - Reads measurements from a Newport Electronics P6000A
			controller as an analog input.

		New Focus Picomotor controllers:

			picomotor_controller - This driver manages
				communication with the Picomotor controller.
			picomotor - This motor driver controls an individual
				Picomotor.
			picomotor_ainput - This driver reads from Picomotor
				analog input channels.
			picomotor_dinput - This driver reads from Picomotor
				digital input channels.
			picomotor_doutput - This driver writes to Picomotor
				digital output channels.

		Precision MicroControl motor controllers (using the
		  vendor-provided MCAPI interface library):

			pmc_mcapi - This driver initializes and shuts down
				the MCAPI interface to the controller.
			pmc_mcapi_motor - This driver controls an individual
				motor axis of a PMC controller.
			pmc_mcapi_ainput - This driver reads from an analog
				input port of a PMC controller.
			pmc_mcapi_aoutput - This driver writes to an analog
				output port of a PMC controller.
			pmc_mcapi_dinput - This driver reads from a digital
				input port of a PMC controller.
			pmc_mcapi_doutput - This driver write to a digital
				output port of a PMC controller.

		record_field_motor - This driver is a pseudomotor that 
			implements its functionality by reading from and
			writing to MX record fields belonging to other
			MX records.

		roentec_rcl_mca - This is an MCA driver for Roentec MCAs that
			use the RCL 2.2 command language.

		Stanford Research Systems SR630 16 channel thermocouple reader:

			sr630 - This driver manages communication with the
				SR630 controller.
			sr630_ainput - This driver reads from an individual
				SR630 thermocouple input channel.
			sr630_aoutput - This driver writes to an individual
				SR630 voltage output.

		Data Track Tracker Process Measurement and Control instruments:

			tracker_ainput - Reads from a Tracker analog input.
			tracker_aoutput - Writes to a Tracker analog output.
			tracker_dinput - Reads from a Tracker digital input.
			tracker_doutput - Writes to a Tracker digital output.

	Also, there were several new drivers written for this release of
	MX that for various reasons have not had a chance to be tested yet.
	These drivers are included in this release with the proviso that
	they are not guaranteed to work yet:

		X10 Firecracker (CM17A) home automation controllers:

			cm17a - This driver is the interface to the actual
				controller.
			cm17a_doutput - This is a digital output driver
				for controlling the device located at a
				particular X10 house code and device code.

		Black Cat Systems GM-10, GM-45, GM-50, and GM-90 Geiger
		  counters:

			gm10_scaler - This scaler driver reports the counts 
				recorded by an individual GM-xx detector.
			gm10_timer - This timer driver manages the counting
				of 1 or more GM-xx Geiger counters.

		Pfeiffer TPG 261 or 262 vacuum gauge controllers:

			tpg262 - This driver manages communication with
				the controller.
			tpg262_pressure - This driver reads the pressure
				from an individual gauge.

	A small number of drivers have been deleted in this release of MX:

		aps_10id_motor - This driver was replaced at APS Sector 10
			by the 'monochromator' driver a long time ago, so
			we have deleted this no longer used driver.

		compumotor_trans - This driver was the ancestor to the
			more general 'translation_mtr' driver.  The 
			'translation_mtr' driver is capable of supporting
			all the features in the 'compumotor_trans' driver
			and is not restricted to Compumotor controllers,
			so it is time to delete this driver.  The record
			description format for the 'translation_mtr' driver
			is identical to that of the 'compumotor_trans'
			driver, so all you should need to do to convert is
			to change the name of the device type in the record
			description from 'compumotor_trans' to
			'translation_mtr'.

		xia_mds - This driver for X-ray Instrumentation Associates
			MCAs has been made obsolete by the 'xia_xerxes' and
			'xia_handel' drivers.

	MX now has support for checking for memory leaks via the following
	new functions:

		mx_get_system_meminfo() - reports information about memory
			usage of the computer as a whole.

		mx_get_process_meminfo() - reports information about memory
			usage of the specified process.

	The amount of information available varies depending on which
	supported OS platform you are using.  Several memory leaks in MX
	were found and fixed using these functions.

	MX now has a set of functions for managing mutexes.  These include
	mx_mutex_create(), mx_mutex_destroy(), mx_mutex_lock(),
	mx_mutex_unlock() and mx_mutex_trylock().  So far, only Pthreads
	versions of these routines have been implemented.  Also, they are
	not yet usable as recursive mutexes.

	When used in an MX server, the MX driver class 'gpib' now has support
	for being remotely accessed directly by MX client programs.  This was
	motivated in part by the addition of the new 'network_gpib' driver.
	However, this support is also accessible directly via shell commands
	like

		mxput hutch1:gpib0.address 11
		mxput hutch1:gpib0.putline '*IDN?'
		mxput hutch1:gpib0.getline
		"KEITHLEY INSTRUMENTS INC.,MODEL 2400,0685035,C11   Oct 10 1997 09:51:36/A02  /F/E"

	Although direct remote access to RS-232 and GPIB ports is often useful,
	it is also important to be able to prevent such access, since in many
	cases such access can bypass restrictions set in MX drivers that make
	calls into the RS-232 and GPIB drivers.  For this reason, the 
	'rs232_flags' field of MX RS-232 records and the 'gpib_flags' field
	of MX GPIB records now have a new bit defined (0x80000000) that if set
	denies direct remote access to the specified interface.  If this bit
	is set, remote clients can only access the interfaces indirectly via
	the records defined in the MX server's database.  For example, this
	would mean that a client could command a motor to move via the 
	motor driver, but it would not be able to send raw commands directly
	to the motor controller.

	The MX RS-232 driver class now has two new functions called
	mx_rs232_get_signal_bit() and mx_rs232_set_signal_bit() which can
	be used to get and set the state of individual pins on the RS-232
	connector.

	The MX 'tty' driver for Unix systems has been modified to initialize
	the serial port using port settings like those used by Kermit.
	Kermit has a long history of interoperating with a wide variety of
	RS-232 devices, so this change should improve the compatibility of
	the MX 'tty' driver with a wider range of RS-232 devices.

	Other modifications to the 'tty' driver include:
	    Support for mark and space parity on systems that support them.
	    A new 'rs232_flags' bit for leaving the RS-232 port settings
	        alone when connecting.
	    The driver can now use FIONREAD to determine the number of
	        input characters available on platforms known to support
		this (currently only enabled for Linux).

	The 'win32_com' RS-232 driver has added the ability to get and set
	the state of the individual RS-232 connector pins.  The other drivers
	already able to do this are the 'tty' and 'vxworks_rs232' driver.

	The RS-232 routine mx_rs232_input_is_available() has been replaced
	by a new function mx_rs232_input_num_input_bytes_available().  The
	old function merely reported the fact that 1 or more bytes of input
	were available, while the new function attempts to report the number
	of bytes that are available.  If the low level driver for a given
	type of RS-232 interface does not have a way of knowing how many
	bytes are available, it will merely report that 1 byte is available.
	Currently, the drivers capable of reporting the actual number of
	bytes available are:

	    network_rs232
	    tty            - only verified and configured for Linux so far.
	    wago750_serial
	    win32_com

	Support will be added for other platforms as time permits.  Note that
	while the MX drivers that used mx_rs232_input_is_available() have all
	been modified to use the new function, many of them currently just
	check to see that the value is nonzero.

	The MX EPICS interface for EPICS 3.14 has been rewritten so that it
	uses preemptive callbacks.  At present, all the callback routine
	does is set a flag to indicate that the callback has occurred.  This
	change should allow MX to correctly interoperate with EPICS 3.14.5
	and above.  This new version of the interface replaces and makes
	unnecessary the 'virtual circuit unresponsive' workarounds present
	in MX 1.0.2.

	mx_create_record_from_description() now enforces the restriction
	of MX record names to 15 characters or less at a very early stage
	in the creation of a record.  Some 16 character record names that
	managed to slide through in older versions of MX will now be 
	disallowed since such record names may trigger core dumps in certain
	situations.  This may affect some user's 'scan.dat' files.  If it
	is any consolation, I expect to raise the length limit for MX record
	and field names to something like 80 characters by the time we get
	to MX 2.0.

	MX scan records that reference nonexistent MX records are no longer
	deleted when the scan database is loaded and are preserved so that
	they can be written out unchanged to new scan database files.  However,
	although the scan records are in the database, MX prevents application
	programs from using such broken scans in any way other than to write
	them back out again to a 'scan.dat' type file.  This was done since
	some beamlines have devices that are not always available and
	installed in the device database.  Previous versions of MX made it
	hard to keep around scans that used devices that are only present
	some of the time.

	Support for the old Mesa Data Server has been dropped from the MX
	X-ray Instrumentation Associates (XIA) MCA drivers.  All of our
	users are either using Handel or Xerxes based drivers at this point.

	The MX XIA DXP MCA drivers have added new support for the following
	operations:
		get_baseline_array
		set_gain_change
		set_gain_calibration
		get_acquisition_value
		set_acquisition_value
		get_adc_trace_array
		get_baseline_history_array

	The 'xia_handel' driver has added the ability to save a Handel
	configuration file that matches the current configuration.  You
	can access this feature by writing the name of the new configuration
	file to the 'save_filename' field of the 'xia_handel' record.

	MX MCA support has added several new functions:

		mx_mca_get_energy_scale(), mx_mca_set_energy_scale,
		mx_mca_get_energy_offset(), mx_mca_set_energy_offset,
		mx_mca_get_energy_axis_array()

			These functions allow the X axis to be specified
			in units of energy rather than channel number.

		mx_mca_get_input_count_rate(), mx_mca_get_output_count_rate()

			These functions can now report the input or output
			count rate for any MCA whose MX driver supports this.
			Previously, functionality like this was only available
			for XIA MCAs.  Also note that the 'mca_value' MX
			driver has been enhanced to be able to report the
			input or output count rates.

	The record description for MX MCS drivers has been change to add a
	new field called 'external_channel_advance_name' before the 
	'external_channel_advance'.  This allows one to specify an optional
	external channel advance source and be able to change the identity
	of the source at run time.  Preexisting MX database record description
	lines that look like this

sis3801 device mcs sis3801 "" "" 32 2000 0 0 timer1 vme1 a16 0 0x3800 0x6 0x0

	will need to be changed to look like this

sis3801 device mcs sis3801 "" "" 32 2000 "" 0 0 timer1 vme1 a16 0 0x3800 0x6 0x0

	if you are not using the external channel advance feature.

	The 'sis3801' MCS driver now determines the size of the module's
	internal FIFO at driver initialization time.  For diagnostic purposes,
	it now also turns on the User LED when the MX driver connects to the
	3801 and then then turns it back off when the MX driver shuts down.
	The 'sis3801' driver has also added code to support external channel
	advance by a pulse generator, but this feature does not yet work for
	reasons that are not clear.

	A number of enhancements have been made to the 'sis3807' pulse
	generator driver in support of its use as an external channel advance
	for the SIS3801.  Other changes have been made to ensure that the
	pulse generator is correctly initialized and that its status is 
	correctly updated.

	The 'sis3100' VME interface driver has been modified to verify at
	run time that the major number of the character device node for the
	driver matches the major number for the driver reported by
	/proc/devices.  This should have the effect of reducing the chance
	of accidental misidentification of the major number.  The driver
	now also turns on the User LED at startup and turns it off at 
	shutdown for diagnostic purposes.

	The 'compumotor' driver has been modified to store raw values from
	the Compumotor controller as double precision variables rather than
	as long integers.  This should always have been the case for
	Compumotor 6K controlled motors, since they can return non-integer
	motor positions, but this had somehow been overlooked until now.

	The 'delta_motor', 'energy_motor', 'wavelength_motor', and
	'wavenumber_motor' drivers have been modified to make use of the more
	efficient 'get_status' and 'get_extended_status' driver functions
	rather than the old busy, positive, and negative limit hit functions.

	When checking to see if a limit has been hit, the 'epics_motor' driver
	now checks for soft limit violations via the LVIO PV in addition to
	checking the hardware limits.

	The 'epics_mcs' driver has been modified to start data acquisition
	with the EraseStart PV rather than the StartAll PV if the EPICS MCA
	driver in use is version 6.0 or higher.

	The 'pfcu_filter_summary' driver for X-ray Instrumentation Associates
	PFCU filter modules has been corrected to fix some minor errors in
	the commands being sent by the MX driver to the XIA module.

	Made a minor change to the 'am9513_motor' driver to get more reliable
	single stepping.

	The MarDTB drivers have been modified to take into account a change
	in the format of the 'status_dump' command used by the MarDTB's
	internal operating system.

	The 'mx/libMx/i_ni488.c' file has tentatively been modified to
	work with the linux-gpib.sourceforge.net GPIB driver.  This driver
	is apparently the replacement for the old Linux Lab Project driver.
	These changes have not yet been tested with a real controller though.

	In 'motor', the pause request handler for scans has added a new
	option 'stop motors at the end of current step' to the preexisting
	options of 'continue scan' and 'immediate abort'.

	The startup for 'mxserver' running on 'win32' and 'win32-borland'
	platforms has been changed to ensure that stdout and stderr for
	the MX server are always unbuffered.  This was done to make it 
	easier to use a Win32 compiled 'mxserver.exe' from a remote
	Cygwin SSH session.

	The SFF datafile driver for MX scans has been modified to put a
	comment character '#' at the start of each of the header lines.
	This was done to make it easier to use SFF format files directly
	in programs like Gnuplot.  The plotting scripts bundled with the
	MX base distribution have been modified to support SFF file headers
	either with or without the comment charactes.

	The driver for the Oxford Instruments ITC503 temperature controller
	now resynchronizes the serial port when connecting for the first time
	and waits for 1 second for the resynchronization to complete.

	Two new utility routines have been added, namely, mx_copy_file()
	and mx_get_current_directory_name().

	Support for compiling MX on Linux with the Borland Kylix C++ compiler
	has been deprecated, since the vendor seems to have lost interest
	in the product.

	On Irix, ULONG_MAX can be too large to fit into a 32 bit integer.
	For this reason, new macros called MX_ULONG_MAX and MX_LONG_MAX
	have been defined in mx/libMx/mx_constants.h which are safe to 
	be used with 32 bit integers.

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

Version 1.1.0 (07/13/05):
	The Mp.Variable class methods write and send_variable no longer
	require single object arguments passed to them to be converted to
	a 1-element tuple by the calling script.  In addition, if the 
	methods read and receive_variable are about to return a 1-element
	tuple to the caller, they unpack the tuple and directly return
	the object inside to the caller.  This means that a method call
	like

		d = d_spacing_variable.read()

	now returns a value like 3.13555 rather than the previous behavior
	of returning (3.13555,).

	MP now defines its own set of Python exceptions that are returned
	when MX returns an error code.  There is a 1-to-1 mapping between
	MX errors and MP exceptions.  For example:

		MXE_ILLEGAL_ARGUMENT	-->  Mp.Illegal_Argument_Error
		MXE_NOT_READY		-->  Mp.Not_Ready_Error

	Added new methods to the Mp.MCA class called get_soft_roi_integrals,
	get_energy_scale, set_energy_scale, get_energy_offset, 
	set energy_offset, get_energy_axis.  Except for the first one, all
	of these methods were added to support displaying MCA spectra with
	an X axis in units of energy rather than channel number.

	Added new methods to the Mp.Motor class called get_status and
	get_extended_status which directly call the underlying MX functions
	mx_motor_get_status() and mx_motor_get_extended_status().

	Added support for scan pause request handlers.  These handlers allow
	the user to pause a scan in progress and then optionally resume the
	scan.

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

Version 1.1.0 (07/13/04):
	Added support for an Mx::MCA class to MxTcl.  This class supports
	all of the same methods that are supported by Python-based MP.

	Added new methods to the Mx::Motor class called get_status and
	get_extended_status.

	Scanning in 'mxgui' now supports creating, editing and running
	MX quick scans and list scans.

	Added support for scan pause request handlers.  These handlers allow
	the user to pause a scan in progress and then optionally resume the
	scan.

******************************* Mxserial ***********************************

Version 1.1.0 (07/13/05):
	Minor changes were made to make 'mxserial' compatible with MX 1.1.0.

************************* MX MarCCD Interface ******************************

Version 1.1.0 (07/14/05):
	Updated for changes to MX RS-232 support.  In addition, the command
	for opening and closing the shutter has currently been disabled.

******************************* Imcagui ***********************************

Version 1.1.0 (07/14/05):
	Imcagui now uses a tabbed notebook layout with the following tabs:

		Beam - This tab corresponds to the original main window.  The
			APS 17-BM version has added a beam position monitor
			display, shutter open/close controls, and new controls
			and display for the new monochromator feedback system.
		MAD - This tab contains the same displays as old MAD window.
		Optimize & Staff Optimize - These tabs contain the controls
			from the old optimize and optimize_auto programs.
			These tabs work by loading routines from the 'optimize'
			and 'optimize_auto' packages which _must_ be installed
			for the tabbed notebook version of Imcagui to work.
		Staff - This tab contains staff-only controls for changin
			the edge energy and buttons for starting the external
			'mxgui', 's17bm', and 'motor' programs.  In addition,
			there are buttons for accessing the storage ring
			status, steering status, and feedback control MEDM
			screens.
	Note that the old multiwindow version of Imcagui is still available
	by invoking Imcagui by the name 'old_imcagui'.

******************************* Optimize ***********************************

Version 1.1.0 (07/14/05):
	Made minor modifications to be compatible with use of this code
	by the new tabbed notebook version of 'imcagui'.  Also modified
	the APS 17-BM beamline specific code to interlock with the new
	monochromator feedback system there.

***************************** Optimize Auto *********************************

Version 1.1.0 (07/14/05):
	Minor changes to permit the use of the optimize_auto code in the new
	tabbed notebook version of 'imcagui'.




More information about the Mx-mailing-list mailing list