[Mx-mailing-list] MX 1.4.0 is available
lavender at agni.phys.iit.edu
Mon Jan 22 12:53:01 CST 2007
Versions 1.4.0 of MX, MP, and MxTcl are now available at the MX web site
from the download page
Please read the changelog below for the changes in this release.
**************** Changelog for MX version 1.4.0 ****************
Version 1.4.0 (01/15/07):
This version of MX adds support for the new 'area_detector' and
'video_input' driver classes. The initial motivation for adding
the new classes so that they could be used to implement drivers
for the new PCCD-170170 CCD detector from Aviex LLC. These new
classes are likely to include new small changes in the near future
since the driver development work for that detector is not yet
complete. In addition, it is expected that the drivers in the old
MX 'ccd' driver class will be migrated to the new 'area_detector'
class at some point in the near future.
As part of the CCD work, a new 'camera_link' interface class has been
added to support communication with digital cameras and frame grabbers
via the Camera Link interface standard. The Camera Link standard
is sponsored by the Automated Imaging Association.
The new files 'mx_image.c' and 'mx_image.h' provide support for a
variety of operations on 2-dimensional images and for sequences of
such images. The images are encapsulated in an MX_IMAGE_FRAME
structure. In the current version, the actual image data must be
in an array local to the process. However, future versions will
add support for image frames that are located in remote computers
so that area detectors that never transfer the raw image data to
the local process can be supported.
Several new MX device drivers have been added:
Area detector drivers:
network_area_detector - This driver allows an MX client to
communicate with an area detector controlled by a
remote MX server.
pccd_170170 - This driver is used to control a PCCD-170170
CCD detector from Aviex LLC. Not all features of
this detector are supported yet.
soft_area_detector - This driver is a software emulation
of an area detector. The driver depends on an
underlying video input driver to generate the
actual frame data. This underlying driver can be
either for a software emulated device or for a
real frame grabber or imaging board.
Video input drivers:
edt, edt_video_input - These drivers are used to control
imaging boards from EDT, Inc. (http://www.edt.com/)
using the EDTpdv drivers that are downloadable from
http://www.edt.com/dvsoftware.html. At present,
the MX drivers are only partially complete and are
not ready for use.
epix_xclib, epix_xclib_video_input - These drivers are used
to control imaging boards from EPIX, Inc.
(http://www.epixinc.com/) using the XCLIB drivers
that may be purchased for $495. At present, the
MX drivers are mostly complete and have successfully
been used to read out image frames from a PIXCI E4
frame grabber using PCI Express.
network_vinput - This driver allows an MX client to
communicate with a video input device controlled by
a remote MX server.
soft_vinput - This driver is a software emulation of a
video input card that can generate 8-bit greyscale,
16-bit greyscale, or 24-bit RGB images. The driver
generates a sequence of 4 images that smoothly ramp
from maximum intensity to minimum intensity. Each
of the four images has a maximum in a different
corner of the image, which helps in verifying that
the image transfer is working properly.
v4l2_input - This driver reads out frames from any imaging
board supported by the Linux Video4Linux2 driver.
At present, only the RGB565 and YUYV image formats
Camera Link drivers:
epix_camera_link - This driver can be used to send and receive
messages from a Camera Link controlled camera.
camera_link_rs232 - This driver can be used to treat a
Camera Link interface as if it were an RS-232
interface. The driver is intended to be used by
RS-232 specific programs like 'mxserial'.
MX client/server communication now uses dynamically resizeable
buffers for network messages. The buffers are now programmed to
start at 1000 bytes and then increase their size as needed. The
primary motivation for this feature was to make it easy to pass
very large arrays, such as those used by area detector images, in
one network call. The length of network buffers should now be
limited only by the amount of memory available on the client and
A new early move feature has been added to MX step scans. If the
current MX database contains a variable record called 'scan_early_move'
and the value of that variable is non-zero, then MX step scans will
start the move to the next step position immediately after the
counters stop counting for the current position. This means that
all input devices will be read out while the motor is moving to
the next step position.
The early move feature will only work correctly if all of the input
devices for the scan latch their values at the end of the counting
time. Other input devices such as analog voltage or current inputs
that do not latch or the motor position itself, will be recorded
with a value taken at some point during the move to the next step
position and not the value it had at the previous step. Thus, one
must be careful about using this feature.
Another change made in support of the early move feature was the
splitting of the old mx_measure_data() function into separate
mx_acquire_data() and mx_readout_data() functions. If you are
writing a program to use the early move feature, then the
mx_acquire_data() function should be called before you start
the next move and mx_readout_data() should be called after the
If a scan has more than 4 input devices, 'modify scan' in the
'motor' program now asks whether or not you want to make any
changes to the list of input devices. If the answer is 'no',
then the list of input devices is copied as is into the new
version of the scan.
Support has been added for starting an MX client or server that
does not get its record definitions from a disk file. Instead,
you can generate the ASCII record definitions in an in-memory
array of strings and create the database by calling the function
The 'win32' build target makefile now looks for the 'manifest' files
that are created by Visual C++ 2005 and above. If the makefile
discovers that manifest files have been created, it invokes the
Microsoft 'mt' utility to embed the contents of the manifest in
the executable. Embedding the manifest file in the executable makes
it unnecessary to explicitly copy manifest files to the install
location. Some effort has been made in the makefile to ensure that
the 'mt' program invoked is the Microsoft one and not the magnetic
tape handling program from Cygwin.
On Linux/Unix platforms, the mx_start_debugger() function now
attempts to start a GUI debugger such as DDD or the Sun Studio
debugger. If a known GUI debugger is not found, then it falls back
to a Curses based debugger in a terminal window. If that fails
as well, it finally attempts to use gdb or dbx in a terminal
Added a new MX build target called 'vms-gnv'. The OpenVMS systems
in the HP TestDrive program only support the version of 'make'
included with the GNV package (http://gnv.sourceforge.net/), so
this new build target was added to work with that makefile system.
However, the underlying compiler is still the HP compiler.
On VMS, the mx_sleep() family of functions now makes sure that
lib$wait() is told that the wait time passed is in LIB$K_IEEE_S
format on Itanium and in LIB$K_VAX_F format on Alpha and Vax.
mx_rs232_putline() has been modified so that if the underlying
RS-232 driver does not have a putline() function, it next looks
for a write() function before falling back to single character I/O.
The source code for the mx_clock_ticks_per_second() function has
been changed so that it first attempts to read the value from the
function sysconf(_SC_CLK_TCK), then reverts to the value of CLK_TCK
if _SC_CLK_TCK is not defined, and finally reverts to the value
of CLOCKS_PER_SECOND if CLK_TCK is not defined as well. The reason
for the change is that the XSI extension to POSIX apparently requires
that CLOCKS_PER_SECOND have the value 1000000 on all compliant
systems regardless of the actual number of clock ticks per second
used by the operating system.
Previous versions of the 'icplus_voltage' driver used an incorrect
':CONFx:VOLT?' command for setting the HV voltage rather than the
correct ':CONFx:VOLT' form of the command, without a question mark
on the end of it. This bug has now been fixed.
A bug has been fixed in the 'tracker_ainput' and 'tracker_aoutput'
drivers for Data Track Tracker modules where originally only the
first four characters were read in responses from the module.
The 'motor' driver class now contains a new record field called
'old_destination'. This new field contains the requested destination
for the move prior to the current move.
The 'keithley428' driver now makes it possible to read out the
version of the firmware loaded in the electrometer, by reading
the value of the new 'firmware_version' record field.
The 'pfcu' driver for XIA PF4 and PF2S2 filter and shutter controllers
has been modified so that it uses the correct line terminators (0x0d)
for commands sent to the controller.
The old 'labpc_adc', 'labpc_dac', 'labpc_din', and 'labpc_dout'
drivers for the LabPC+ DAQ card have been removed from MX. The reason
for this is that they relied on a third-party device driver that has
not been updated since the Linux 2.0 days. At some future date, we
plan to add support for Comedi supported DAQ cards which will support
the LabPC+ card and a wide variety of other cards.
The array functions in libMx/mx_array.c no longer add an extra byte
at the end of strings for the null terminator character. For new
versions of MX, if you want enough space for a null terminator, then
make the string 1 byte longer to begin with. This change was made
to make strings in C code more compatible with the way Python handles
A new header file called 'mx_poison.h' has been added. The purpose
of this header is to enforce a prohibition on the use of unsafe
C runtime functions such as gets() and strcpy(). Currently, only
part of MX is making use of this feature, but we plan to expand the
use of this header to most of MX as time permits. The current
implementation makes use of the 'GCC poison' pragma, which means
that it only works for code compiled with GCC 3 and later.
**************** Changelog for MP version 1.4.0 ****************
Version 1.4.0 (01/15/07):
Three new classes have been added to MP to support the corresponding
additions to MX:
Mp.AreaDetector - This class provides support to MP scripts
for MX-controlled area detectors.
Mp.ImageFrame - This class provides a way of manipulating
MX_IMAGE_FRAME structures from Python.
Mp.Net - This class provides a way for MP scripts to perform
low level I/O with an MX server via the Mp.Net.get()
and Mp.Net.put() methods.
At present, no MP class for MX video inputs has been created.
This will be added as time permits.
A new module called MpNum has been added. This module provides
a single class called MpNum.Net which inherits from the Mp.Net
class. The difference is that MpNum.Net reads and writes
NumPy arrays, while the base class Mp.Net uses Python lists
and tuples. The expectation is that MpNum.Net will normally
be much faster than Mp.Net, but this expectation has not yet
been tested with benchmarks.
It is possible to configure the MP makefiles so that they do not
attempt to compile MpNum.py on machines that do not have the
'numpy' Python module. However, even if the 'numpy' module is
not available, the failure to compile MpNum.py will not cause
the makefile to abort.
Some test programs for the MpNum.Net class have been placed
in the new subdirectory mp/net. The main program is called
'mpnet' while the other two programs 'mpget' and 'mpput' are
symbolic links to 'mpnet'. 'mpget' and 'mpput' are intended
to be similar to the 'mxget' and 'mxput' scripts from the
MxTclNet package and may well replace them someday. One issue
that remains to be resolved is whether or not 'mpget' should
display the array returned in NumPy style format or alternately
in a flattened format such as is currently used by 'mxget'.
A couple of new functions have been added to the Mp.py module:
Mp.start_c_debugger() - This function invokes the function
called mx_start_debugger() in the underlying libMx
Mp.start_py_debugger() - This function starts the 'pydb'
In some cases it is useful to actually start both debuggers, so
that 'pydb' debugs the Python part of the code, while DDD or GDB
debugs the C part of the code. As far as I know, the order in
which you start the two debuggers does not matter.
It is now possible to compile a special version of MP that is
compatible with the debugging version of Python. If you use the
debugging version of Python, it becomes possible to trace into
the part of Python written in C, which is occasionally useful.
The procedure for using this feature is to recompile MP with
the definition -DPy_DEBUG added to CFLAGS and then start your
Python script with an Python interpreter binary that has the
debugging support built in. For the Debian Etch distribution,
this requires installing the 'python-dbg' package which provides
a debugging interpreter that is also called 'python-dbg'.
New Mp.Record.open_hardware() and Mp.Record.close_hardware()
methods have been added so that your Python script can invoke
the underlying functions in libMx. The fact that they were
absent was merely an oversight.
**************** Changelog for MxTcl version 1.4.0 ****************
Version 1.4.0 (01/15/07):
Updated Tcl package version to 1.4.
Modified make_LibMxTcl_index so that it no longer uses the
Bash 'x$PATH = x' trick for Cygwin and Win32 to determine whether
or not the PATH variable already exists. The trick fails if the
PATH variable contains space characters, which are a common
occurrence on Cygwin and Win32 systems.
More information about the Mx-mailing-list