[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