[Mx-mailing-list] MX 1.5.0 is available
Bill Lavender
lavender at agni.phys.iit.edu
Sun Nov 16 22:10:06 CST 2008
Versions 1.5.0 of MX, MP, and MxTcl are now available at the MX web site
from the download page
http://mx.iit.edu/source.html
There have been a large number of features added since MX 1.4.3. The most
important ones are:
Full software support for several Aviex area detectors.
New support for MX event callbacks. At this time, poll callbacks,
value-changed callbacks, motor backlash callbacks, and function
callbacks are supported.
However, you should read the changelogs below for the full list of changes.
This release also introduces two new packages:
MpWx - This is set of WxPython-based GUI classes for widgets that
monitor or change the values of MX network variables. The initial
set of classes include:
MpWx.Value - Monitors the value of an MX network variable.
MpWx.ValueEntry - Provides a text entry widget for users to
change the value of an MX network variable.
MpWx.Choice - Provides a choice control for users to select
from a list of values and then send that value to MX.
MpWx.RadioBox - Provides a radiobox control for users to select
from several possible values and then send that value to MX.
MX Blu-Ice Server - This package provides a Blu-Ice DHS and/or DCSS
server interface for MX controlled devices. It provides full DHS
and partial DCSS support for exporting MX devices as Blu-Ice
area detectors, motors, shutters, ion chambers, strings, and
operations. It also supports Blu-Ice style motor scans and
area detector runs.
I would like to finish by thanking Jim Fait, Ken McIvor, and Henry Bellamy
for their contributions to this release.
Bill Lavender
**************** Changelog for MX version 1.5.0 ****************
Version 1.5.0 (11/15/08):
A major feature of this release is full functionality for the
PCCD-170170 area detector from Aviex LLC. The detector is designed
for acquisition of small-angle X-ray scattering (SAXS) data inside
a vacuum chamber. The detector system now supports full framed and
binned mode, multiframe sequences, circular multiframe sequences,
streak camera sequences, and subimage sequences. This detector
is currently in use at the SWING beamline of Synchrotron SOLEIL
near Paris, France.
The same software package was used for bench testing of an Aviex
PCCD-4824 detector that was delivered to ESRF. Also, it is now in
the process of being modified to control an Aviex PCCD-16080 detector
that is located at the BioCAT beamline of the Advanced Photon Source.
This release of the Aviex CCD code use the smvspatial() package
to perform geometric correction of the CCD images. This package
of functions was written by Andy Howard and was derived from his
X-GEN data processing package for crystallographic area detector
data. You can find out more information about X-GEN at the
following web site
http://xgen.iit.edu/
The old MX CCD driver class has now been replaced by the new
MX Area Detector class and the old MX CCD drivers are in the
process of being converted to the new Area Detector class.
---------------------------------------------------------
New support has been added for event callbacks in MX servers. For
this release, event callbacks are not enabled by default. If you
want server callbacks, you must add the command line argument '-c'
to the 'mxserver' command line. In later MX releases, event
callbacks will be enabled by default.
So far the following kinds of callbacks have been implemented:
Poll callback - This is a callback that periodically
reads values from MX server controlled hardware. This
callback sends 'value changed' callbacks to MX clients
that have requested them. The hardware is only polled
if a client has requested 'poll' callbacks for that
device. Otherwise the hardware is not polled.
Value changed callback - This kind of callback is sent to
an MX client if a poll callback finds that the change
in the current value of the field exceeds the value change
threshold. Value changed callbacks can also occur as
side effects of MX get and MX put calls.
Most record fields will use a default test function with
the obvious name of mx_default_test_for_value_changed().
However, it is possible to override the default test
for individual record fields, which is done automatically
for motor and area detector records.
For motors, the 'position', 'status', and 'extended_status'
fields are tested using the mx_motor_vctest_extended_status()
function. mx_area_detector_vctest_extended_status() is
used by area detector records for the 'last_frame_number',
'total_num_frames', 'status', and 'extended_status' fields.
Motors and area detectors use special test functions for
these fields since the values of the associated fields
are coupled with each other.
Backlash callback - If an MX client tells the MX server to
move a motor and the move will require backlash correction,
the MX server no longer blocks all MX clients until the
backlash correction is complete. Instead, the MX server
starts the move to the backlash position and then schedules
a backlash callback to be invoked at a later date.
When the backlash callback is invoked, it checks to see
if the backlash move has completed. If the move has
completed, the backlash callback starts the main move
and then exits. If the move is _not_ complete, then
the backlash callback reschedules itself to be invoked
at a later date.
Function callback - This is a relatively generic kind of
callback. For this kind of callback, application code
must setup and start an MX virtual timer, with the
function mx_callback_standard_vtimer_handler() as the
callback function and a pointer to an MX_CALLBACK_MESSAGE
structure as the callback argument. When invoked,
mx_callback_standard_vtimer_handler() will arrange for
the application code's callback function to be invoked.
If the application wants the callback to be invoked
periodically, then the application's callback function
is responsible for rescheduling the next invocation
of the callback.
At present, function callbacks are used by the new MX
area detector class to implement asynchronous dark
current and flood field measurements. If asynchronous
messages of this sort are used, the area detector code
does not block until the dark current or flood field
measurement is complete. Instead, it sets a bit in
the area detector's status word so that clients can
tell when the correction measurement sequence completes.
A test program 'mx/test/features/callback_test/vcc_monitor.c'
has been provided to test the operation of value changed
callbacks. If you start the test program with a command line
like
./vcc_monitor omega.position
the program will display value changed callbacks for the field
'omega.position' for an MX server running on 'localhost' at
port 9727. If instead you use a command line like
./vcc_monitor ida at 9827:theta.position
then, the program will display all value changed callbacks that
are sent for the field 'theta.position' for an MX server running
on the machine 'ida' at port 9827.
The new API functions used to implement 'vcc_monitor' are
mx_remote_field_add_callback() - This asks an MX server to
set up a value changed callback for the specified
network field with a programmer supplied callback function.
mx_network_wait_for_messages() - This function waits for
messages to arrive from any connected MX server until
the specified timeout expires. Any callback messages
sent by the remote server will trigger the matching
local callback function when they arrive.
Other useful new functions include
mx_remote_field_delete_callback() - This deletes a callback
created by mx_remote_field_add_callback().
mx_network_wait_for_messages_from_server() - This is just
like mx_network_wait_for_messages() except for the fact
that it only looks for messages from a particular MX
server.
mx_network_wait_for_message_id() - This function waits for
messages from the specified MX server until either a
message with the specifed message id shows up, or the
specified timeout expires. This can be useful if you
are interested in waiting until a particular callback
message is sent.
---------------------------------------------------------
MX now has a new Waveform Output class. Initially, it is used
by the new MX drivers for the BK Precision 912x series of
programmable power supplies. These drivers are described further
in the next section. In addition, there is also a new 'wvout'
command for 'motor' that can be used to control the output
waveform.
---------------------------------------------------------
New MX device drivers:
Please note that the 'ilm', 'cryojet', and 'itc503' drivers family
of drivers were partially based on code contributed by Henry Bellamy
of CAMD at LSU.
Analog I/O drivers:
bkprecision_912x_ain - Returns the voltage, current,
power, dvm, or resistance reported by the
corresponding 'MEASURE:xxx?' command.
bkprecision_912x_aout - Can be used to switch the power
supply into fixed mode and then either set the
voltage or the current.
bluice_dcss_ion_chamber - Returns values reported by the
Blu-Ice DCSS message 'stog_report_ion_chambers'.
bluice_dhs_ion_chamber - Returns values reported by the
Blu-Ice DHS message 'htos_report_ion_chambers'.
cryojet_ainput - Reports internal parameter values of
the Oxford Instruments Cryojet temperature
controller via the 'R' command.
cryojet_aoutput - Can be used to set the values of the
derivative action time 'D', integral action time
'I', shield flow 'J', sample flow 'K', heater
output 'O', proportional band 'P', or temperature
setpoint 'T' for an Oxford Instruments Cryojet
temperature controller.
ilm_ainput - Reports internal parameter values of the
Oxford Instruments ILM (Intelligent Level Meter)
controller via the 'R' command.
itc503_ainput - Reports internal parameter values of
the Oxford Instruments ITC503 temperature
controller via the 'R' command.
itc503_aoutput - Can be used to set the values of the
derivative action time 'D', gas flow 'G',
integral action time 'I', heater output 'O',
proportional band 'P', or temperature setpoint 'T'
for an Oxford Instruments ITC503 temperature
controller. This driver replaces the old
'itc503_control' driver.
spellman_df3_ain - Reports internal parameters of the
Spellman DF3/FF3 series of high voltage power
supplies for X-ray generators via the Query 'Q'
command.
spellman_df3_aout - Sets internal parameters (voltage,
current, power, filament current) of the
Spellman DF3/FF3 series of high voltage power
supplies for X-ray generators via the Set 'S'
command.
Area Detector drivers:
bluice_dcss_area_detector - Communicates with a Blu-Ice
DCSS controlled area detector via the collectFrame
operation.
bluice_dhs_area_detector - Communicates with a Blu-Ice
DHS controlled area detector via the
detector_collect_image family of operations.
pccd_170170 - This driver for the Aviex PCCD-170170 is
now fully functional.
pccd_4824 - Driver for the Aviex PCCD-4824 area detector.
pccd_16080 - Driver for the Aviex PCCD-16080 area detector
at the BioCAT sector of the Advanced Photon Source.
marccd - Acts as the remote mode server for a MarCCD
detector. It is started from the 'Server Command'
field of the Remote mode dialog box.
marccd_server_socket - Communicates with the example
remote mode server 'marccd_server_socket' that
is provided with MarCCD.
Camera Link drivers:
camera_link_api - This driver dynamically loads a vendor
supplied Camera Link DLL or shared library and
then exports it to MX clients using the MX
Camera Link API.
soft_camera_link - This driver provides a software
emulated Camera Link serial interface.
Controller drivers:
bkprecision_912x - This driver controls BK Precision 912x
series programmable power supplies.
cryojet - This driver controls Oxford Instruments Cryojet
temperature controllers.
itc503 - This driver controls Oxford Instruments ITC503
temperature controllers.
ilm - This driver controls Oxford Instruments ILM
(Intelligent Level Meter) controllers.
spellman_df3 - This driver controls the Spellman DF3/FF3
series of high voltage power supplies.
Digital I/O drivers:
bkprecision_912x_din - Reports the status from the
'DIGITAL:INPUT?' command for the BK Precision 912x
series of power supplies.
bkprecision_912x_dout - Sets the digital outputs of the
BK Precision 912x power supply using the
'DIGITAL:OUTPUT' command.
cryojet_doutput - This driver can be used to control the
auto/manual setting 'A' and the local/remote/lock
setting 'C' for Oxford Instruments Cryojet
temperature controllers.
epix_xclib_dinput -
epix_xclib_doutput - These are digital I/O drivers for
digital input and output ports attached to video
imaging boards from EPIX, Inc.
ilm_sample_rate - This driver can be used to change the
sample rate for an Oxford Instruments ILM
(Intelligent Level Meter) controller.
ilm_status - This driver reports nitrogen, helium, or
relay status for the Oxford Instruments ILM
(Intelligent Level Meter) controllers.
itc503_doutput - This driver can be used to control the
auto/manual setting 'A' and the local/remote/lock
setting 'C' for Oxford Instruments ITC503
temperature controllers.
spellman_df3_din - Reports internal parameters of the
Spellman DF3/FF3 series of high voltage power
supplies for X-ray generators via the Query 'Q'
command.
spellman_df3_dout - Sets internal parameters (X-ray on,
X-ray off, power supply reset) of the
Spellman DF3/FF3 series of high voltage power
supplies for X-ray generators via the Set 'S'
command.
u500_status - Returns the value reported by the function
WAPIAerReadStatus().
Interface drivers:
isobus - This driver communicates with data acquisition
and control hardware over the Oxford Instruments
ISOBUS.
Motor drivers:
bluice_dcss_motor - Controls a Blu-Ice motor via a Blu-Ice
DCSS server.
bluice_dhs_motor - Controls a Blu-Ice motor via a Blu-Ice
DHS server.
cryojet_motor - This driver controls the temperature setpoint
of an Oxford Instruments Cryojet temperature controller
as if it were a motor.
cubic_spline_motor - This pseudomotor driver is used to
move a dependent motor record to a position that
is a clamped cubic spline function of the requested
pseudomotor position. The MX record description
in the MX database specifies the name of the
dependent record and a pair of 1-dimensional
array records that contain the X and Y positions
used to define the cubic spline. The most typical
use of this pseudomotor is as a dependent motor
in an MX 'monochromator' record.
itc503_motor - This driver controls the temperature setpoint
of an Oxford Instruments ITC503 temperature controller
as if it were a motor. This is a significant rewrite
of the old 'itc503_motor' driver to communicate with
the controller via the new 'itc503' and 'isobus'
drivers.
polynomial_motor - MX pseudomotor driver that uses a
polynomial to compute the position of a dependent
motor. The most typical use of this pseudomotor
is as a dependent motor in an MX 'monochromator'
record.
src_mono - MX motor driver for monochromators at the
Synchrotron Radiation Center (SRC) of the
University of Wisconsin-Madison.
Relay drivers:
bluice_dcss_shutter - This driver sets the position of
a Blu-Ice DCSS controlled shutter via the
gtos_set_shutter_state message.
bluice_dhs_shutter - This driver sets the position of
a Blu-Ice DHS controlled shutter via the
stoh_set_shutter_state message.
marccd_shutter - This driver can control the state of the
shutter of a MarCCD detector. However, if software
external to MX changes the state of the detector,
then the MX driver cannot detect that this has
happened.
RS-232 drivers:
edt_rs232 - This driver provides access to serial ports
on video imaging boards from EDT.
epix_rs232 - This driver provides access to serial ports
on video imaging boards from Epix, Inc.
u500_rs232 - Used to upload programs to the Aerotech
Unidex 500 series of motor controllers. U500
programs can send back responses to the MX driver
using the custom 'MX' macro implemented in the
mxi_u500_rs232_putline() function of the driver.
Scan drivers:
wedge_scan - Runs an area detector wedge scan with support
for inverse beam and multiple X-ray energies. The
scan uses the Run Sequence order described near the
bottom of the page
http://smb.slac.stanford.edu/public/facilities/
software/blu-ice/collect_tab.html
Server drivers:
bluice_dhs_manager -
bluice_dhs_server - These two drivers work together to
manage connections between an MX-based DCSS process
and the Blu-Ice DHS processes that connect to it.
The 'bluice_dhs_manager' driver manages the server
socket that Blu-Ice DHS processes use to connect to
the MX-based DCSS. After a DHS process has connected
to the MX-based DCSS, the 'bluice_dhs_manager'
driver passes control of the new socket off to an
instance of the 'bluice_dhs_server' driver. After
this point is reached, sockets belonging to
'bluice_dhs_server' instances are treated essentially
the same as sockets belonging to 'bluice_dcss_server'
instances.
String drivers:
bluice_dcss_operation - Controls a Blu-Ice 'operation'
running on a Blu-Ice DCSS server.
bluice_dhs_operation - Controls a Blu-Ice 'operation'
running on a Blu-Ice DHS server.
bluice_self_operation - Controls a Blu-Ice 'operation'
running in the current process.
bluice_dcss_string - Reads the value of a Blu-Ice string from
a Blu-Ice DCSS server.
bluice_dhs_string - Reads the value of a Blu-Ice string from
a Blu-Ice DHS server.
bluice_self_string - Reads the value of a Blu-Ice string in
the current process.
Timer drivers:
bluice_dcss_timer - This driver starts an ion chamber
measurement by sending a 'gtos_read_ion_chambers'
message to a Blu-Ice DCSS.
bluice_dhs_timer - This driver starts an ion chamber
measurement by sending an 'stoh_read_ion_chambers'
message to a Blu-Ice DHS.
Variable drivers:
file_double -
file_long -
file_string -
file_ulong - These drivers provide read and optionally
write access to operating system files. They
were originally developed for use with Linux
/proc and /sys files, but they can be used with
other things such as named pipes.
Video input drivers:
file_vinput - This is a video input driver that reads
individual video frames from a set of image files
in a user specified directory. The primary
intended use for this driver is to provide frames
for a simulated area detector.
Waveform Output drivers:
bkprecision_912x_wvout - Generates a waveform output from
the BK Precision 912x series of power supplies.
network_wvout - Controls the output of a waveform output
record in a remote MX server.
---------------------------------------------------------
Blu-Ice:
A significant amount of work has been done to expand the
interface between Blu-Ice and MX. New drivers and a new server
have been written to let MX code play any of the following four
roles:
1. MX acting as a Blu-Ice GUI client.
2. MX acting as DCSS for one or more Blu-Ice DHS processes.
These two cases are handled by the new MX drivers listed
in the previous section. The drivers that start with
'bluice_dcss_' are used when MX is playing role 1, while
the drivers that start with 'bluice_dhs_' are used when
MX is playing role 2.
3. MX acting as DCSS for one or more Blu-Ice GUI clients.
4. MX acting as a DHS that connects to a Blu-Ice DCSS.
These two cases are handled by the separately distributed
'mx_bluice_server' package. You can find this package
on the MX web site as the file
http://mx.iit.edu/src/mx_bluice_server.tar.gz
or on the CSRRI Subversion server at
http://svn.csrri.iit.edu/mx_bluice_server
Please note that it is possible for a given MX process to play
more than one of the above four roles at the same time, which
may be useful under certain circumstances.
---------------------------------------------------------
New record field attribute feature:
MX network field records now have support for record field
attributes. These attributes provide a way of modifying the
behavior of individual record fields at run time. The initial
set of attributes are:
MXNA_VALUE_CHANGE_THRESHOLD:
This attribute allows one to both read and modify the
value change threshold for individual record fields.
For example, if the value change threshold for a given
record field is set to 2.5, then a value changed callback
will only occur if the value of the field has changed by
2.5 or more since the last time that the field sent out
a value changed callback.
MXNA_POLL:
This attribute can be used to set or clear the MXFF_POLL
flag in an MX record field. If this flag is not set, then
a poll callback will not attempt to read a new value from
the hardware before checking to see if the value of the
record field has changed.
MXNA_READ_ONLY:
This attribute reports whether or not a given record field
is read only. It is not possible for an MX network client
to change this attribute.
A pair of test programs called 'mxattr_get' and 'mxattr_set' are
provided in the 'test/features/attribute_test' directory to show
how to make use of these attributes.
---------------------------------------------------------
Added new 'custom' datafile and plot drivers. The purpose of these
drivers is to allow an application program to intercept the datafile
and plot output from an MX scan and send them instead to functions
specified by the application program. For example, by using a
'custom' plot type in the scan description, the plot data can be
redirected to a GUI window belonging to the application window.
When used in this way, this eliminates the need to have the plotting
software be in a separate process.
Custom datafile and plot handlers are defined via the functions
mx_scan_set_custom_datafile_handler() and
mx_scan_set_custom_plot_handler(). For each of these functions,
the programmer supplies a pointer to a scan record, a pointer to
either an MX_DATAFILE_FUNCTION_LIST or an MX_PLOT_FUNCTION_LIST,
and a void pointer to an arbitrary programmer specified data
structure.
At present, the first real user of this functionality is the
'mxbl_operations.c' file of the 'mx_bluice_server' package that
is distributed separately from the core of MX. In this package,
an MX-based implementation of the Blu-Ice 'collectRun' operation
runs a hidden MX 'wedge_scan' to manage the area detector run.
Attempts by the hidden 'wedge_scan' to write to a datafile are
intercepted by the custom function
mxbl_collectRun_df_add_measurement_to_datafile() which instead
generates Blu-Ice messages to tell the client which image frame
we are on and what the current position of the motor is. The
MX-based implementation of the Blu-Ice 'scanMotor' operation
does something similar using an ordinary MX motor scan.
---------------------------------------------------------
The list head record 'mx_database' now has some new fields:
mxput 'mx_database.report_all' 'recordname' -
Shows information about all of the fields in the specified
record in the server log.
mxput 'mx_database.show_record_list' -
Shows the summary information for each record in the
server log. This generates the same type of output
that would be generated by a 'show record' command
in 'motor'.
mxput 'mx_database.show_callbacks' -
Shows a list of all of the currently configured callbacks
in the server log.
mxput 'mx_database.show_callback_id' 'callbacknumber' -
Shows more information about the specified callback
in the server log.
---------------------------------------------------------
The header file 'mx_version.h' now provides a new set of compile
time macros for testing for the versions of MX and other software
used to compile and link your program. All of the version macros
use the format of
version = 1000000 * major_version
+ 1000 * minor_version
+ update version
Thus, on one Linux machine you may get definitions like
#define MX_VERSION 1005000L
#define MX_GNUC_VERSION 3003005L
#define MX_GLIBC_VERSION 2003002L
which state that you are compiling MX 1.5.0 on a machine using
GCC 3.3.5 and Glibc 2.3.2. On another machine, you may get
#define MX_VERSION 1005000L
#define MX_GNUC_VERSION 4003002L
#define MX_GLIBC_VERSION 2007000L
which state that you are compiling MX 1.5.0 using GCC 4.3.2 and
Glibc 2.7.0 (or just 2.7). The MX_VERSION macro is defined on
all platforms, while MX_GNUC_VERSION is only defined on platforms
using GCC and MX_GLIBC_VERSION is only defined if you are using
Glibc. Other macros will be added when appropriate.
---------------------------------------------------------
A new set of functions for handling cubic splines are available
via the new 'mx_math.h' header file. The cubic spline logic
was derived from the equivalent Fortran algorithm in the book
"Numerical Methods" by Robert W. Hornbeck, Quantum, 1975.
The available spline functions are mx_create_cubic_spline(),
mx_delete_cubic_spline(), and mx_get_cubic_spline_value(). There
are also a pair of macros called mx_create_natural_cubic_spline()
and mx_create_clamped_cubic_spline() that specify typical sets of
boundary conditions for the spline. The new cubic spline code
is used by the new 'cubic_spline_motor' pseudomotor mentioned
above. The 'test/features/math_test/' directory contain example
programs for using the spline functions.
---------------------------------------------------------
Deleted the old 'network_ccd' driver, since it has been replaced
by the new 'network_area_detector' driver.
Deleted the old 'remote_marccd' driver, since it is to be replaced
by the new 'marccd' and/or 'marccd_server_socket' drivers.
Deleted the old 'remote_marccd_shutter' driver, since it is to be
replaced by the new 'marccd_shutter' driver.
Deleted some old unfinished drivers, namely, the 'als_robot_java',
'ggcs', and 'ggcs_motor' drivers.
---------------------------------------------------------
MX 1.5.0 has not been tested on HP/UX or Tru64 machines, since
I no longer have access to such machines. However, I have
attempted to update the code and makefiles for those platforms
as best as I can. Let me know if you see problems.
All of the MX header files mx_*.h have been modified to be
useable by C++ programs.
Added new MX database startup functions mx_setup_database_pointer()
and mx_setup_database_pointer_from_array(). These two functions
return the MX_RECORD pointer for the database list head record
instead of the mx_status_type object returned by something like
mx_setup_database(). This was done to make it easier for programs
like LabVIEW to communicate with MX.
A pointer test function called mx_pointer_is_valid() has been
created. The idea is that you hand mx_pointer_is_valid() a
pointer to the start of an address range to check, the length
of the range to check, and the type of access you are checking
for (read, write, execute). Platform-specific version of
mx_pointer_is_valid() have been developed for Linux, Windows,
MacOS X, Solaris, Irix, BSD, and VMS. On platforms not listed
above, all mx_pointer_is_valid() does is check to see if the
pointer is NULL. As far as I know, it is safe on all platforms
to invoke mx_pointer_is_valid() at almost any time (probably
not in signal handlers), since it does not use unsafe functions
like IsBadReadPtr(). However, in most cases, mx_pointer_is_valid()
is very slow, so you should only use it when debugging problems
with pointers. Never use it in production code.
Added a new digital input function called mx_digital_input_clear()
for use with digital inputs that latch their value. So far, it
has only been implemented for the 'epix_xclib_dinput' driver.
Added a new digital output function called mx_digital_output_pulse().
This function turns on a digital output and then, after a
programmable amount of time, turns it off again. The polarity
of the pulse is selectable.
The 'network_dinput', 'network_doutput', 'network_ainput' and
'network_aoutput' drivers have been modified so that it is now
possible to use a record field name such as 'testdev.control'.
For previous versions of the drivers only the record name such
as 'testdev' can be specified, which is expanded internally to the
record field name 'testdev.value'. You may still specify only
the record name if you want to use the remote 'value' field.
For 'network_ainput' drivers, the "server subtracts dark current"
feature is only supported if you specify only a record name such
as 'testvar' instead of specifying a record field name such as
'testvar.value'. If you use the latter form, you may still save
dark current values in the local record, but then each MX client
will have its own private version of the dark current.
A couple of bugs have been found in the handling of user interrupt
and pause requests when using the scan 'early move' feature.
Ken McIvor's patches that fix this have been applied in this
release.
The 'mxsave' and 'mxrestore' scripts have been added. These are
wrappers around the modern version of 'mxupdate' that allow the
user to manually save or restore user-specified groups of MX
database parameters. This is in addition to mxupdate's normal
automatic save and restore functionality.
An /etc/init.d style 'pixci' script has been added to support
automatic loading of the EPIX 'pixci' module on systems with
EPIX, Inc. cameras installed.
Updates have been made to the EDT video input drivers. However,
the current versions of the drivers are not yet fully functional.
Cross-platform support for anonymous pipes has been added. See
"mx_pipe.h" for the details. The new pipe functions are used by
the new event callback system described above. On POSIX systems,
pipe writes are guaranteed to be atomic for writes of less than
or equal to PIPE_BUF bytes. PIPE_BUF is guaranteed to have a
value of 512 bytes or more. On Linux, it is 4096.
Support has been added for implementing the POSIX style directory
interface (opendir, closedir, readdir, rewinddir) on non-POSIX
systems such as Microsoft Windows. Portable programs should
include "mx_dirent.h" rather than <dirent.h>.
Cross-platform support has been added for dynamically loading
DLLs and shared libraries. You can access the new functions via
the "mx_dynamic_library.h".
A new set of generic linked list handling functions has been added.
The new functions are defined in "mx_list.h".
Added a new mx_get_system_boot_time() which reports the most recent
system boot time in a 'struct timespec' structure. On some platforms,
this is used to help convert internal operating system times into
absolute times.
The mx_get_process_affinity_mask() and mx_set_process_affinity_mask()
functions have been added to control the binding of a process to
particular CPUs on multi-CPU systems. The most common reason for
setting the processor affinity is to get monotonically increasing
CPU times on multi-CPU systems where the clocks on the various CPUs
are not guaranteed to have the same value. This is an issue on
recent versions of 32-bit and 64-bit versions of x86 CPUs. Process
affinity mask support has been added for Linux, Windows, Solaris,
and Irix. Unfortunately, MacOS X does not appear to provide a way
of controlling the processor affinity.
Windows resource files for 'mxserver' and 'motor' have been added
that contain VERSIONINFO resources for the executable. Typically,
some of these will show up in Process Explorer under the Description
and Company Name columns.
**************** Changelog for MP version 1.5.0 ****************
Version 1.5.0 (11/12/08):
New classes added:
Mp.Callback - This class encapsulates references to MX callbacks
so that they can be passed to other Mp methods and functions.
New methods added:
Mp.RecordList
connect_to_mx_server() - This method connects to the MX server
at the specified hostname and port number
and then returns an Mp server object.
wait_for_messages() - This method waits for messages from
any connected server until the specified timeout expires.
Mp.Record
resynchronize() - Invokes the mx_resynchronize_record()
function on the MX record corresponding to the
Mp.Record object.
Mp.AreaDetector
get_detector_readout_time() - Reports the total time
required to read out the detector. This time may
be for a single frame or for an entire sequence
depending on the sequence type.
get_total_sequence_time() - Reports the estimated time
for the currently loaded sequence to run.
get_total_num_frames() - Reports the total number of
image frames received since the MX process was
started.
transfer_frame() - Modified to add an image_frame argument.
Mp.DigitalInput
pulse() - Generates an output pulse on a digital output
for the specified duration.
Mp.Server
wait_for_message_id() - Waits until the arrival of a
message using the supplied MX message ID or until
the timeout expires.
wait_for_messages_from_server() - Waits for messages from
a particular MX server until the timeout expires.
Mp.Net
get_with_callback() - Designed to start an Mp get operation
and then invoke a callback function when the operation
completes. WARNING: For now this function is
synchronous.
get_attribute() - Returns the value of the specified
network field attribute.
set_attribute() - Sets the specified network field attribute
to the specified value.
get_attribute_number() - Returns the attribute number
corresponding to the specified attribute name.
add_callback() - Requests the MX server to set up an MX
callback of the specified type, with the specified
callback function and arguments. The method returns
an Mp.Callback object.
get_local_value() - This method returns the current value
of the local copy of an Mp.Net object _without_
requesting an update of the value from the remote
server.
Added new 'mp_monitor' script. This script monitors a user
supplied list of MX network fields for value changed callbacks.
Added a new example script to demonstrate the use of value
changed callbacks:
mp/examples/mpscript/mp_move_callback - This script starts
a motor move to the requested position and uses a value
changed callback to notify the script that the move
is complete.
Added new 'mpenv' script. This script creates an environment in
which the Mp module can run and then executes a user-supplied
script. It does not actually load Mp itself or an MX database.
Deleted the old Mp.CCD class which has been replaced by the
Mp.AreaDetector class.
Deleted the image_type attribute from the Mp.ImageFrame class.
**************** Changelog for MxTcl version 1.5.0 ****************
Version 1.5.0 (11/12/08):
Updated Tcl package version to 1.5.
Added new Mx::SCA class to control MX single channel analyzers.
More information about the Mx-mailing-list
mailing list