Version 2.0.0 (03/10/16): Added new build targets: bsd-clang, linux-clang, macosx-clang, hurd The -clang targets provide support for compiling MX using the LLVM Clang compiler. On Windows, MX is normally compiled from Cygwin or Msys shell sessions even if the compiler is Visual C++. The source code directory mx/scripts/windows/visual_studio now contains some example scripts that automatically figure out all of the environment variable definitions needed for Cygwin to be able to compile using Visual C++ from a Cygwin command line. All you need to do is to copy the script that matches your compiler to some place like /usr/local/bin, arrange for your Cygwin Bash startup scripts to automatically source that script, and then modify the definition of PROGRAM_FILES_DIR or MSDEV_DIR at the top of the script to match the location that Visual Studio has been installed to on your system. At present, example scripts are available for Visual Studio 2010, 2012, 2013, and 2015, as well as Visual C++ 4.0, 5.0, and 6.0. If you are using the Visual Studio Cygwin scripts just mentioned above, the Windows makefile mx/libMx/Makehead.win32 now supports autoconfiguration of the variables used to build MX with Visual C++ on Windows. Under normal circumstances, it should not be necessary to modify mx/libMx/Makehead.win32 at all. Similar autoconfiguration changes have been made to other MX makefiles. Most of the time, you should not need to change anything other than the variables MX_ARCH and MX_INSTALL_DIR in the top level MX Makefile. 'mxserver' now has support for an ASCII command interface in addition to the regular binary command interface. This was done for third-party beamline control programs that prefer to use an ASCII interface. At present, the commands 'GET record.field' and 'PUT record.file value' are implemented. If you have a choice, use the binary command interface since it is much, much faster than the ASCII interface and has many more features. The 'mxupdate' program has been renamed to 'mxautosave'. The immediate cause for doing this is the fact that Windows 7 seems to insist on popping up a UAC dialog any time that you try to run an EXE file with the string 'update' embedded in its name. Changing the name to 'mxautosave' is probably just as well, since the new name more directly describes what it does, namely, automatically saving and restoring MX variables. Added new 'mxmonitor' program. It will display value change updates in your terminal window for MX record fields whose name are specified on the 'mxmonitor' command line. Added 'mx_config' utility program. 'mx_config' can be used in MX makefiles to report the compiler version, the runtime library version, the operating system version, etc. The 'mx_config python' option allows makefiles for Mp-based Python scripts find Windows Python in the Registry and make sure that the Win32 version of Python is invoked when building .pyc files, rather than the Cygwin version. This makes it possible to build Win32 Python .pyc files from a Cygwin bash shell. Added cross-platform support for "file monitors". These allow MX to be informed when monitored files have been changed. Changed the length of record names and field names to 40. Including the '.' between the two, this allows for 81 character record field names. Added new sequence types: gated - In a gated sequence, an area detector or video input takes images as long as an external gate signal is active. Area Detector-Related Changes: 'Flood field' has been renamed to 'flat field' in both messages and function names for greater compatibility with standard terminology in the imaging business. Renamed area detector oscillation functions and variables to 'oscillation' rather than the older, misleading name of 'exposure'. A low resolution ASCII image display can now be written to the output log of 'mxserver' by writing a command like this: mxput cmos.show_image_display 4 The number for the example above means this: 0 - Display the current image frame buffer for the detector. 1 - Display the mask frame buffer. 2 - Display the bias frame buffer. 4 - Display the dark current frame buffer. 8 - Display the flat field frame buffer. The command mxput cmos.show_image_statistics 4 can similarly be used to display statistics about the image in the matching MX frame buffer. MX database changes: New fields for the 'mx_database' record. mx_database.cflags - Displays the value that the CFLAGS macro had at the time MX was compiled. mx_database.crash - Writing to this field immediately crashes the MX server for testing the handling of such crashes. Only available if remote breakpoint (-r) support is enabled for the running MX server. mx_database.numbered_breakpoint_status and mx_database.breakpoint_number - Adds support for "numbered" breakpoints in MX that can be individually turned on or off. mx_database.posix_time - Reports the current time for the MX server using the Posix epoch. Added new database file directives for MX database files. !break - causes mx_breakpoint() to be invoked at the point where the '!break' statement is encountered in reading a database file. !return - causes MX to stop reading the current database file at the point where the '!return' statement is encountered. New Driver Superclasses: operation - This driver superclass provides a way of managing long-running operations that are managed via an MX record. Drivers are expected to supply 'start', 'stop', and 'get status' functionality, but the actions performed by "operations" are not otherwise constrained. Available class: operation_class - Includes the 'network_operation', 'toast', 'rdi_mbc_log' (rdi_mbc.mxo), and 'biocat_6k_toast' (site_biocat_toast.mxo). special - This driver superclass provides a place to store driver classes that do not really fit anywhere else. Available classes: program - For managing external processes that are typically used by "mxserver". Available driver: 'external_command'. mod - For MX drivers that override the behavior of other MX drivers. Typically this is done by replacing some of the method functions in the original driver. At present, the only existing driver is the 'rdi_xineos_gige' driver from the RDI-proprietary rdi_xineos_gige.mxo module. New Variable Classes: field - A driver class that contains drivers for reading and writing record fields as MX variable records. special_variable - A driver class for variable drivers that do not fit anywhere else. Available drivers are 'rdi_mbc_string' (rdi_mbc.mxo), 'rdi_mbc_filename' (rdi_mbc.mxo), 'rdi_mbc_datafile_prefix' (rdi_mbc.mxo), 'rdi_mbc_pathname_builder' (rdi_mbc.mxo), 'rdi_mbc_save_frame' (rdi_mbc.mxo), and 'biocat_6k_joystick' (site_biocat_toast.mxo). New Driver Types Added to MX Core (libMx): ainput_as_dinput - Uses an analog input as a digital input with selectable values for low, high, and threshold voltages for compatibility with 5V, 3.3V, 1.8v, and other voltage-based digital logic. aoutput_as_doutput - Uses an analog output to generate a digital output with selectable values for low, high, and threshold voltages. coordinated_angle - This driver coordinates the moves of several motors to maintain them all at the same relative angle. Used at BioCAT to move several motors when mirror angles are changed. digital_fanin - Reads values from other MX record fields and performs a logical operation on the values read (and, or, xor). digital_fanout - Forwards the value written to this record to several other MX record fields. external_command - Runs an external command using mx_spawn() and waits for the command to finish. These commands are intended to be run during MX database startup and can be run either at finish_record_initialization() time or at open() time. field_string, field_char, field_uchar, field_short, field_ushort, field_bool, field_long, field_ulong, field_hex, field_int64, field_uint64, field_float, field_double, field_record - These drivers provide a way of reading and writing arbitrary MX record fields as if they were MX variables. gittelsohn_pulser - MX pulse generator driver for Mark Gittelsohn's Arduino-based pulse generator used by RDI area detectors. indirect_string - This variable driver can read values from several other MX record fields and then construct a string value from them based on a C-style format string specified in the MX database. merlin_medipix - MX area detector driver for the Merlin Medipix series of detector from Quantum Detectors. monte_carlo_mca - An MX driver that calculates a simulated MCA spectrum. The details of the peak sizes and widths are specified in the MX database entry for this record. At present, "gaussian" and "lorentzian" peaks are supported, as well as "polynomial" and "uniform" backgrounds. network_operation - MX operation driver for operations controlled by a remote MX server. network_wvin - MX waveform input driver for waveform input devices controlled by a remote MX server. pilatus - MX area detector driver for Dectris Pilatus area detectors. Not all functionality of the Pilatus is supported yet, but single frame capture works. relay_as_doutput - MX digital output driver that treats an MX relay as a digital output. soft_mce - Implements software-emulated MX multichannel encoders that periodically read motor positions from other records. For most records, the value read is the value that is currently found in motor->position. However, for 'soft_motor' records, the motor position is computed using the function mx_dead_reckoning_predict_motion(). This driver is only suitable for software testing and should not be used for real experiments. synaccess_netbooter, synaccess_netbooter_ainput, synaccess_netbooter_relay - The Synaccess netBooter is a remotely controllable power strip to provide remote users the ability to remotely power cycle a device. For some versions of the netBooter, it is also possible to measure the current draw of the device and the ambient temperature of the netBooter. toast - MX operation driver that oscillates a motor back and forth until stopped. For some kinds of experiments, this can be thought of as "toasting" the sample in the X-ray beam. xafs_k_power_law_scan - Implements XAFS wavenumber scans for which the counting time follows a power law. This is an alternative to multiregion XAFS scans. Renamed Drivers: Note that in each case a backward compatibility alias is available for the old name. databox_mce - New name for 'databox_encoder'. mcs_mce - New name for 'mcs_encoder'. Current Dynamically Loadable Modules: In MX 2.0.0, all drivers that depend on third-party DLLs or shared libraries have been moved to dynamically loaded MX modules, so that the core of MX can be compiled independently of these external libraries. Here is the list of currently working modules for MX 2.0.0. aviex_pccd.mxo: Drivers for Aviex (later Dexela) PCCD series area detectors. The drivers for these used to be in libMx. pccd_16080 - This is an old detector located at the BioCAT beamline of the Advanced Photon Source. pccd_170170 - This detector is in use at the SWING beamline of Synchrotron Soleil. pccd_4824 - This detector is located at ESRF. pccd_9785 - This is the newest and last member of the series of PCCD detectors. It is located at the BioCAT beamline of the Advanced Photon Source. driverlinx_portio.mxo: The driver for this used to be in libMx. driverlinx_portio - A low level driver for communicating with x86 architecture I/O ports. The third party driver this MX driver depends on does not work on recent versions of Windows or on 64-bit Windows. epics.mxo: Core MX client support for EPICS, as well as MX drivers for most of the EPICS drivers in the SynApps package. The drivers for these used to be in libMx. epics_ainput - MX analog_input driver that reads floating point values from EPICS PVs with support for dark current subtraction. epics_aoutput - MX analog_output driver that writes floating point values to EPICS PVs. epics_area_detector - MX area_detector driver that communicates with area detectors controlled by the EPICS areaDetector module. epics_ccd - MX area_detector driver that communicates with the obsolete ccd EPICS module. epics_dinput - MX digital_input driver that reads integer values from EPICS PVs. epics_doutput - MX digital_output driver that writes integer values from EPICS PVs. epics_mca - MX mca driver that communicates with multichannel analyzers controlled by the EPICS mca module. epics_mcs - MX mcs driver that communicates with multichannel scalers controlled by the EPICS mca module. epics_motor - MX motor driver that communicates with motors controlled by the EPICS Motor record. epics_scaler - MX scaler driver that communicates with a single scaler channel of a device controlled by the EPICS scaler module. epics_scaler_mce - MX multichannel encoder driver that reads out channels from EPICS Scaler channels that were saved using synchronous groups. epics_scaler_mcs - MX multichannel scaler driver that reads out channels from EPICS Scaler channels that were saved using synchronous groups. epics_timer - MX timer driver that communicates with the timer channel of a device controlled by the EPICS scaler module. epics_camac - MX CAMAC driver that communicates with a CAMAC crate controller using the EPICS CAMAC module. epics_gpib, epics_rs232 - MX gpib and rs232 drivers that communicate with GPIB and RS-232 ports using an old obsolete EPICS interface for such ports. They should be replaced by drivers using Asyn support, but this has not been done yet. epics_vme - MX VME driver that reads and writes values located at VME addresses managed by the EPICS VME module. epics_char, epics_short, epics_long, epics_float, epics_double, epics_string - These are MX variable drivers that read and write EPICS PVs with matching variable types. epics_timeout - Controls the EPICS PV connection timeout from MX. epics_aps.mxo: MX drivers for devices only found at the Advanced Photon Source. aps_gap - MX motor driver that controls the undulator gap for an Advanced Photon Source insertion device. aps_quadem_amplifier - MX amplifier driver for the quadEM EPICS module. aps_id_qscan - An MX quick scan driver that arranges for an APS insertion device to be scanned in sync with a beamline monochromator. aps_topup_interlock - aps_topup_time - Reports the time until the next Topup injection. epics_mbc.mxo: MX drivers for EPICS PVs specific to the MBC beamline 4.2.2 at the Advanced Light Source: mbc_gsc_trigger, mbc_noir, mbc_noir_trigger epics_pmac_biocat.mxo: MX drivers for EPICS controlled devices at the BioCAT beamline (18-ID) at the Advanced Photon Source. epics_pmac_biocat - A version of the MX motor driver for PMAC-controlled motor axes at BioCAT. It has more features than the older 'epics_pmac_tc' module. epics_pmac_tc.mxo: MX drivers for the original EPICS databases for PMAC- controlled motors. pmac_tc_motor - An MX motor driver for this module. epix_xclib.mxo: MX drivers for 2-dimensional image frame grabbers from EPIX, Inc. epix_xclib - MX driver for communicating with the XCLIB library. epix_rs232 - MX driver for communication with serial devices controlled by the XCLIB library. epix_camera_link - MX driver for communication with Camera Link devices controlled by the XCLIB library. epix_xclib_dinput, epix_xclib_doutput - MX digital input and digital output drivers for digital I/O controlled by the XCLIB library. epix_xclib_video_input - An MX video_input driver for frame grabbers controlled by the EPIX XCLIB library. esone_camac.mxo: MX module wrapper for communication with a CAMAC crate controlled via an ESONE-compatible API library. esone_camac - MX CAMAC interface driver for the CAMAC crate controller. k8055.mxo: MX module for controlling the USB-controlled Velleman K8055 data acquisition device. k8055 - MX driver for USB communications to the K8055 device. k8055_ainput, k8055_aoutput, k8055_dinput, k_8055_doutput - MX analog and digital I/O drivers for the Velleman K8055. k8055_scaler - MX scaler driver for a counter channel of the Velleman K8055. k8055_timer - MX timer driver for the timer of the Velleman K8055. libusb_01.mxo: MX module for communicating with the deprecated libusb-0.1 API. libusb_01 - MX USB driver for the libusb-0.1 API. linux_portio.mxo: MX module for communicating with x86 I/O ports using the 'linux_portio' kernel device driver. linux_portio - MX port I/O driver using the 'linux_portio' kernel device driver. newport_xps.mxo: MX module for controlling the Newport XPS-C and XPS-Q series of motor controllers via the vendor-provided C++ code. newport_xps - MX interface driver for the controller as a whole. newport_xps_motor - MX motor driver for a single axis of the motor controller. ni488.mxo: MX module for controlling GPIB interfaces using either the National Instruments IEEE-488 library or the open source Linux-GPIB library. ni_daqmx.mxo: MX module for controlling National Instruments DAQmx devices. ni_daqmx - MX driver for controlling the DAQmx library. ni_daqmx_ainput, ni_daqmx_aoutput, ni_daqmx_dinput, ni_daqmx_aoutput - MX analog and digital I/O drivers for the DAQmx library. ni_daqmx_thermocouple - An MX analog_input driver for thermocouples read out via DAQmx. ni_valuemotion.mxo: MX module for controlling National Instruments ValueMotion motor controllers via the vendor-provided Win32 libraries. pcmotion32 - MX interface driver for the controller as a whole. pcmotion32_motor - MX motor driver for a single axis of the controller. ortec_umcbi.mxo: MX module for EG&G Ortec devices controlled via the Unified MCB Interface for 32 Bits library (A11-B32) under Windows. umcbi - MX interface driver for the UMCBI library. trump_mca - MX mca driver for the Ortec Trump MCA. pleora_iport.mxo: MX module for the vendor-provide Win32 C++ libraries for the Pleora iPORT camera interface. pleora_iport - MX interface driver for the Pleora iPORT. pleora_iport_vinput - MX video input driver for Pleora iPORT camera interfaces. pleora_iport_dinput, pleora_iport_doutput - MX digital I/O drivers for the Pleora iPORT. pmc_mcapi.mxo: MX module for the Precision MicroControl MCAPI series of motor controllers. pmc_mcapi - MX interface driver for communicating with MCAPI. pmc_mcapi_motor - MX motor driver for a single axis controlled by the MCAPI library. pmc_mcapi_ainput, pmc_mcapi_aoutput, pmc_mcapi_dinput, pmc_mcapi_doutput - MX analog and digital I/O drivers for the MCAPI library. powerpmac.mxo: MX module for controlling Delta Tau PowerPMAC motor controllers. Please note that these drivers are designed to be run directly on the controller itself using the installed version of PowerPC Debian GNU/Linux and the installed GCC compiler. powerpmac - MX interface driver for communicating with the PowerPMAC controller. powerpmac_motor - MX motor driver for a single motor axis. powerpmac_ainput, powerpmac_aoutput, powerpmac_dinput, powerpmac_doutput - MX analog and digital I/O drivers for the PowerPMAC. powerpmac_long, powerpmac_ulong, powerpmac_double - MX variable drivers for the matching internal variables of the PowerPMAC python.mxo: MX module for calling MP-based Python scripts from a C/C++ based user program. Typically this is used by 'mxmotor'. python - An MX extension (not a driver) that controls communication with Python 2.x. Warning: Creating and modifying MX scans is not yet fully supported by this extension module. radicon_helios.mxo: MX module for the Radicon Helios 25x20 and 10x10 CMOS area detectors. These were test devices for RDI that were never made into a product. radicon_helios - MX area_detector driver for the detector. radicon_helios_trigger - An MX pulse_generator driver for the detector. radicon_taurus.mxo: MX module for the Radicon Taurus-based CMOS_8M series of area detectors from Research Detectors Inc. Currently in use at the ALS 4.2.2 MBC crystallography beamline. radicon_taurus - MX area detector driver for the detector. radicon_taurus_rs232 - MX interface driver for communicating the detector FPGA via an ASCII protocol. rdi_mbc.mxo: MX module for custom additions to the ALS 4.2.2 detector interface for compatibility with that beamline's existing control software. rdi_mbc_string, rdi_mbc_filename, rdi_mbc_datafile_prefix, rdi_mbc_pathname_builder, rdi_mbc_log, rdi_mbc_save_frame sapera_lt.mxo: MX module for Teledyne DALSA's Sapera LT interface library for controlling DALSA cameras and frame grabbers. Please note that DALSA cameras and frame grabbers have similar, but not identical, APIs, so it is necessary to have two separate video input drivers for them. sapera_lt - MX interface driver for communicating with the Sapera LT libraries. sapera_lt_frame_grabber - MX video_input driver for DALSA frame grabbers. sapera_lt_camera - MX video_input driver for DALSA cameras. sis3100.mxo: MX module for controlling VME crates via the Struck 1100/3100 set of VME controller cards. sis3100 - MX VME driver for the Struck interface. site_biocat_toast.mxo: Site-specific drivers for a Parker Compumotor controller used at the BioCAT (18-ID) beamline of the Advanced Photon Source. biocat_6k_toast - This MX operation driver uses an X-Y translation stage to "toast" samples in front of an X-ray beam. biocat_6k_joystick - This MX special variable driver allows the joystick input of the X-Y translation stage to be controlled from an MX-based GUI. u500.mxo: MX module for the vendor-provided Win32 libraries for the Aerotech Unidex 500 motor controller. u500 - MX interface driver for the controller as a whole. u500_rs232 - MX rs232 driver for sending command strings to the driver. u500_motor - MX motor driver for a single axis. u500_status - MX digital_input driver for reading status values from the controller. u500_variable - MX variable driver for U500 V variables. v4l2_input.mxo: MX module for the Linux-only Video4Linux version 2 video capture API. v4l2_input - MX video_input driver for the Video4Linux 2 API. vxi_memacc.mxo: MX module for the NI-VISA VXI/VME controller via the MEMACC resource. vxi_memacc - MX VME driver for the MEMACC resource. xia_handel.mxo: MX module for multichannel analyzers made by XIA that are controlled via the Handel library. handel - MX interface driver for the Handel API. handel_mca - MX mca driver for a single MCA in a multi-MCA module. handel_sum - MX driver that computes weighted sums of XIA Handel values. handel_timer - MX timer driver to control the timing of Handel controlled MCAs. xineos_gige.mxo: MX module for the DALSA Xineos GigE series of detectors. xineos_gige - MX area detector driver for this detector. Unfinished modules: There are several modules that were written, but never fully tested for various different reasons. These modules have been kept in the source code tree, but need more work to be usable by end users: avt_pvapi, avt_vimba, bnc725, edt, fastcam_pcclib, labjack_ux, libtiff, nuvant_ezware2 Modules deleted: dalsa_gev, nuvant_ezstat Drivers deleted: brandeis_biocat Version 1.5.4 (05/10/11): Although the development leading up to this release called itself MX 1.5.3, the stable release will be called MX 1.5.4. The new policy is that development releases will always end in odd numbers while stable releases will end in even numbers. This will make it easier to distinguish stable releases from development versions in the future. Dynamically Loadable Module support: MX now has support for dynamically loading extension modules at runtime. For MX 1.5.4, these modules can only contain sets of device drivers, but in future releases it will be possible to dynamically load extensions containing software packages that are not drivers, such as Python interpreters, specialized numerical processing packages, and so forth. Modules are loaded using the new mx_load_module() function. The ultimate plan is to move all optionally compiled drivers that are currently selected using the libMx/mxconfig.h file into the new dynamically loaded modules and do away with the mxconfig.h file. MX 1.5.4 comes with four modules. Two of these are currently being used in the testing of new area detectors, while the other two are at earlier stages of development. Area detector-related modules: pleora_iport - This Windows C++ module contains a series of drivers for the Pleora iPORT family of streaming video capture devices. The available drivers include: pleora_iport - Interface driver for communicating with the iPORT software libraries. pleora_iport_vinput - MX video input driver for capturing frames from an iPORT IP engine. pleora_iport_dinput - MX digital input driver for reading the A0 through A3 inputs of an iPORT PLC. pleora_iport_doutput - MX digital output driver for writing to the Q outputs of an iPORT PLC. radicon_helios - This Windows C++ module contains drivers for controlling the Helios series of Rad-icon X-ray detectors which make use of the Pleora iPORT. The available drivers include: radicon_helios - MX area detector driver for a Helios detector. This detector is either triggered by an external trigger or by the 'radicon_helios_trigger' driver described below. radicon_helios_trigger - This makes use of parts of the Pleora iPORT PLC that are not used by the 'radicon_helios' to implement a self-contained triggering system for the 'radicon_helios' so that it can work without external triggering. Work in progress modules: daqmx_base - This C-based module provides interfaces to the National Instruments DAQmx Base data acquisition libraries. On Linux, the analog output and digital I/O drivers work with a USB-6009 module, but the analog input driver does not seem to detect supplied input voltages (for an unknown reason). On Windows, the analog input driver sometimes can cause the MX server to hang. Work on the 'daqmx_base' module was put on hold for now, since it was holding up the release of MX 1.5.4. It will be completed at a later date. Unfortunately, National Instruments only supports DAQmx Base on Linux for OpenSuse and Red Hat Enterprise Linux. I have not yet been able to get installation to work on Debian-based distributions. In addition, due to the way that National Instruments has implemented DAQmx Base, it is necessary on Linux to prefix the command that starts your MX server with this LD_PRELOAD=/usr/local/lib/libnidaqmxbase.so Otherwise, the DAQmx Base library does not work correctly. In addition, startup and shutdown of the 'daqmx_base' drivers is _very_ slow, since National Instruments's DAQmx Base is actually firing up a copy of the LabVIEW runtime in the background. Nevertheless, the available drivers and their status are: daqmx_base - Interface driver for communicating with the DAQmx Base libraries. (works) daqmx_base_ainput - Analog input driver, which does not work on the USB-6009 as mentioned above. daqmx_base_aoutput - Analog output driver. (works) daqmx_base_dinput - Digital input driver. (works) daqmx_base_doutput - Digital output driver. (works) daqmx_base_thermocouple - Analog input driver for use with thermocouples. Not tested, since the USB-6009 does not support thermocouple inputs. bnc725_lib - Windows C++ module for the BNC725 digital delay generator from Berkeley Nucleonics Corporation. This is intended to provide MX pulse generator drivers as well as other drivers. However, the work has not yet progressed far enough for this module to be useful. New Device Driver Support: digital_output_pulser - This is a driver that uses an MX digital output as a "pulse generator" using operating system timers to control the timing of the pulses. You should only use this driver in cases where the precise timing of the pulses is not important. energy_mcs_qscan - This is an MX quick scan driver that is optimized for use with MX energy pseudomotors. Restricting this driver to only work with energy pseudomotors allows this scan to run faster than the 'mcs_qscan' driver. epics_area_detector - This is an MX area detector driver for communicating with the IOC-based EPICS Area Detector record. file_dinput - This driver uses values read from a file to simulate a digital input. keyboard_dinput - This driver uses keypresses on a keyboard to simulate a digital input. I404 - Drivers for the Pyramid Technical Consultants I404 digital electrometer. The individual drivers are: i404 - Controller driver. i404_amp - Amplifier driver to control gain, offset, etc. i404_mcai - Multichannel analog input driver. This driver reads the values from all 4 channels of the I404 as a single operation. limited_move - This is an MX pseudomotor driver that limits the magnitude of relative moves. Linkam T9x - Drivers for the Linkam T92, T93, T94, and T95 series of temperature controllers. The individual drivers are: linkam_t9x - Controller driver. linkam_t9x_motor - This is a motor driver for controlling the motion control part of the T9x controllers. linkam_t9x_pump - Analog output driver for controlling the pump speed. linkam_t9x_temp - This is a motor driver for controlling the temperature setpoint. Molecular Biology Consortium (Beamline 4.2.2 at the ALS) - This is a series of drivers written to control beamline specific components of the ALS 4.2.2 beamline. The individual drivers are: mbc_noir - MX area detector driver for controlling the MBC NOIR 1 detector. mbc_noir_trigger - Pulse generator driver that controls the beamline trigger signal through the MBC:NOIR: EPICS PVs. mbc_gsc_trigger - Pulse generator driver that controls the beamline trigger signal directly through the MBC:gsc: EPICS PVs of the MBC GonioSync Controller. network_mcai - MX multichannel analog input driver for an MCAI controlled by a remote MX server. Power PMAC - This is a set of drivers for controlling the new Delta Tau Power PMAC series of motion controllers. The Power PMAC controller, as delivered, is based on a PowerPC-based Linux computer running the Debian Lenny (5.0) distribution with Xenomai patches. The installed copy of Lenny comes complete with GCC, Make, and other development tools. This makes it straightforward to build the MX server to run directly on the Power PMAC controller itself, linking to the vendor-provided motion control libraries. The individual drivers are: powerpmac - Controller driver. powerpmac_motor - Motor driver for controlling an individual Power PMAC motor. powerpmac_ainput, powerpmac_aoutput, powerpmac_dinput, powerpmac_doutput - Drivers for controlling Power PMAC variables as if they were analog or digital I/O devices (which in some cases, they are). powerpmac_long, powerpmac_ulong, powerpmac_double - MX variable drivers for directly reading and writing Power PMAC internal variables. SIM900 - A set of drivers for controlling modules installed in a Stanford Research Systems SIM900 mainframe. The currently available drivers are: sim900 - Mainframe controller driver. sim900_port - MX RS-232 driver for communicating with individual modules in the SIM900 mainframe. sim960 - MX motor driver for the SIM960 Analog PID controller. sim980 - MX analog input driver for the SIM980 summing amplifier. sim983 - MX amplifier driver for the SIM983 scaling amplifier. telnet - This is an RS-232 driver for communicating with Telnet-based terminal servers. The primary difference between the 'tcp232' driver and the 'telnet' driver is that the 'telnet' driver knows how to handle Telnet option negotiation. MX now supports the 'win32' build target on Windows 7. Note that Windows Vista is _not_ supported, since I do not have access to a Vista machine, but it will probably work anyway. MX can now be built for the 'win32' build target using the Microsoft Visual C++ 2010 Express compiler or using the Windows 7 SDK compilers. Visual C++ 2010 Express does not include a compiler capable of creating 64-bit binaries, so you must use the Windows 7 SDK for that or else use the full version of Visual Studio 2010. Please note that you use the 'win32' build target in the MX makefiles even if you are building a 64-bit version of the code, since the Windows API is actually essentially the same on 64-bit systems. MX support for EPICS on Windows 7 has been tested using EPICS 3.14.12. On Linux platforms, 'make install' now copies scripts/mxsetup.sh to /opt/mx/bin. This is to make the example startup script easier to find by new users. Added new mx_rs232_get_configuration(), mx_rs232_set_configuration(), and mx_rs232_send_break() functions for MX RS-232 drivers. The get and set configuration functions affect the speed, word size, parity, stop bits, flow control, read terminators, and write terminators for the port. At present, these features are supported by the 'network_rs232', 'tty', and 'win32_com' drivers. Changed the area detector code to use the term 'duration' mode rather than 'bulb' mode for exposures whose length depends on the duration of an external trigger signal. Although 'bulb' mode is the term used in digital photography and by the PVCAM library, I found that I was always having to explain what I meant by the term. Hopefully, 'duration' mode will be a more obvious description of what the area detector mode is doing. Added 'exposure_mode' infrastructure to area detector support do distinguish (when necessary) between the following exposure types: still, dark, and expose(oscillation). This is currently only being used by MBC detectors. Added the MXF_AD_SAVE_CORRECTION_FRAME_AFTER_ACQUISITION flag (0x8000) to the 'area_detector_flags' field of area detectors. If this flag is set, mx_area_detector_default_datafile_management_handler() will automatically save a copy of any newly acquired correction images to disk. The frames are saved as part of the normal numbering sequence for saved images. This feature is intended primarily for debugging the acquisition of correction frames. The 'pccd_16080' driver for the Aviex PCCD-16080 detector at BioCAT now can use binning of up to 128 in the horizontal direction and up to 8 in the vertical direction. The 'pccd_16080' driver now supports strobe mode sequences, where the acquisition of each frame is started by an external trigger. Updated the 'epics_mca' driver so that it can automatically compensate for whether or not the version of dxp support is dxp3-0 or newer. Added the MXF_EPICS_MCA_WAIT_ON_START bit (0x8) to 'epics_mca_flags' to wait for a notification that the EPICS MCA record has started counting. This used to be the default behavior, but now is not in order to speed up scanning. The 'motor' program can now directly create and run area detector scans of type 'wedge_scan'. The 'wedge_scan' driver is designed to emulate the behavior of Blu-Ice when acquiring CCD data. The underlying scanning code has existed for several years, but this now provides a user interface for the feature. The 'pmac_mce' driver can now directly modify the slaving of the slave motor axis without needing to run a PLC program. If you specify a negative number for the 'plc_program_number' parameter, the driver uses the absolute value of that as the slave motor axis number. EPICS support in libMx/Makehead.linux now contains examples of how ot configure the makefile to use the NSLS-II EPICS Debian packages at http://epics.nsls2.bnl.gov/debian/ instead of the IIT EPICS Debian packages at http://debian-xray.iit.edu/. The behavior of EPICS is essentially identical, regardless of which set of EPICS Debian packages you use. Tested linux-ppc EPICS support using a Power PMAC system as the development platform. Minor 'win32' makefile changes for compatibility with very recent versions of Gnu make from Cygwin. Minor 'solaris' makefile changes for compatibility with the SunStudio 12.1 development system. Minor change to the 'linux_parport' series of drivers so that by default they do _not_ shift the bits read from the parallel port status ports. This provides better compatibility with the pinout descriptions on the Internet for PC-style parallel ports. 'linux_parport_flags' in the 'linux_parport' driver now has two new flag bits: MXF_LINUX_PARPORT_PERIPHERAL_DRIVES_DATA_LINES (0x2) tells Linux to not have the parallel port itself drive the data lins. MXF_LINUX_PARPORT_STATUS_PORT_SHIFT_BITS_DOWN (0x4) shifts the status bits down by 3 bits to recover the old behavior before this release, as described in the previous paragraph. Changes have been made to the interactions between the motor 'position', 'status', and 'extended_status' to more reliably send value changed updates when necessary. Changes have been made to the interactions between the area detector 'last_frame_number', 'total_num_frames', 'status', and 'extended_status' to more reliably send value changed updates when necessary. Modified the order in which SMV headers are written to disk files for better compatibility with Fit2d. Added new motor fields: 'busy_start_interval_enabled' MXFT_BOOL 'busy_start_interval' MXFT_DOUBLE (in seconds) 'last_start_time' MXFT_DOUBLE (in seconds) If 'busy_start_interval_enabled' is set to a non-zero value, then just after a move is commanded, motor drivers will unconditionally report the motor as moving for a period equal to 'busy_start_interval', regardless of what the motor controller itself says. This is to work around motor controllers that have the misfeature of reporting that the motor is not moving for a short time after a motor move is commanded. At present, the 'pmac_motor' and 'powerpmac_motor' drivers set the busy start interval to 0.01 seconds. The 'pmac' driver now supports 5 different port connection types: rs232 - Connect using an MX RS-232 port. tcp - Connect using the PMAC Ethernet Protocol described in the manual for the Delta Tau Accessory 54E UMAC module for Ethernet/USB communication. gpascii - Telnet to a Power PMAC, login, and then run the vendor-provided 'gpascii' program. gplib - When running on a Power PMAC CPU, use the vendor -provided gplib library. epics_ect - Connect using the StrCmd and StrRsp PVs of an Argonne ECT-style EPICS database for VME-based PMAC controllers. Not recommended. For Power PMAC controllers, you are better off using the 'powerpmac' series of MX drivers instead. Added Linux support for the 'pmc_mcapi' series of drivers used by Precision MicroControl motor controllers that use the MCAPI library. Added better XMAP support for the XIA Handel drivers. Added the new MXF_ISOBUS_RESYNCHRONIZE_DURING_OPEN (0x4) flag to the 'isobus' driver. High resolution timers should now work correctly on x86_64-based Linux platforms. Added support for briefer and more understandable network debugging messages for MX clients. For the 'motor' program, this can be accessed by adding the '-a' command line argument when you start it. The interface class 'generic' has been renamed to 'controller' to more accurately reflect its purpose. For the forseeable future, the old name of 'generic' will still work. Version 1.5.2 (03/30/10): New Device Driver: u500_variable - This driver provides a way to read and write U500 V-variables. The 'u500_rs232' driver has now been successfully tested for writing command strings to the U500 controller. It appears that reading strings sent by running U500 programs may well not be possible. The 'iseries' interface driver can now communicate correctly with i-Series controllers in Point-to-point mode rather than just those in Multipoint mode. Added support for the Mpatrol and Dmalloc memory debugging packages. Found and fixed a variety of memory leaks. The set_mode functions of the 'epics_scaler' and 'epics_timer' drivers now turn off Joerger autocount, since autocount can delay the start and end of MX scans by several seconds. Added PowerPMAC 'gpascii' support to the 'pmac' driver. Bear in mind that this code has not yet been tested with a real PowerPMAC. Added a new 'set plot end' command for 'motor', which tells MX to only display the plot at the end of a scan. For XAFS scans, the effect is to only update the plot at the end of each scan region. Modified scan plotting support to use the new mx_coprocess_open() and mx_coprocess_close() functions rather than popen() and pclose(). The coprocess functions provide a way of reliably being able to kill all of the processes spawned by the call to mx_coprocess_open() which is not possible with popen(). The coprocess support has been tested on both Unix and Windows platforms. MX area detectors can now be used as scan input devices. For step scans, an image will be stored for each step in the scan. MX area detectors now support deferring the adding of a bias offset until after the flood field correction. This was done to improve the linearity of the dark current and flood field corrections. For this case, the correction calculations are done in double precision floating point so that temporary intermediate results can be negative before the values are converted to 16-bit unsigned integers at the end. Added new area detector fields: bias_corr_after_flood datafile_allow_overwrite - If set, this flag allows the area detector software to overwrite existing data files. If the flag is not set, an error will be returned instead. datafile_autoselect_number Dark and flood images are no longer saved as part of the normal area detector datafile numbering sequence. When using SMV format, the area detector bias offset is now written to the ZEROOFFSET field in the SMV header. MCS quick scan backlash is now only performed if the following value fabs( quick_scan_backlash_correction / quick_scan_motor_scale ) is greater than 1.0e-6. Otherwise, the quick scan backlash step is skipped, which can shorten the setup time for a quick scan by 3 seconds or more. Added a new 0x8 'epics_mcs_flags' bit (ignore clears) to the 'epics_mcs' record. If this flag is set, then any commands to clear the MCS will be ignored. Instead the MCS will be cleared before the start of the next measurement. Added a just-in-time debugging option (-J) for 'motor' and 'mxserver' which invokes a debugger just after a crash. Added -m option to 'mxserver'. This tells the MX server to periodically display a brief description of its resource usage at a time interval in seconds specified by the argument to the -m option. Added thread-safe versions of Posix time functions such as localtime_r() for non-Posix build targets. Added EPICS support for the 'cygwin' build target. Support has been dropped for building MX support for EPICS 3.13. Please use EPICS 3.14 or above. Added MXF_SPAWN_NO_PRELOAD flag for mx_spawn() to keep spawned debuggers from being affected by things like LD_PRELOAD=/usr/lib/libefence.so. In addition, the unused suspend code for mx_spawn() has been deleted. Fixed an ancient bug in 'motor' where script files were not being closed after the script was executed. The symptom was that after approximately 1020 scripts had been run, attempts to run new scripts would abort with a 'Too many open files' error. Fixed bugs in the handling of MXFT_RECORD, MXFT_RECORDTYPE, and MXFT_INTERFACE fields by mx_copy_array_to_buffer(). Fixed the handling of multidimensional string arrays in network RAW mode. Moved some file descriptor handling functions to mx_io.c. Changed a number of long and unsigned long variables to int32_t and uint32_t for 64-bit compatibility with data structures that must be 32-bit. Version 1.5.1 (10/29/09): MX now supports Windows 7 and Visual Studio 2008. New Device Drivers: handel, handel_network, handel_mca, handel_input, handel_sum, and handel_timer: New preliminary MCA drivers for the DXP-XMAP from Xray Instrumentation Associates that exclusively use Handel -specific APIs. The previous generation of 'xia_...' drivers still used Xerxes style parameter names, even when making calls to Handel. Although the drivers seem to work (except for handel_timer), they have not been used for real experiments yet. prologix - This new GPIB driver has been tested with Prologix GPIB-USB controller from www.prologix.biz. The driver should work with the GPIB-ETHERNET controller as well but this has not been tested. spellman_df3, spellman_df3_ain, spellman_df3_aout, spellman_df3_din, spellman_df3_dout: A group of drivers for the Spellman DF3/FF3 series of high voltage power supplies for X-ray generators. systron_donner_m107 - Driver for the Systron-Donner M107 DC voltage source. epics_ccd - MX area detector driver for the EPICS CCD record. mca_weighted_sum - This is an analog input driver that reports weighted sums of MCA regions of interest. function_generator_scaler - MX scaler driver for a software emulated scaler that acts like a function generator. Updates to the 'ilm' and 'cryojet' drivers from Henry Bellamy of CAMD at Louisiana State University. The 'marccd_shutter' record can now talk to a 'marccd_server_socket' record. The MX 'epics_mca' driver now supports the DXP-XMAP based Vortex detectors available in the Advanced Photon Source detector pool. MX scans now put all of the MCA output spectra for the scan into a subdirectory which has a name derived from the scan output file name. If a scan uses 'SFF' format headers, then any MCA files written by that scan also have 'SFF' headers. Similarly, 'XAFS' headers are added to MCA files written by scans using 'XAFS' format headers. Added support for a multichannel scaler (MCS) 'clear_deadband'. If an MCS clear is commanded and the time since the last clear is less than the clear deadband _and_ no new start has been commanded, then the clear is skipped. This was done for performance reasons. When running a 'motor' script, 'motor' now first looks for the script name with the string '.mtr' appended. If not found, it then looks again for the script _without_ the string '.mtr' appended. In addition, 'motor' now supports a new environment variable MX_MOTOR_PATH. If MX_MOTOR_PATH is defined, 'motor' now searches this path to look up motor scripts specified for the '@' command. The 'setup scan' command in 'motor' has been changed so that aborting a new scan setup preserves any existing scan with the same name. Brought up to date the text for the top level 'help' command of the 'motor' program. In 'motor', a command like 'help set', 'help ad', etc. now redirects the individual help messages for each of the commands. 'setup scan' and 'modify scan' in 'motor' now inform the user during the scan setup if they have selected an input device name that does not exist, rather than waiting until the scan is executed. The 'mca rawread' and 'mca rawcount' commands in 'motor' now allow you to abort the display of output by typing 'q'. Added a 'show scas' command to 'motor' and rearranged the precedence so that a 'show sca' command now returns a list of scans. Added a 'rename scan' command to 'motor'. The 'ls330_motor' driver for Lakeshore 330 temperature controllers now handles soft aborts by directly sending a raw LS300 command instead of using mx_motor_move_absolute(). The previous procedure of using mx_motor_move_absolute() could mistakenly 'abort' the abort if the current temperature was outside the soft limits of the motor record. Modified 'motor' so that amplifier gains that are >= 10000 are shown in exponential notation. Improved the behavior of pause/retry logic in MX scans. Input scans now work correctly if 'scan_early_move' is set. The 'vcc_monitor' program for monitoring changes to MX network fields now supports some interactive commands: a - Add new callback d - Delete existing callback l - List existing callbacks q - Quit Added a new MX_NETWORK_OPTION_WORDSIZE option to allow MX network clients to find out the wordsize of the server. If the wordsize of the client and the server are different, it is necessary for them to communicate using XDR format even if the data formats are the same. Added a new mx_breakpoint() function. If a debugger is not currently running, then this will start the debugger. If a debugger _is_ running, then this will generate a breakpoint trap back into the debugger. Not currently implemented for all platforms. Added a new mx_analog_input_clear() function. This is intended for use with analog input devices that can latch a value. Added new 'mxserver' debugging infrastructure: Implemented mxserver "enable remote breakpoint" option '-r'. Added a new 'mx_database.breakpoint' network field. This is only active if remote breakpoints have been enabled by the '-r' option listed above. Added a new 'mx_database.debugger_started' network field. Writing 0 to this resets the internal mx_debugger_started flag, so that calling mx_breakpoint() again will spawn a new debugger session. EPICS changes: MX code that communicates with EPICS has been changed to be 64-bit safe by using 'int32_t' for all MX_CA_LONG variables. Replaced mx_epics_poll_for_events() with mx_epics_pend_event(). Added new mx_epics_pend_io() function. Added new wait_for_connection parameter to mx_epics_pv_connect(). Replaced the existing mx_epics_get_num_elements() function with mx_epics_pv_get_element_count(). Added mx_epics_pv_get_field_type() and mx_epics_get_element_size(). Replaced the old EPICS_IS_VERSION_... macros with a new MX_EPICS_VERSION macro to be used in conditional compilation macros for dealing with multiple versions of EPICS Base. Area detector changes: Lots of internal changes for the Aviex PCCD-16080 driver. Added a new 'use_dezinger' record field to provide a way of remotely turning on or off correction image dezingering. MX area detector drivers can now select at run time whether or not they implement dark current and flood field correction measurements using a multiframe sequence or a series of one-shot measurements. Currently, the Aviex PCCD-170170 and PCCD-4824 detector default to using multiframe sequences, while all others (including the PCCD-16080) default to using a series of one-shot measurements. The 'pmac_motor' driver now sets the direction of home searches using the Ixx23 variable. The Mclennan 'pm304' driver no longer looks at the state of the 'Not error' bit returned for the 'os' command. Updated the U500 drivers to send aborts followed by a fault acknowledge when starting up. The U500 motor driver now reports the motor as busy for up to 0.5 seconds after a move, even if the U500 hardware says that it is not busy. This is done because the U500 hardware may report the motor as in position for a short time after a move is commanded. For the 'mca_value' driver, the existing 'corrected_roi_integral' and 'corrected_soft_roi_integral' MX fields have been renamed to 'live_time_corrected_roi_integral' and 'live_time_corrected_soft_roi_integral'. The original names also exist as aliases. Also added the new 'rate_corrected_roi_integral' and 'rate_corrected_soft_roi_integral' fields. Added new mx_get_console_size() function that is intended to be used to match the number of lines displayed in paged text output to the actual size of the text console. Added 'mxupdate' support for MXFT_HEX fields. 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@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 . 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. Version 1.4.3 (08/14/07): Fixed an XAFS scan bug. If an XAFS scan was run with the 'early move' flag set, the energy of the last measurement for each XAFS region was written to the datafile incorrectly. Specifically, the recorded energy was set to the energy of the previous data point. This is now fixed. Version 1.4.2 (07/27/07): Fixed a bug that made it difficult to terminate running XAFS scans. Version 1.4.1 (06/04/07): Fixed a bug in the 'xia_network' driver which caused the driver to overwrite the last character of XIA parameter names with a null byte. Fixed a bug in the 'compumotor' driver that prevented the driver's 'set_position' function from working. The Win32 MX malloc wrappers originally written for use with the Borland C++ compiler are now being used by the Visual C++ compiler as well. These wrappers replace calls to the malloc() family of functions with calls to HeapAlloc(), HeapFree(), and HeapRealloc(). This was done to make it more likely that DLLs and EXEs compiled with the -MTd (static debug library) switch will work properly. In general, a DLL linked to the LIBCMTD.LIB library will use a C runtime heap for malloc(), etc. that is different from the C runtime heap used by the EXE. This can lead to crashes if memory allocated from one runtime heap is freed by the other runtime heap. The use of the MX malloc wrappers forces MX DLL code and MX EXEs to use the same heap and avoids the clashes. We recommend that you use the -MD switch (dynamic library) which links to MSVCRT.DLL, since it appears that DLLs and EXEs compiled this way all use the same C runtime heap by default. The mx_is_valid_heap_pointer() now invokes HeapValidate() on Win32 when _DEBUG is defined rather than _CrtIsValidHeapPointer(). This was done for compatibility with the new malloc() wrappers mentioned in the previous paragraph. If the requested length of a buffer passed to the functions mx_allocate_network_buffer() and mx_reallocate_network_buffer() is shorter than MXU_NETWORK_MINIMUM_MESSAGE_BUFFER_LENGTH, the length is now rounded up to MXU_NETWORK_MINIMUM_MESSAGE_BUFFER_LENGTH. The old behavior in this case was to return an MXE_WOULD_EXCEED_LIMIT error. 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 are supported. Camera Link drivers: epix_camera_link - This driver can be used to send and receive messages from a Camera Link controlled camera. RS-232 drivers: 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 the server. 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 move starts. 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 mx_setup_database_from_array(). 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 window. 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 strings. 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. Version 1.3.0 (08/08/06): This version of MX has added support for multiple virtual interval timers that are layered on top of a single real interval timer. The real interval timer is used to periodically update the state of all its dependent virtual timers and to invoke the virtual timer event handlers when necessary. This feature was added to compensate for the fact that most operating systems have a fairly small number of real interval timers (sometimes only one). MX can now successfully be compiled with Microsoft Visual C++ 2005 Express. Added interval timer support for BSD style kqueue() timers and Mach-based MacOS X timers using mach_wait_until(). New MX device drivers have been added: gated_backlash - This pseudomotor arranges for a gate signal to be generated while a backlash correction is in progress. The gate signal can be sent to an analog output, digital output, or relay record. This also required the addition of a new MX_MOTOR field called 'backlash_in_progress'. pulsed_relay - This record is a variant of the generic relay record that activates the relay for a specified length of time and then automatically deactivates the relay. The activation time is implemented using software timing, so the actual activation time may be longer than what was requested. xia_dxp_timer - This record is an MCA timer record for XIA DXP MCAs. When asked for its "last measurement time", it reports a value stored in the XIA interface record rather than a value stored in the timer record itself. This change ensures that all MCAs controlled by the same XIA interface will all report the same last measurement time. For this version of MX, the example programs that were originally distributed as a separate tar file examples.tar.gz have now been folded into the main MX distribution in the subdirectory 'examples/'. Added support for an MX local server configuration script that runs when the server is started and provides for local customization of the server's environment. This script is normally found at the location $(MXDIR)/etc/mx_local_config. If this script is not found, then it is ignored. The 'aps_gap' pseudomotor driver for Advanced Photon Source insertion devices has been updated to use the new nomenclature for EPICS insertion device PVs. Existing PVs such as ID10:GapSet.VAL have been renamed to ID10ds:GapSet.VAL. This change was made by the APS to provide for undulator straight sections that have two insertion devices rather than one. If a sector has two insertion devices, the additional one will have a name like ID10us:GapSet.VAL. In MX configuration files, use subtypes of 1 (mm), 2 (keV), 3 (taper mm), and 4 (taper keV) for the downstream device and values of -1, -2, -3, and -4 for the corresponding upstream device if any. The 'picomotor' drivers for New Focus Picomotor controllers have now been restructured to support multiple controllers at a time. They have also been revised to include a command retry loop, since there are some situations in which commands can get lost. New options have been added to the mx_database.status field. You can now execute commands like the following: mxput server:mx_database.status cpu_type to get a description of the CPU architecture, word size, endianess, etc. on the MX server log. mxput server:mx_database.status process_memory to get a description of the current memory usage of the process executing the server on the server log. mxput server:mx_database.status system_memory to get a description of the total memory usage of the computer that runs the server on the server log. MX support for the XIA Xerxes libraries has been changed so that calls to dxp_readout_detector_run() only readout the array that is being used by the current operation of either reading a spectrum or reading a baseline. This eliminates a bit of unnecessary overhead. In addition, the MX XIA Xerxes support now maintains its own flag for whether or not a run should be in progress, so that calls to mxi_xia_xerxes_stop_run_and_wait() will return immediately unless this is the first call to the function since dxp_start_run() was invoked. Fixed a bug in the MX drivers for the XIA Xerxes and Handel libraries that caused a buffer overrun crash if the number of spectrum bins reported by the XIA firmware was smaller than the length of the spectrum array allocated by MX. A new define HAVE_XIA_XERXES has been added to libMx/mxconfig.h in addition to the existing HAVE_XIA_HANDEL definition. The two definitions now separately describe whether or not the Xerxes or the Handel APIs can be directly called. This change reflects the fact that some recent distributions of Handel do not provide .LIB and header files for directly invoking Xerxes functions. Revised temporary file handling in the 'xia_xerxes' driver so that it uses GetTempPath() and GetTempFileName() to construct the name of the temporary modules file. This means that the temporary files are no longer created in the 'C:\' directory, but instead are created in a user specific directory. The 'network_rs232' driver has been modified to check the version of the remote MX server before doing I/O. Current versions of MX use the MXFT_CHAR datatype for 'getchar' and 'putchar', but versions of MX prior to MX 1.2.0 used MXFT_INT for this. The new fix ensures that the MX 1.3.0 'network_rs232' driver can talk to RS-232 ports controlled by both new and old MX servers. Added support for the mx_scanlog_info(), mx_set_scanlog_enable(), and mx_get_scanlog_enable() functions. This allows MX scan progress messages to be handled separately from other informational messages. This was done for the sake of users that do not want to see the scan progress messages, but do want to see other informational messages. In addition, the 'motor' program now has two new commands, namely, 'set scanlog on | off' and 'show scanlog' which are used to turn on or off this feature. In this version of MX, the old 'motor.shared' executable on Unix-like systems has been renamed to 'motor' and the old 'motor' shell script has been eliminated. In addition, the defaults of the new version of the 'motor' executable have been changed to match the defaults of the old 'motor' shell script. This change has been done for compatibility with Debian's policy discouraging shell script wrappers. For the sake of uniformity, on Win32 and DOS platforms the old 'motorbin.exe' program has been renamed to 'motor.exe' and the old 'motor.bat' batch file has been eliminated. A new set of functions for constructing MX control system filenames has been added in 'libMx/mx_cfn.c'. This set of functions makes it easier to ensure that all control system filenames such as database names, logfile names, etc. are accessed using standardized directory locations. The actual directory locations are specified in a header file called 'libMx/mx_cfn_defaults.h'. At present, MX can be configured to use one of two standard sets of directory locations. The default set uses the traditional pattern of storing all system-wide files in subdirectories of the main $(MXDIR) directory where MXDIR defaults to "/opt/mx". The alternate set is designed to be compatible with the Linux Standard Base directory layout as is accessed by defining the HAVE_LSB macro at compile time. The original motivation of this addition is to make it easier to build Debian packages of MX that conform to Debian standards. 'motor' and 'mxserver' have been modified to use these functions when finding their configuration files. Added a new macro MXP_PLOTGNU_COMMAND for specifying the command to be run when displaying two-dimensional plots. This macro replaces the explicit specifications of the command string that were previously found in a variety of places in the code. Added new mx_print_field_value() and mx_print_field_array() functions used to provide a more general mechanism for displaying MX record field values in application programs. A new function mx_get_cpu_architecture() has been added that returns two strings for an architecture type and an architecture subtype that describes the system that MX is running on. This feature is mainly designed for reporting purposes. A new function mx_connect_to_mx_server() has been added for the use of programs that only intend to do network MX gets and puts with a single MX server without explicitly setting up an MX database. Most MX programs should not use this feature and should use a database instead. Added do-nothing stubs for MXF_PTZ_PAN_POSITION, MXF_PTZ_TILT_POSITION, and MXF_PTZ_FOCUS_POSITION for the 'hitachi_kp_d20' pan/tilt/zoom driver when invoked by the mx_ptz_get_pan(), mx_ptz_get_tilt(), and mx_ptz_get_focus() functions. In previous versions, such calls for Hitachi KP-D20A/B cameras would return an error message. Minor updates to the 'pcmotion32' series of drivers for National Instruments ValueMotion motor controllers to make sure that they compile with this version of MX. Currently, I do not have access to any of these controllers, so that is all I can do at this time. Added support on the 'win32' build target for using the DUMA malloc debugging package from http://duma.sourceforge.net/ with the Microsoft Visual C++ compiler. DUMA is a fork of the Electric Fence debugging package from the Linux/Unix world that has been ported to Win32. It helps find memory overruns by deliberately causing an exception when an application program writes beyond the end of explicitly allocated buffers. WARNING: As delivered, DUMA is compiled with the -MLd flag to use the single threaded static C runtime library. MX cannot be compiled with the -MLd flag, so you must recompile DUMA with one of the allowed flag settings for MX, namely, -MD, -MDd, -MT, or MTd before linking DUMA to MX libraries. Makefiles for MacOS X have been changed to use 'gcc -dynamiclib' when building libraries instead of calling 'libtool' directly. Added FreeBSD specific support for getting the Pentium time stamp counter frequency in the MX high resolution timer functions in 'libMx/mx_hrt.c'. Version 1.2.0 (03/17/06): The focus of this release has been the addition of support for 64-bit operating systems. 64-bit operation has been successfully tested on the following platforms: alpha (Debian Linux 3.1, Tru64 Unix 5.1b, OpenVMS 8.2) amd64 (Red Hat Enterprise Linux 3, SuSE Enterprise Server 9.0) itanium (Debian Linux 3.1, Red Hat Enterprise Linux 4, FreeBSD 6.0, HP-UX 11, OpenVMS 8.2) mips (Irix 6.5) parisc (HP-UX 11) sparc (Solaris 10) Interoperability between 64-bit and 32-bit clients and servers has also been successfully tested. Please note that on platforms that support both 32-bit and 64-bit executables, you must uncomment the makefile macro USE_64_BITS in the appropriate Makehead.??? file in order to compile a 64-bit binary. As part of this change, new MX data types have been added and some old data types have been removed. Data types added: MXFT_BOOL - Intended for boolean values (TRUE/FALSE). MXFT_INT64 MXFT_UINT64 Data types removed: MXFT_INT MXFT_UINT For network communication, the old data types should be changed to the new data types as follows: MXFT_INT ----+----> MXFT_BOOL (for TRUE/FALSE values) | +----> MXFT_LONG (for all other 32-bit values) MXFT_UINT ---------> MXFT_ULONG Similarly, for MX database files, the following changes should be made: int --------+----> bool | +----> long uint -------------> ulong net_int ----+----> net_bool | +----> net_long net_uint ---------> net_ulong For example, a database definition like this id_ev_enabled variable net_variable net_int "" "" 10id id_ev_enabled.value 1 1 1 would be changed to look like this id_ev_enabled variable net_variable net_bool "" "" 10id id_ev_enabled.value 1 1 1 By contrast, a database definition like this id_ev_type variable inline int "" "" 1 1 3 should be changed to look like this id_ev_type variable inline long "" "" 1 1 3 The general pattern is that you should replace TRUE/FALSE variables with 'bool' variables and everything else with 'long' variables. One of the rationales for removing the old 'int' data types is reduce ambiguity in the use of data types. Traditionally, MX programs have treated 'int' and 'long' types as more or less equivalent. On most 32-bit platforms, you can get away with this. However, on many 64-bit platforms this is no longer the case and it was decided that the best way to reduce ambiguity was to eliminate the 'int' datatypes altogether. For this release, MX assumes the following word sizes for integral data types: char - at least 8 bits long short - at least 16 bits long long - at least 32 bits long int64 - at least 64 bits long These definitions are compatible with the ANSI C standards up to and including C99. Note that ANSI C actually only guarantees 'int' to be at least 16 bits long. For network communications via either RAW or XDR mode, the integral data types are truncated to the minimum number of bytes shown above. However, for RAW connections between 64-bit MX clients and 64-bit MX servers that have the same byte order (big-endian vs. little-endian), it is possible to configure the MX network connection to transmit the full 64 bits of 64 bit longs by setting the 0x10000 flag in the 'server_flags' field of the server record in the client's database. It might be possible to perform the same trick for XDR connections by bending the rules of XDR communication, but that has not been done for this release. Please note that by a careful choice of numerical datatype definitions, the modifications to MX network communication have been done in such a way that 32-bit and 64-bit MX 1.2.0 clients and servers should be able to interoperate with old 32-bit MX clients and servers that used the 'int' datatypes. This was mainly done by assigning MXFT_BOOL the same numerical value as the old MXFT_INT definition. New MX header files 'mx_stdint.h' and 'mx_inttypes.h' have been added to provide support for the new fixed length data types provided by the new C99 and header files. The reason for providing my own header files is to make sure that the C99 definitions are available on MX build targets that do not already provide such definitions. For example, on Linux the MX header files merely include the C99 header files, while for Microsoft Visual C++, the MX header files explicitly supply the missing definitions. For now, "mx_stdint.h" is guaranteed to provide definitions for int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t, intmax_t, and uintmax_t. The 'fast' and 'least' variants of these definitions are not currently implemented. The "mx_inttypes.h" header provides definitions for the PRI series of printf() macros for 8, 16, 32, and 64 bit integral types. The SCN series of scanf() macros provides similar support for the 16, 32, and 64 bit integral types. Unfortunately, it appears that it is not possible to provide support for the SCNd8, SCNu8, and SCNx8 macros on some platforms since the underlying vscanf() implementation only supports 8-bit types as ASCII characters rather as integers. Added a new header file 'mx_program_model.h' that specifies the integer programming model for the current platform. The most common programming models are ILP32 (32-bit ints, longs, and pointers) supported by most 32-bit computers and LP64 (32-bit ints, 64-bit longs and pointers) supported by most 64-bit computers except for Microsoft's 64-bit versions of Windows. The header file also defines a macro called MX_WORDSIZE for those cases where all you want to know is whether or not you are on a 32-bit or 64-bit computer. A new header file 'mx_xdr.h' has been added to manage the support of XDR data types by MX. In addition, the files 'xdr_hyper.c' and 'xdr_hyper.h' have been added to the 'tools' directory to provide support for the 64-bit 'hyper' XDR data type on platforms that do not already provide such support directly. The old header file 'mx_types.h' has been removed since its functionality has been replaced by the new 'mx_stdint.h' header file. The MX function API has been changed in a number of places to replace 'int' function arguments with either 'mx_bool_type' arguments or 'long' arguments. This has required matching changes in the MP and MxTcl packages for Python and Tcl. The general pattern has been to use 'mx_bool_type' for boolean values and 'long' for everything else. The reason for inventing a new type called 'mx_bool_type' rather than using the C99 'bool' or '_Bool' types is that as far as I know the C99 standard makes no promises as to how many bits there are in a 'bool' type, but I need a consistent definition of the number of bits in order to use them in network communication. Thus, 'mx_bool_type' has been defined to use a 32-bit integer type. If anyone can show me that the C99 standard _does_ guarantee that 'bool's are 32-bits or more, then I will be happy to replace 'mx_bool_type' with the C99 'bool'. Please note that for this release, we use 'long' and 'unsigned long' for the data values provided by the digital I/O, stepper motor, pulse generator, scaler, MCA, and MCS device classes. This means that you can only assume 32-bit precision in the values returned. Since I have not yet run into a piece of hardware that supports more than 32-bit values, I do not regard this as a significant limitation. If such a piece of hardware does appear, I will reevaluate what to do then. A large number of trivial changes to print and scanf format strings have been made for the sake of 64-bit compatibility. If you have any questions about the changes for 64-bit compatibility, do not hesitate to contact me (William Lavender) about this. ******************************************************************* In the meantime, a number of changes unrelated to the 64-bit transition have also occurred: The old, obsolete version of the "mxupdate" program that had been kept around for backward compatibility has now been deleted. Fixed an issue with "motor"'s "measure dark" command when used with the "epics_mcs" driver. It turns out that sometimes the "measure dark" operation was using many more MCS measurements than had actually been requested by the user. For example, if the user had just run a 3500 point MCS quick scan and then requested "motor" to perform a single point dark current measurement, it turns out that "motor" was actually making a 3500 point dark current measurement and then throwing away all but the first measurement. Thus, the dark current measurement would take 3500 times longer than the user had expected. This issue was fixed by adding a call to mx_mcs_set_num_measurements() in the clear() function of the 'mcs_scaler' driver. This location was chosen since it should have the least impact on the other current MCS drivers. Added code to the MX motor driver class and the "motor" program to distinguish between between tripping hardware limits and software limits in error reporting. At present, the "epics_motor" driver is the only driver taking advantage of this feature. Usually, on an EPICS MEDM display, the distinction between the two will be that tripping a hardware limit will display a red error message which exceeding a software limit will display a yellow error message. Support for this distinction will be added as time permits to the drivers for motor controllers that make this distinction themselves. Many motor controllers only have support for hardware limits. A variety of drivers have been updated to use the snprintf(), strlcpy(), and strlcat() functions instead of the older sprintf(), strcpy(), strcat(), strncpy(), and strncat() functions. This is because the new functions do a better job of protecting against buffer overruns. snprintf() is widely available on most MX build targest, but has been redefined as sprintf() on the small number of MX build targets that do not support it. strlcpy() and strlcat() are less well know. They are versions of the string functions for which you always provide the full length of the buffer you are copying to rather than expecting the programmer to provide a potentially faulty calculation of the unused length left in the buffer. Since most platforms do not currently support strlcpy() and strlcat(), versions derived from OpenBSD have been bundled with MX in the 'tools' directory. Added support for HP's Tru64 Unix operating system on 64-bit Alpha based computers. Updated support for the HP-UX operating system to HP-UX 11. Added preliminary support for the eCos real time operating system. This support has not yet been fully tested. Support for the Intel compiler on Linux has been updated to Intel C 9.0. Increased the buffer size for 'set_position' commands in the 'compumotor' driver. This was in response to reports of buffer overruns at CAMD. As it happens, the 'compumotor' driver is one of the drivers that has been updated to use the snprintf(), strlcpy(), and strlcat() functions, so this driver should be relatively immune to buffer overruns in the future. The Makefile for OpenVMS only works with some ports of Gnu make and not others. Some explanatory text has been added to that makefile to indicate which version of Gnu make should be used. The 'smartmotor_aout' driver was actually reading from the output pin rather than writing to it. This has been fixed. Fixed a bug in the 'mc6821' digital I/O interface driver. Until now, the data direction for port B had incorrectly been set to the data direction requested for port A. Version 1.1.1 (01/11/06): A new build target 'win32-mingw' has been added for building MX with the MinGW compiler on Win32. This target has been tested using MinGW 4.1.1 and MSYS 1.0.10 on Microsoft Windows. The source for the 'mxserial' program, which was previously distributed separately, has now been folded into the main MX source code distribution. The source may now be found in the file 'mx/util/mxserial_fork.c'. The name of the file reflects the fact that it still only works on platforms that fully support the fork() system call. We expect to add a version for Win32 at some later date, although the Cygwin version _may_ work now (untested). MX has added a new device class called PTZ for Pan/Tilt/Zoom camera controllers. Note that these drivers only move the camera or change its settings such as focus or zoom. They do not read out the actual picture image. The following devices have had drivers added for this release of MX: Hitachi KP-D20A/B cameras: hitachi_kp_d20 - MX PTZ driver. The hardware only allows the zoom to be controlled. Panasonic KX-DP702 cameras: panasonic_kx_dp702 - Interface driver for the controller. panasonic_kx_dp702_ptz - PTZ driver for an individual motion. Sony VISCA cameras (tested with the EVI-D100): sony_visca - Interface driver for the controller. sony_visca_ptz - PTZ driver for an individual motion. MX network PTZ controllers: network_ptz Software emulated PTZ controllers: soft_ptz Motor driver: ptz_motor - Controls the pan, tilt, zoom, or focus of an MX-controlled PTZ as an MX motor. This allows you to do things like step scan the pan, etc. MX has added initial support for communicating with the Blu-Ice and Distributed Control System from SSRL described at http://smb.slac.stanford.edu/public/research/developments/blu-ice/ This initial version supports running MX as what Blu-Ice calls a "GUI client", although there is nothing on the MX side that requires the use of a GUI. Additional support for acting as a Device Hardware Server (DHS) will be added in a future release. The Blu-Ice related drivers added to this release include: Servers: bluice_dcss_server - Manages the connection to a Blu-Ice DCSS server. Devices: bluice_ion_chamber - Reads out values from a Blu-Ice ion chamber as an MX analog input device. bluice_motor - Operates a Blu-Ice motor as an MX motor. bluice_shutter - Operates a Blu-Ice shutter as an MX relay. bluice_timer - Acts as an MX timer for Blu-Ice controlled ion chambers. Variables: bluice_command - Sends a raw Blu-Ice command to a remote DCSS. bluice_master - Used to request that the MX client either become a Blu-Ice master or a Blu-Ice slave. bluice_string - Reads the value of a Blu-Ice string. Added optional timeout functionality to MX network connections using non-blocking socket I/O. The timeout is turned on by setting flag 0x10000000 in the server_flags field of the MX server database record. If the timeout is turned on, it currently is set to 5 seconds, although this can be changed at run time with a motor command like 'set field 10id.timeout 2' to change the timeout to 2 seconds. Non-blocking socket I/O has been disabled for Solaris 10 for now since performance testing showed that it was _really_ _slow_ for some unknown reason. By contrast, Solaris 8 has no such problem. I do not have access to a Solaris 9 machine to check this on, so I have disabled non-blocking socket I/O there as well just to be safe. I will check into this issue further at some later date. New socket I/O functions mx_socket_set_non_blocking_mode() and mx_socket_ioctl() to consolidate the rather platform specific code related to these functions in one place. Added a new function mx_initialize_runtime() to consolidate all of the non-database related initialization of MX into one place rather than having copies of this initialization duplicated in all of the MX application programs. This change was motivated by the need to make calls in all MX program to _control87() and _matherr() for the 'win32-borland' build target to disable floating point exceptions enabled by the Borland C++ compiler that are not enabled by the Microsoft compiler. The directories of test files bundled with MX have been reorganized to all live under a single directory called 'test'. The old directories have been renamed as follows: test ---> test/drivers testserver ---> test/server testupdate ---> test/update In addition, there is a new directory called 'test/features' which currently contains test cases for the interval timer, mutex, semaphore, and thread support described further below. The 'xia_handel' driver has now been successfully tested with the DXP-2X based multielement detector system at MR-CAT (APS sector 10). It appears that the main reason we were having problems with this before was that we were using configuration files that had the gain for some detector channels set to 0. Apparently this happened since we did not realize that certain error messages generated by the Mesa2X configuration program meant that the Mesa2X-generated configuration file would contain some channels with gains set to 0. This has now been fixed. For XIA Handel controlled MCAs, starting a run in a single detector channel does not necessarily start the run in all channels. For this reason, a new MX timer driver has been added for use only with Handel: xia_handel_timer - Uses xiaStartRun() to start the MCA counting in all detector channels. MX interval timer support is now available on all MX platforms. Bear in mind that on most platforms the timer callback is implemented in a separate thread, so the timer callback needs to be thread safe. However, some platforms have significant limitations on the support: 1. The MacOS X, BSD, and DJGPP targets currently use setitimer() based interval timers using ITIMER_REAL since they do not support Posix realtime timers. This is bad since there can only be one such timer per process. Even worse, on MacOS X and BSD the timer is SIGALRM based, which is _very_ bad since many different systems, features, and libraries on Unix-like systems all try to use SIGALRM, so there is a significant danger that different pieces of code will fight over the control of SIGALRM. For a future release, I will investigate whether the underlying Mach system provides a way around this problem for MacOS X. 2. The Solaris, Irix, and VxWorks targets use Posix realtime timers with SIGEV_SIGNAL notification which restricts the number of interval timers to the value (SIGRTMAX - SIGRTMIN + 1). On Solaris this value is only 8, while on VxWorks it is only 7. The following related MX driver has been added: interval_timer - An MX timer driver that uses the new interval timer functionality. It is primarily intended for testing MX interval timers, but it may be used as an alternative to the 'soft_timer' driver as well. A set of functions called mx_signal_allocate() and mx_signal_free() for managing the allocation of signals has been added. These functions are advisory only since in general the underlying operating systems do not support such a feature. At present, these functions are only used by the MX interval timer support. MX now includes support for threads in a platform independent fashion. This includes support for stopping threads, killing threads on some platforms, and waiting for a thread to terminate. In addition, support for thread-specific data is included. Support for threads is available on all MX platforms except DJGPP. MX mutex support is now available for all MX platforms except DJGPP. Since DJGPP does not support threads, the mutex lock, unlock, and trylock functions are all stubs that return MXE_SUCCESS on that platform. MX now includes support for counting semaphores. In principle, both named and unnamed semaphores are supported. However, not all features of the MX semaphore implementation are supported on all platforms since the underlying operating systems do not uniformly provide the necessary features. I will attempt to clean this up better in a future release. See the file 'mx/libMx/mx_semaphore.c' for the details of the current limitations which are too complicated to describe here. The Struck SIS3801 MCS has now been successfully tested with firmware version 9 using both the 'sis3801' driver and the 'epics_mcs' driver. This change increases the maximum time per point from 1.67 seconds to 26.8 seconds. We have also found that the SIS3801 external next pulse feature finally works with firmware version 9, whereas it did not work for us with earlier firmware versions. We have now successfully tested using the SIS3807 pulse generator with version 4 firmware as an external next pulse source for the SIS3801 using version 9 firmware. When using this combination, the maximum time per point becomes 14.27 years (!) which should be long enough for anyone. The largest time per point that I have actually tested the system with is 1000 seconds. Added a bug fix for the 'epics_mcs' driver when used with recent versions of the EPICS MCA record. We have encountered a problem where the initial connection to the 'Acquiring' PV times out, but subsequently works fine after the connection is made. The typical symptom was that the first quick scan run in a given copy of 'motor' would fail with this error, but subsequent quick scans would work. For now, we are dealing with this by intentionally reading the value of the 'Acquiring' PV during MX startup to get the timeout out of the way before running the first user commands. We also now send a stop command before starting acquisition, since starting an already started MCS did not always work correctly. In addition, the driver now sets the preset real time to 0 when the number of MCS measurements is selected. This is to stop MX MCS scans from terminating early. Previously, the MX 'monochromator' driver was invoking the function mx_motor_save_speed() during its open routine. You should _never_ do this. If you do, then if you happen to start 'motor' when a quick scan is in progress in another copy of 'motor', you will overwrite the saved motor speed with whatever speed the motor happens to have at that moment. This has now been fixed. Hopefully this will get rid of the cases where the monochromator has the wrong motor speed after a quick scan completes. In a related change, MX scans now only save the motor speeds for quick scans at one single place in mx_perform_scan(). In addition, mx_scan_restore_speeds() is now also invoked for quick scans near the end of mx_perform_scan() to guard against the possibility that a lower level routine did not already restore the speeds. The 'aps_gap' driver for Advanced Photon Source insertion devices has been modified to add the ability to change the undulator taper in units of mm or keV. The 'pm304' motor driver has been modified to add an extra 'minimum_event_interval' field for testing the maximum rate at which commands can be sent to the controller. Applied Jim Fait's patch that modifies the 'pmac_cs_axis' motor driver for PMAC coordinate system axes so that it better handles aborts. We also added a 'set position' function to that driver. Fixed a bug for the 'compumotor' driver in the 'set_position' function. Previously, a 'set_position' command for one motor would screw up the positions for all the other motors controlled by a given Compumotor controller if those other motors used MX scale factors that were not 1.0. The driver has now been fixed so that it uses the correct raw units rather than user units when redefining the position. Modified the 'mca_timer' driver so that it more correctly performs time normalization. Datafiles created by MX scans are now written in line buffered mode. MX scan databases whose names contain embedded spaces are now correctly updated by 'motor'. 'motor' scripts now may use the '#' character as a comment character. A new function mx_info_entry_dialog() has been added along with matching set and default functions. This function is designed to display a prompt to the user and then read in a line of response. It has provision for suppressing echoing of characters typed in response. This feature was added to support prompting the user for a username and password when connecting to Blu-Ice servers, but will obviously be useful in other circumstances as well. The driver arrays for MX classes and superclasses have been split off into a new file 'mx/libMx/mx_driver_class.c', while the driver arrays for MX types have been left in 'mx/libMx/mx_driver.c'. The motivation for this change is to make it easier to link in only a subset of the MX drivers on a platform with constrained memory such as a VME crate. If you are on a workstation platform and want to link in all the available drivers, you need not pay any attention to this change. There are several steps required to link in just a subset of the drivers: 1. The definition MX_LIB_SRCS in 'mx/libMx/Makefile' has been split into three parts, namely MX_CORE_SRCS, MX_DRIVER_SRCS, and mx_driver.c. The makefile also provides a default definition of MX_LIB_SRCS that merely recombines the three parts, namely: MX_LIB_SRCS = mx_driver.c $(MX_CORE_SRCS) $(MX_DRIVER_SRCS) 2. Using VxWorks as an example, go into 'mx/libMx/Makehead.vxworks' and create a new definition MX_DRIVER_VXWORKS_SRCS that lists only the source code for the drivers you really want. Then create a new version of MX_LIB_SRCS like this: MX_LIB_SRCS = mx_driver_vxworks.c $(MX_CORE_SRCS) $(MX_DRIVER_VXWORKS_SRCS) Bear in mind that some driver files depend on other driver files. For example, you can't have the motor driver 'd_compumotor.c' without including the controller driver 'i_compumotor.c'. If you leave out 'i_compumotor.c' in this example, the library will successfully compile, but it will be impossible to create a working database that uses Compumotor-controlled motors. 3. The last step is to create a new 'mx/libMx/mx_driver_vxworks.c' that only contains references to the drivers you want. The easiest way is to make a copy of 'mx/libMx/mx_driver.c' and just delete the driver table entries you do not want. You will want to delete the corresponding include files as well, since they take up space too. If you do this correctly, you will end up with a version of libMx that uses up much less memory. Nevertheless, on workstation platforms with hundreds of megabytes of memory or more, it is simpler just to leave things as they are and link in all the drivers. This version of MX has started the replacement of buffer overflow prone functions with alternatives that are not prone to this problem. At present, this means the replacement of strcpy, strcat, strncpy, strncat, sprintf, and vsprintf with strlcpy, strlcat, snprintf, and vsnprintf. The new functions are not universally available on all MX platform, so we have bundled slightly modified versions of strlcpy and strlcat from the OpenBSD people and fallbacks to sprintf and vsprintf for those platforms that do not yet have snprintf and vsnprintf. There are a lot of uses of the old functions in MX code, so this change will not occur all at once. MX already had some workalike functions called mx_strncpy and mx_strappend. These have been replaced with the corresponding strlcpy and strlcat calls. The old keyboard interface files key*.c have been folded together into a new file 'mx/libMx/mx_key.c'. In addition, the new functions mx_key_echo_off(), mx_key_echo_on(), and mx_key_getline() have been added to provide a way of entering passwords without echoing them to the screen in a platform independent way. Bear in mind that while the key echo on/off functions will affect all output on _some_ MX platforms, only mx_key_getline() is guaranteed to pay attention to the echo on/off state on _all_ MX platforms. A new file 'mx/libMx/mx_os_version.c' has been added to provide a platform independent way of getting the operating system version at run time. This was done to allow programs to use one binary on multiple versions of an operating system in cases where different things have to be done on different versions. It also provides a way of displaying the operating system version to the user for documentation purposes. On Win32, the implementation of mx_heap_check() has now been changed. When compiled to link with the debug libraries, it uses the function _CrtCheckMemory() as before. However, when compiled to link with the release libraries, it loops over all the heaps returned by GetProcessHeaps() and invokes HeapValidate() on each heap. We have had a variety of problems with memory allocation functions when using the Borland C++ compiler on Win32 including both memory leaks and also things like programs hanging in malloc(). For this reason, we have written our own Borland-specific replacements for malloc(), free(), calloc() and realloc() which call directly to the underlying Win32 Heap() functions. The source for this may be found in 'mx/libMx/mx_util_borland.c'. Some new preprocessor tests in 'mx/libMx/mx_util.h' are used so that calls to malloc, etc. are redirected to the functions bc_malloc(), etc. instead when compiled with Borland C++. We have not yet had a chance to see if this makes the memory leak problem go away, but it definitely makes the hanging in malloc() problem go away. The 'mx/libMx/os_rtems*.h' header files have been revised to work better with RTEMS 4.6.5. There are still some outstanding issues, so we have more work to do on this. The 'sunos4' and 'linux-kylix' build targets have now been declared obsolete since the original vendors no longer support them and the software no longer works on recent systems. The files used by these targets have been moved to the 'mx/misc' directory and will be removed in a future release. Added a new function mx_string_split() that allows us to split a string into tokens. It is similar to strsep() except for the fact that it treats a string of several delimiters in a row as being only one delimiter. By contrast, strsep() would say that there were empty tokens between each of the delimiter characters. A couple of functions in the file 'mx/libMx/mx_util.c' have been split off into a new file 'mx/libMx/mx_util_cfaqs.c' to reflect the fact that they are covered by a different license since they were derived from the book 'C Programming FAQs'. 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. Version 1.0.2 (08/27/04): EPICS 3.14.5 and 3.14.6 have implemented a change in how process variable virtual circuits are managed by Channel Access. MX versions prior to 1.0.2 are not compatible with this change which can result in intermittent process variable circuit disconnects if more than 35 seconds elapses without any communication with EPICS. The symptom of this problem is the appearance of EPICS messages that include the string 'virtual circuit unresponsive'. MX 1.0.2 has implemented a hopefully temporary workaround for this issue that seems to work successfully with EPICS 3.14.6 without noticeably degrading the operation and performance of MX. This 'virtual circuit unresponsive' error has also been reported for a variety of non-MX applications, so there is some reason to believe that the EPICS developers will provide their own workaround for this soon, perhaps in 3.14.7. If and when they do this, it should then be possible to remove MX's own workaround. Only time will tell. An alternate workaround is to compile and link MX with EPICS 3.13.x which is unaffected by this issue. Note that EPICS versions 3.12.x and before are no longer supported by MX. MX now has support for communicating as a client with a remote Spec server (http://www.certif.com/) via the client/server Spec protocol introduced in Spec 5.x. At present, the following set of MX drivers is now available: spec_server - A server driver for communicating with the remote Spec server. spec_command - This is a pseudo RS-232 driver that works in a manner similar to the remote_eval() command of Spec itself. The way you use this driver is to use mx_rs232_putline() to send a command to the remote Spec command line. You then read the response back with mx_rs232_getline(). spec_motor - Sends commands to a motor controlled by a remote Spec server. spec_scaler - Sends commands to a counter controlled by a remote Spec server. spec_timer - Sends commands to a timer controlled by a remote spec Server. spec_string, spec_char, spec_uchar, spec_short, spec_ushort, spec_long, spec_ulong, spec_float, spec_double - These are variable drivers used for getting and setting remote Spec properties. They have been tested with single valued number and string properties, while the 'spec_string' driver has also been tested with Spec associative-arrays. The newer Spec data-array properties are not yet supported. Added support for Aerotech Unidex 500 motor controllers using the Aerotech provided Win50032.dll library on Microsoft Windows Win32 platforms. The supported drivers are: u500 - This interface driver operates the Unidex 500 controller as a whole. At present, the driver has been tested with only one board in the computer. u500_motor - This driver controls one particular motor on a Unidex 500 controller. You must set the definition HAVE_U500 in 'libMx/mxconfig.h' to 1 in order to use this driver. Added support for Keithley 2400 series SourceMeter multimeters. The supported drivers are: keithley2400 - This is the interface driver for the controller as a whole. keithley2400_ainput - This driver can measure voltages, currents, and resistances using a Keithley 2400 input channel. keithley2400_aoutput - This driver can control voltage and current outputs for a Keithley 2400. keithley2400_doutput - This driver can control digital outputs for the Keithley 2400 which are typically used for interlocks. Added support for Keithley 2700 series switching multimeters. The supported drivers are: keithley2700 - This is the interface driver for the controller as a whole. keithley2700_ainput - This driver can measure voltages, currents, resistances, temperatures, frequencies, periods, and continuity using a Keithley 2700 input channel. keithley2700_amp - This driver uses its gain setting to control the range used for voltage, current, and resistance measurements. MX now has support for being compiled on the Microsoft Windows Win32 platform with the Borland C++ compiler. The MX_ARCH platform name to use in the top level Makefile is 'win32-borland'. And, of course, there is also a 'libMx/Makehead.win32-borland' file for configuring Borland-specific options. The 'win32-borland' platform has been tested for Borland C++ 5.5.1. A new interface class for USB interfaces has been added to MX. The first interface driver written for this class is the MX 'libusb' driver that interfaces with the libusb library commonly found on Linux (http://libusb.sourceforge.net/). Theoretically, the 'libusb' driver probably can be made to work on MacOS X, the BSDs, and even Win32 via http://libusb-win32.sourceforge.net/, but so far the support has only been tested on Linux. Since this is a new class, there may be minor changes and additions to the class interface as more experience is gained with talking to USB devices. At present, the 'usb' class has support for talking with USB control endpoints and bulk transfer endpoints. You must set the definition HAVE_LIBUSB in 'libMx/mxconfig.h' to 1 in order to use the 'libusb' driver. The first device drivers for USB controlled devices are the MX 'phidget_old_stepper' and 'phidget_old_stepper_controller' drivers for the old non-HID stepper motor controller that used to be advertised by Phidgets Inc. (http://www.phidgets.com). This controller may still be available if you ask Phidgets Inc. for it, but they have now moved to HID-based motor controllers which are not yet supported by MX. The MX_CLOCK_TICK structure defined in libMx/mx_clock.h has been modified to change the 'low_order' variable from a 'clock_t' to an 'unsigned long', since 'clock_t' generally is defined as a 'long'. For operating systems that use a 100 Hz timer (Solaris, most types of Linux, etc.), a 'long' version of 'clock_t' will overflow after 248.55 days. This change was made after tests of MX 1.0.2 on a Solaris machine that had been up for 345 days showed that MX was not handling the overflow correctly. Changing to an 'unsigned long' pushes the limit off to 497.1 days without a reboot. I would like to be able to support even longer uptimes, but I do not currently know how you detect in software that over 2^32 clock ticks have occurred. Presumably this is a platform specific issue. The MX 'epics_motor' record now contains support for Brian Tieman's portable channel access-based motor record used for Aerotech U500 motor controllers. For recent versions of the EPICS motor record, the MX 'epics_motor' record was incorrectly detecting the direction sense of limit switch trips if the EPICS '.DIR' field was set to 'Negative'. This has now been fixed. Added a new 'pfcu_filter_summary' driver that reports the status of all of the filters in an X-ray Instrumentation Associates PFCU filter controller as a single integer with one bit for each filter. The MX drivers for X-ray Instrumentation Associates MCAs now distinguish between what they calls 'rate-corrected' ROI integrals and what they calls 'livetime-corrected' ROI integrals. The difference is that the 'rate-corrected' ROI only corrects the raw ROI integral by multiplying it by the ratio of the input count rate to the output count rate, while the 'livetime-corrected' variant additionally multiplies by the ratio of the real time to the live time. XIA itself recommend that you use the version I am calling 'livetime-corrected' here, however there are users that prefer the 'rate-corrected' version. Some changes have been made in the 'file_list_scan' scan driver. If you do not know, file list scans do not generate the motor positions for each step of a step scan by computing them internally. Instead, they read the requested motor positions for each step of the step scan from a file that enumerates all of positions with each column corresponding to a motor and each row corresponding to a measurement. The 'file_list_scan' driver has now been modified to add an additional first column which either contains the requested measurement time for a 'preset_time' scan or the requested scaler counts for a 'preset_count' scan. This change lets each point of the scan have a different measurement time or preset count. If you want all of the measurements to have the same measurement time, then set all the values in the new first column to the same measurement time. The 'resynchronize' operation for the MX PMAC coordinate system driver 'pmac_cs_axis' now sends 'A' and 'ABS' commands at the end which aborts all programs and moves in the current coordinate system and then makes sure the motors are in absolute positioning mode. For some reason, the MX server did not include the code necessary for it to run home searches. This has now been fixed. The MX MarDTB support now includes support for operating the MarDTB X-ray shutter via the 'mardtb_shutter' driver. Bear in mind that this driver and the related 'mardtb_status' drivers only report their current status correctly if the vendor's 'marccd' program is running at the same time. Otherwise, the reported status reflects the values that were last read by 'marccd'. Some effort has been put into exploring what would be necessary for the MX drivers to get the correct current status even when 'marccd' is not running, but this does not work correctly yet. In fact, getting current status while 'marccd' is not running may not be practical with MarCCD/MarDTB as they currently exist. A mistake was found and fixed in how the MX 'pmac_bio_motor' driver was allocating memory for its data structures. This driver is used at APS sector 18 for controlling PMACs via the EPICS databases originally written by Tom Coleman. Modified mx_copy_array_to_buffer() and mx_copy_buffer_to_array() in libMx/mx_array.c to copy scalar data using memcpy() rather than using explicit pointer dereferencing. On Irix, at least, dereferencing double pointers, int pointers, etc. on nonaligned pointer addresses was causing bus errors. However, memcpy() can operate on arbitrarily aligned pointer addresses which eliminates the problem. The MX GPIB class has removed the top-level functions mx_gpib_read_parms_from_device() and mx_gpib_write_parms_to_device() and the code that used to be in the 'read_parms_from_device' and 'write_parms_to_device' driver functions have been folded into the corresponding 'open_device' and 'close_device' driver functions. All of the MX GPIB interface drivers have been modified to make this change. The drivers for the Oxford Instruments ITC503 now check to see if the serial port parameters have been set correctly at startup time. mx_measure_data(), mx_compute_normalized_device_value(), and mx_convert_normalized_device_value_to_string() have now added support for 'relay' records that was previously missing. The naming convention for functions in the recently added 'mcai' class has been changed from mx_multichannel_analog_input_... to mx_mcai_.... Version 1.0.1 (05/28/04): MX analog input records now have support for dark current subtraction in a manner similar to the way dark currents are already supported for MX scaler records. This change has required the addition of two new fields 'dark_current' and 'timer_record_name' to each database entry just after the existing 'analog_input_flags' field. For example, an existing database entry like x_curr device analog_input network_ainput "" "" 0 0.01 0 amps 0x0 rbserv x_curr must be changed to x_curr device analog_input network_ainput "" "" 0 0.01 0 amps 0x0 0 "" rbserv x_curr The bit definitions for the 'analog_input_flags' field for analog input records have been changed to follow the existing pattern for 'scaler_flags' in scaler records and are currently defined as #define MXF_AIN_SUBTRACT_DARK_CURRENT 0x1 #define MXF_AIN_SERVER_SUBTRACTS_DARK_CURRENT 0x2 #define MXF_AIN_PERFORM_TIME_NORMALIZATION 0x1000 Please note that MXF_AIN_PERFORM_TIME_NORMALIZATION _used_ to have the value 0x1. This has been changed to make it possible for the dark current flag settings to be the same for both MX analog input and scaler records. The precise behavior of these new analog input features depends on how the record is configured: 1. If neither dark current flag is set then, of course, nothing is subtracted. 2. If the MXF_AIN_SERVER_SUBTRACTS_DARK_CURRENT flag is set then MX does not subtract a dark current, since the server is assumed to have done that for it. 3. If MXF_AIN_SUBTRACT_DARK_CURRENT is set, then: 3A. If the 'timer_record_name' field is empty, the dark current is assumed to be an absolute value and is directly subtracted from the reported value. 3B. If a timer name has been specified, the dark current is stored normalized to counts per second. The MX runtime asks the timer record for the length in seconds of its last measurement and multiplies that by the normalized dark current to compute an offset to be subtracted from the reported value. The already existing feature MXF_AIN_PERFORM_TIME_NORMALIZATION is used for determining whether the reported analog input value is normalized by the measurement. However, in MX 1.0.1 this normalization is now done in the analog input driver, whereas in previous versions this was handled by special case code in the individual MX datafile and plot drivers. However, this means that if the flag bit MXF_AIN_PERFORM_TIME_NORMALIZATION is set, you must specify the name of the timer used in the new 'timer_record_name' field. If you do not specify a timer, no time normalization will be done and the value reported will be in raw units even if the normalization bit is set. Previous versions of the 'mcs_scaler' driver did not correctly handle global dark current correction. The effect was that global dark currents did not work for most of the ways in which the 'mcs_scaler' driver could be used. This has now been fixed by changing the model that the 'mcs_scaler' driver uses for handling global dark currents. The 'mcs_scaler' driver now treats the MCS record it depends on as being its "server". Thus, the 'mcs_scaler' now implements global dark currents by setting the 0x2 bit (MXF_SCL_SERVER_SUBTRACTS_DARK_CURRENT) in the 'scaler_flags' field. The dark currents are now stored in data structures internal to the MCS. 'mcs_scaler' global dark currents have now been tested with the 'network_mcs', 'epics_mcs', and 'sis3801' MCS drivers for both step scans and quick scans. As part of the bug fix for the 'mcs_scaler' driver above, a new function mx_timer_get_last_measurement_time() has been added. Previous versions of MX just directly examined the internal pointer timer->last_measurement_time. However, the 'mcs_timer' driver is a case where the timer value you really want is to be found in the MX_MCS structure rather than the MX_MCS_TIMER structure. Thus, there was a need for a wrapper function. In support of this, a new function pointer 'get_last_measurement_time' has been added to the MX_TIMER_FUNCTION_LIST structure used by all MX timer drivers. The MX drivers for the X-ray Instrumentation Associates PFCU filter controller have now been successfully tested at APS Sector 17-BM (IMCA-CAT). The MX drivers for the Oxford Danfysik QBPM beam position monitor readout electronics have now been successfully tested with a real unit at APS Sector 17-BM. Some minor driver changes were made. The most important of these was the addition of a new 'AVERAGE' value type for 'qbpm_aout' records. The 'AVERAGE' value type is a front end to the existing 'AVGCURR', 'WDWCURR', and 'SINGLE' value types which uses the sign of the supplied number to determine which of these commands is used. Setting 'AVERAGE' to 1 to 100 is equivalent to setting 'AVGCURR' to 1 to 100, while values of -1 to -100 are equivalent to setting 'WDWCURR' to 1 to 100, and a value of 0 is equivalent to using the 'SINGLE' command. Note that the 'default_averaging' field of the 'qbpm' driver uses the same convention for these values and is used to initialize the averaging at MX server startup time. The 'mxupdate' server was internally generating an incorrectly formatted MX server database entry which prevented it from successfully connecting to MX servers. This has now been fixed. MX RS-232 drivers now have a new flag bit defined for 'rs232_flags' called MXF_232_SUPPRESS_TIMEOUT_ERROR_MESSAGES. This flag is intended to be used by MX drivers that talk to RS-232 devices that frequently time out so that the timeout can be transparently handled without generating an error message to be sent to the user. The mx_socket_receive() function now has a new extra argument for returning the number of bytes actually received. This value should only be different from the number of bytes requested if line terminators were specified in the call to mx_socket_receive(). A new mx_network_connection_is_up() function has been added for determining whether an MX network server connection is active. The initial motivation for adding this is so that mx_set_client_info() does not attempt to write to a server connection that is not currently active. The entry points for the 'mdrive_din' and 'mdrive_dout' drivers were accidentally left out of the driver list in 'libMx/mx_drivers.c' used by MX 1.0.0. This omission has now been rectified. Version 1.0.0 (04/26/04): The primary goal of this release was to improve the speed at which MX operates. For version 1.0.0, MX communication with EPICS has become up to 40 times faster than before. In addition, a shift to binary data formats for MX network communication has sped up common multichannel analyzers scans by a factor of 2. Since MX has been stable for quite some time now, it was decided that this was a good occasion to go ahead and declare this release as version 1.0. These improvements are described in further detail below. In order to improve performance, one must be able to measure it. Thus, one of the first things done for this release was to implement a high resolution timing package capable of measuring time intervals with submicrosecond resolution or better. Most modern CPUs include high resolution timers such as the Pentium Time Stamp Counter or the PowerPC timebase registers, so it was just a matter of encapsulating them in a platform independent way. The new MX high resolution timing package prototyped in 'libMx/mx_hrt.h' and 'libMx/mx_hrt_debug.h' reports the current time and measures time intervals with nanosecond resolution. The high resolution time package is best supported for x86 Linux (Pentium or above), Microsoft Windows (Win32), MacOS X, Sun Solaris, or SGI Irix. In addition, if you are willing to accept a 10 second startup delay for timer calibration, the package will also run on any PowerPC or Pentium and above operating system for which the binary was compiled with GCC. Other platforms will be added as needed. The first important thing to be benchmarked with the new high resolution timing code was MX communication with EPICS. This benchmarking showed that for older versions of MX the bottleneck occurred in the EZCA package. On an SGI Irix system, it was found that ezcaGet() from an EPICS scaler record was taking an incredible 60 milliseconds to execute and that many EPICS operations were taking 60 milliseconds or more to execute. After some investigation, I found out that by default EZCA has a _built-in_ delay time for reasons I am not entirely clear on and that it was possible to reduce this delay time. However, this discovery caused me to reexamine the value of using EZCA at all, since a closer examination of the EZCA source code showed that it was doing a bunch of things internally that I really did not need. MX originally started using EZCA back in the mid-1990s at a time when I did not yet understand EPICS all that well. However, now that I understand EPICS much better than I did then, it seemed that the best course of action was to abandon EZCA and write my own small wrappers for raw Channel Access that did only what MX needed and nothing more. This change paid off big by reducing the 60 millisecond interval describe above down to around 1.5 milliseconds (a factor of 40!) when used with an m68k based VME system controller. Ironically, these measurements were done during an upgrade of APS sector 17-BM's VME system controller from an m68k based controller to a PowerPC based controller. It turned out that changing to the PowerPC based controller reduced the benchmarked time further down to 0.5 milliseconds (only a factor of 3). So taking EZCA out of the mix did a lot more to improve the speed of the system than switching from m68k to PowerPC did! Another important change is the use of binary data transfer formats for MX network communication. Up until recently, the body of MX network messages has been transmitted as ASCII text. However, now MX clients and servers have the ability to send and receive the body of MX messages either in raw native binary format or in XDR binary format. The data format used is now automatically negotiated at the time that an MX client connects to an MX server. One of the first things an MX client now does is ask for the native integer and floating point data formats of the remote MX server. If the server and client have the same native data formats, then the client asks the server to transmit and receive MX messages using that native data format. Thus, an x86 Linux client talking to an x86 Linux server would then use little-endian integer and IEEE floating point binary data to communicate. If the client and server have different native data formats, then the client asks the server to use XDR binary data format. Thus, a MacOS X machine talking to an x86 Linux server would use XDR. If the MX server refuses to handle binary data formats ( an old MX server would do this ), then the client reverts back to using the old ASCII data format. This switch to binary data formats has already made a significant difference to measurements that read large quantities of data. For example, typical MCA scans at MR-CAT now run twice as fast as they used to. As it happens, most plaforms supported by MX already come with support for XDR. However, Microsoft Windows does not, so it was necessary to add support for it. I did not want to port the entire RPC/XDR package to Microsoft Windows since I am not using most of it. Instead, what I have done is write a small set of routines found in the 'tools/xdr' directory that only implements the subset of XDR routines used by MX. The header file "mx_alloc.h" has been renamed to "mx_array.h". It has been expanded to contain definitions for new functions that copy MX arrays to and from network transfer buffers using either XDR or native binary format as well as the array allocation functions that were already there. These new functions are used to help implement the new network binary data transfer formats. Since MX now no longer uses EZCA, MX must now directly take responsibility for caching the EPICS channel and group ids that EZCA used to cache for us. Two new data structures have been defined to handle this as follows: typedef struct { char pvname[ MXU_EPICS_PVNAME_LENGTH + 1 ]; void *channel_id; /* In EPICS this is a 'chid'. */ } MX_EPICS_PV; typedef struct { unsigned int group_id; /* In EPICS this is a 'CA_SYNC_GID'. */ } MX_EPICS_GROUP; The idea here is that the MX_EPICS_PV data structure for each process variable will be initialized with the character string name of the process variable by the routine mx_epics_pvname_init() during the startup of each record. mx_epics_pvname_init() does not make the initial connection to the EPICS IOC but instead just saves the name of the process variable. Instead, the connection is made the first time the process variable is accessed by functions such as mx_caget(), mx_caput(), etc. These functions also transparently handle disconnection and reconnection of process variables due to rebooting of IOCs, network cables falling out, and so forth. The revised MX API for accessing EPICS can be found in 'libMx/mx_epics.h'. Almost all MX application and driver code that uses EPICS has been revised to use these functions, although the old routines like mx_caget_by_name() that specify the PV by name are still available if desired. However, it is not recommended that the old 'by_name' routines be used for any EPICS variable that is likely to be used more than once in an MX program for efficiency reasons. The MX 'epics_motor' record now supports simultaneous start and extended status reporting. However, there have been some problems seen with the reported sense of limit switches, that is, positive limit trips being reported as negative limit trips and vice versa, when used with recent versions of the EPICS motor record which need to be investigated further. Apparently, versions that use the old HLS and LLS PVs work, but versions that use the newer MSTA PV do not. I expect that this will be fixed for MX version 1.0.1 which will probably come out a month or so after the release of 1.0.0. Four new drivers have been written to read and write arbitrary EPICS process variables via MX analog and digital I/O records. These drivers include the 'epics_ainput' and 'epics_aoutput' drivers for reading and writing floating point process variables. The 'epics_dinput' and 'epics_doutput' drivers are used for integer EPICS process variables. MX has now added a new 'sample_changer' device class that is used to control robotic sample changers. The initial implementation is for the new sample changer at APS sector 22 (SER-CAT) which uses a design originally created for the protein crystallography beamlines at the Advanced Light Source. Although the primary usage will be for protein crystallography, I have attempted to write the class in such a way that it would be usable for other types of sample changers such as an array of samples on an X-Y stage. The initial methods for the 'sample_changer' class are 'initialize', 'shutdown', 'select_sample_holder', 'unselect_sample_holder', 'grab_sample', 'ungrab_sample', 'mount_sample', 'unmount_sample', 'soft_abort', 'immediate_abort', 'idle', 'reset', 'cooldown', and 'deice'. At SER-CAT, the sample holders are pucks with positions to store up to 16 crystal samples which are normally stored in a liquid nitrogen dewar when they are not mounted for an experiment. The normal pattern of use for mounting a crystal sample is select_sample_holder - This identifies which puck in the dewar that you want to use. grab_sample - After cooling down the sample gripper, the robot picks up a sample from the puck. mount_sample - The robot takes the sample it has picked up and mounts it on the goniometer head. The normal pattern of use for unmounting a crystal is unmount_sample - After cooling down the sample gripper, the robots removes the sample from the goniometer head. ungrab_sample - The robot put the sample onto the puck in the dewar and then releases the sample. idle - The robot moves to a safe idle position. For testing purposes, a new 'sample_changer' command has been added to 'motor' to help exercise the new sample changer support. The command is also available via the alias 'changer'. The software development for the SER-CAT sample changing robot, has required the writing of several new MX drivers in addition to the new mx_sample_changer_...() functions for the class as a whole. The new MX drivers are sercat_als_robot - Sample changer driver for SER-CAT's implementation of the ALS sample changing robot. network_sample_changer - This driver allows an MX client program to use an MX sample changer controlled by a remote MX server. soft_sample_changer - An emulated sample changer for use in software testing. als_dewar_positioner - This is a pseudomotor driver that moves the X and rotation stages of the ALS style dewar to the correct position so that the sample changing robot gripper is directly above the sample. In addition, a number of drivers for Animatics and Wago equipment were written to support the new SER-CAT sample changer as described below. MX has added support for Animatics SmartMotor servo motor controllers. SmartMotors are 1-axis controllers that package the controller together with the motor as one unit in a manner similar to the IMS MDrive stepper controller. The MX 'smartmotor' driver controls the motion of the motor itself. MX also has 'smartmotor_ain', 'smartmotor_aout', 'smartmotor_din', and 'smartmotor_dout' drivers for the analog and digital I/O points that come with the motor. One word of warning: SmartMotors use an unusual combination motor power and control signal connector of a type I had never seen before. So, if you buy SmartMotors, you need to be sure that you get the correct cable for connecting to them. MX now has support for using the MODBUS fieldbus protocol. So far this support has only been tested using the MODBUS TCP protocol over Ethernet. A driver has been written for using MODBUS RTU protocol over serial ports, but it has not yet been tested. The available MX drivers include modbus_tcp - An ethernet based driver that has been tested with the Wago 750-841 and Wago 750-842 fieldbus controllers. modbus_serial_rtu - A serial port based driver that has not been tested yet. I expect to test it with Omega iSeries controllers in the near future. modbus_ainput, modbus_aoutput, modbus_dinput, modbus_doutput - Drivers for performing analog and digital I/O with MODBUS registers and coils. The Wago series of MODBUS controllers have the additional feature that one can read the current state of an output by reading from a MODBUS address that is 0x200 higher than the address of the output. MX supports using this additional feature via the 'wago750_modbus_aoutput' and 'wago750_modbus_doutput' drivers. MX has also added support for RS-232 communication over MODBUS via the Wago 750-65x series of serial ports using the new 'wago750_serial' MX driver. This support has been tested using the 750-650 RS-232 interface module, but is expected to work as well with the current loop and RS-485 variants of the module. You should be aware that RS-232 communication via this method is significantly slower than using a Linux serial port. You should really only use Wago serial ports if you have a need for accessing a serial port at a remote location and some constraint prevents you from putting a PC there. If you examine the MX source code, you will see that it currently has some code for implementing communication with USB devices. Please be aware that this code is a work in progress and is not yet sufficiently complete to talk with real USB devices. The MX drivers for the X-Ray Instrumentation Associates DXP-2X and Saturn multichannel analyzers have been modified to make use of new support in the XIA default firmware for region of interest (SCA) integrals computed in the XIA controller. So far this support has been successfully tested with the Saturn parallel port-based MCA but not yet with the CAMAC-based DXP-2X. This new feature has been implemented in the Handel-based MX driver, but not the older Xerxes-based drivers since XIA has only documented how to use the hardware computed integrals from Handel. Eventually, I expect that the old Xerxes-based MX drivers will go away since the Handel interface is what XIA wants to support, but, at present, the DXP-2X can only be used via the MX Xerxes drivers, so we cannot get rid of them yet. By contrast, I plan to get rid of the even older MDS-based (Mesa Data Server) drivers in the next release, since I do not think that anyone has used them in a long time and since they are much slower than the Handel and Xerxes drivers anyway. On a related note, the MX 'xia_dxp_mca' driver has added two new extra parameters to the end of each 'xia_dxp_mca' record in your MX databases. These parameters are 'preset_clock_tick' and 'runtime_clock_tick' which are specified in seconds. Normally, both of these will be set to 800e-9 for a Saturn MCA and 400e-9 for a DXP-2X, but there do exist firmware versions for which these are not the correct values. Also, the reason for having both preset and runtime clock tick fields is that there was at least one version of XIA firmware in which the two values were accidentally not the same. In any case, you should make test measurements with your system to verify that the clock tick values you have entered in your MX database are correct. The MX drivers for the Oxford Danfysik IC PLUS intensity monitor have now been extended to also support the Oxford Danfysik QBPM beam position monitor electronics. The new modifications support reading multiple intensity values and reading out computed X and Y positions directly from the QBPM. The following new driver types parallel the original 'icplus' drivers, although the 'qbpm_mcai' driver is new: qbpm - Amplifier driver to control gain and offset. qbpm_ain - Analog input driver used to read 1 of the 4 input current values (CURR1, etc.) or the computed X or Y position (POSX or POSY) of the beam. qbpm_aout - Analog output driver that can be used to control the averaging of signals by the QBPM (AVGCURR, WDWCURR, and SINGLE) and also to set the parameters such as 'GX', 'A1', etc. that control the calculation of X-Y positions. qbpm_din - Digital input driver used to read user inputs of a QBPM interface. qbpm_dout - Digital output driver used to control user outputs of a QBPM interface. qbpm_mcai - Multichannel analog input driver used to read the four QPBM current values in one operation. Although the 'icplus' drivers have been tested with actual IC PLUS controllers, the 'qbpm' drivers have not yet been tested with an actual QBPM controller. It is expected that this will be done in May 2004 and that any necessary changes will be incorporated into MX 1.0.1. MX now has a new driver class for multichannel analog inputs called 'mc_analog_input' which is used by the 'qbpm_mcai' driver mentioned above. This driver class is meant for devices that report simultaneous values from multiple inputs in one operation. At present, the only operation supported for this class is reading all the inputs, although more operations may be added in the future. A new analog input driver called 'mcai_function' has been added as a complement to the new multichannel analog input support described above. This driver computes a linear function of the values reported by a multichannel analog input driver and is most likely to be used to compute sums and differences of those values. As it happens, for the QBPM controller, the 'qbpm_ain' driver already supports reading out the POSX and POSY values. However, the QBPM does not support computing the sum of all four inputs for use as an intensity monitor, so the 'mcai_function' driver will be useful for doing that. MX has added drivers for the X-Ray Instrumentation Associates PFCU RS-232 interface to their PF4 and PF2S2 filter and shutter controllers. The new drivers include pfcu - A driver for the controller as a whole pfcu_filter - This relay driver controls an individual filter. pfcu_shutter - This relay driver for the PF2S2 uses a pair of filter positions to implement a shutter. pfcu_shutter_timer - This timer driver controls the exposure duration of a PF2S2 shutter to perform timed exposures. These drivers have not yet been tested, but I expect to test them during May 2004, so they should be ready in time for MX version 1.0.1. MX now has drivers for communicating with the iSeries temperature and process controllers made by Newport Electronics and commonly distributed by Omega. The drivers include the 'iseries' driver for managing the controller as a whole and the 'iseries_ainput', 'iseries_aoutput', 'iseries_dinput', and 'iseries_doutput' drivers for performing analog and digital I/O with iSeries controllers. The drivers do contain code for communicating with iSeries controllers via MODBUS RTU serial protocol, but they have only been tested so far using the native iSeries protocol over an Ethernet connection. MX has added a new set of drivers for performing digital I/O using a PC style parallel printer port using the Linux 'parport' module. The new drivers include the 'linux_parport', 'linux_parport_in', and 'linux_parport_out' drivers. These drivers differ from the older series of MX 'lpt' drivers in that the 'linux_parport' drivers make use of the parport kernel modules that are bundled with the Linux kernel, while the 'lpt' module usually requires the installation of extra kernel drivers that do not normally come with the operating system. However, the 'lpt' drivers have the virtue that they can be used on non-Linux operating systems as well. The MCA processing code in the MX server now supports calculating region of interest integrals for soft regions of interest. A soft region of interest is an ROI that is implemented entirely in the the MX device driver rather than in the actual MCA hardware. This allows you to effectively have as many regions of interest as you want, but in general is slower than using ROIs implemented in the MCA controller itself. 'mxserver' has added a new 'report' field for each record. Sending a shell command like 'mxput omega.report' will cause the MX server to write to its log file the same text that would normally be displayed in 'motor' by a 'show record', 'show motor', etc. command. The 'monochromator' pseudomotor now uses the MX scan 'fast mode' flag to determine when to reread the dependency enable variables. The assumption is that users will not normally change the state of the dependency enable variables like 'id_ev_enabled' during the course of a scan, so the time for a scan can be shortened by only examining the enable variables at the start of the scan. Previous versions of MX multichannel scaler drivers had an internal offset variable 'mcs->first_scaler_number' which was used to distinguish between MCSes where the first channel was channel 0 and those where the first channel was channel 1. The idea was to match the labeling on the front panel of the MCS. However, it turns out that this 'feature' has caused more confusion than illumination since, for example, the fourteenth channel in an MCS might under some circumstances be referred to with a channel index of 14 and under other circumstances as channel 13. In the interest of clearing up confusion, MX 1.0.0 now specifys that the first channel of an MX MCS record is channel 0 regardless of what the front panel may say. The 'remote_marccd' and 'network_ccd' MX drivers have now been successfully used to readout, correct, and write MarCCD frames while running the MarCCD vendor's GUI in remote control mode. This required a variety of changes to the prototype 'remote_marccd' driver to get it to work since initially it was not obvious from the vendor's documentation that MarCCD remote mode is fully asynchronous with messages from MarCCD completely decoupled from commands sent to MarCCD. In addition, MX has now added a new CCD support function called mx_ccd_start_for_preset_time(). This was added when it became clear that remote operation of MarCCD required that the client to MarCCD handle the calculation of when the exposure was to end. The 'motor' program has now added a new command called 'ccd'. This gives the user a way to control the reading, correcting, and writing of CCD image frames from the 'motor' command line. The 'pm304' driver for the old Mclennan PM304 motor controllers used at APS sectors 10 and 17 has been upgraded to use the newer MX motor 'get_status' driver function. This allows the driver to report a wider variety of error conditions such as following errors and axis disabled than the older version of the driver which could only detect hitting a limit. The 'aps_adcmod2' MX driver for the electrometer system designed by Steve Ross of the Advanced Photon Source has been modified to add three extra fields to its MX database record. The three extra fields are averaged_value_update_frequency - raw_value_read_frequency - num_raw_measurements_to_average - These fields were added to make it easier to tweak the way in which incoming signals were average. In addition, the 'aps_adcmod2_amplifier' driver used to control the gain and time constant was changed to insert 1 millisecond delays between each command sent to the ADCMOD2 interface during the 'open' routine for the driver. This improves the reliability of the initialization of this interface. Other parts of the MX drivers for the ADCMOD2 already had such delays in them, so leaving them out of the amplifier open routine was just an oversight. MX has also added support for the 'aps_quadem_amplifier' driver for communicating with the APS ADCMOD2 electrometer via EPICS and the EPICS QuadEM database. The idea here is that for a VME crate controlled by EPICS, you will use the 'aps_quadem_amplifier' MX driver, while if you are not using EPICS, you can use the 'aps_adcmod2' series of MX drivers. MX now has support for reading the tilt angle values reported by a Crossbow Technology CXTILT02 digital inclinometer. The MX support makes use of two new drivers namely cxtilt02 - This driver controls the inclinometer as a whole. cxtilt02_angle - This driver reports one of the angles. Mx has added support for the IOtech Micro488EX RS-232 to GPIB interface via the new 'micro488ex' driver. MX has also added the VME bus interface drivers 'rtems_vme', 'vxworks_vme', and 'mmap_vme' for accessing VME bus addresses via RTEMS, VxWorks, and operating systems supporting mmap() respectively. There is also now a 'vxworks_rs232' driver for accessing RS-232 ports from VxWorks. MX has now added support for accessing an MX server via Unix domain sockets. On the server side, this may be done by adding a command line argument to 'mxserver' that looks like " -p /opt/mx/run/socket ". If desired, a given MX server can simultaneously offer services via both a TCP socket and a Unix domain socket. See the examples 'testserv/msoftunix' and 'testserv/msoftboth' in the MX source code distribution for examples of this. On the client side, using a Unix domain socket means replacing a line that looks like serv1 server network tcpip_server "" "" 0x0 192.168.137.3 9727 with a line that looks like serv1 server network unix_server "" "" 0x0 /opt/mx/run/socket The original purpose in adding Unix domain socket support was in the hope that Unix domain sockets would be faster than TCP/IP localhost sockets. On Linux at least, it appears that the two types of sockets are of comparable speeds. Similar performance measurements have not yet been made on other MX supported platforms. Even if it is not faster, Unix domain socket support may still be interesting since on some platforms such as Linux, it is possible to reliably determine the UID (user id) of the remote MX client process which will be useful for purposes of access control. In the source code, MX_SOCKET has been changed to be a data structure of the form typedef struct { MX_SOCKET_FD socket_fd; unsigned long socket_flags; } MX_SOCKET; while the old meaning as an alias for the file descriptor is now provided by the MX_SOCKET_FD define. This was done to make it easier to support transparent reconnection of sockets. In future versions, I expect to add pointers for data transfer buffers to this structure as well. The various mx_..._socket_open_as_...() routines now have an additional argument called 'socket_flags' which is stored in the structure above. At present, there are two defined flag bits in the socket_flags argument, namely, MXF_SOCKET_DISABLE_NAGLE_ALGORITHM and MXF_SOCKET_QUIET. The Nagle algorithm is a fundamental feature of TCP/IP where small packets are consolidated into bigger packets to try to improve the efficiency of transmission. However, there are occasions where the Nagle algorithm is inappropriate. The circumstance that prompted its inclusion in MX was the discovery that Wago I/O controllers using MODBUS TCP did not function correctly if the Nagle algorithm was turned on. The MXF_SOCKET_QUIET flag was added to suppress socket disconnection and reconnection messages in cases where automatic socket reconnection was desired. The mx_socket_send(), mx_socket_receive(), mx_socket_getline(), and mx_socket_putline() routines have now been modified to allow the line terminators for a message to be specified at run time rather than the previous behavior of assuming what the line terminators were. The routines now also handle a wider variety of ways in which a socket connection can disconnect. The socket library has added new functions called mx_socket_num_input_bytes_available() and mx_socket_discard_unread_input(). On platforms that support the FIONREAD ioctl(), mx_socket_num_input_bytes_available() can report the actual number of bytes that can be read without blocking. On other platforms, mx_socket_num_input_bytes_available() is implemented with select() which does not provide a count of the number of bytes available to be read. For MX platforms that implement this functionality using select(), mx_socket_num_input_bytes_available() never reports a value larger than one. At present, the primary user of this routine is the new routine called mx_socket_discard_unread_input() which throws away any unread bytes from a socket. MX RS-232 database records now have two extra fields, namely timeout - number of seconds to wait for an action to complete. rs232_flags - currently only used to request unbuffered I/O. If the timeout field is set to a negative value, then the timeout is ignored. The two fields are inserted in an MX RS-232 database entry just after the line terminator definitions. Thus, a database entry that used to look like pmac1_rs232 interface rs232 tty "" "" 38400 8 N 1 N 0xd 0xd /dev/ttyS0 will now look like pmac1_rs232 interface rs232 tty "" "" 38400 8 N 1 N 0xd 0xd -1 0x0 /dev/ttyS0 if you want to preserve the same behavior as before. mx_rs232_getline() has been modified to do a better job of handling timeouts for those cases where the underlying device driver does not itself implement a getline() function. Also, the new function mx_rs232_getchar_with_timeout() has been added to support cases where you want to explicitly specify the timeout interval. In addition, the functions mx_rs232_getline(), mx_rs232_putline(), mx_rs232_read(), and mx_rs232_write() have now been modified to do single character I/O if the MXF_232_UNBUFFERED_IO bit is set in the 'rs232->rs232_flags' variable for the interface. The old MX_RS232_SIGNAL_STATE structure has been replaced by an unsigned long 'signal_state' variable in the MX_RS232 structure that uses individual bits in the variable to encode the state of the individual I/O pins of an RS-232 interface such as RTS, DTR, etc. The signal state is available from an MX server via the 'signal_state' record field. This change was made since an unsigned long variable is simpler and easier to use than the old structure was. The Unix 'tty' RS-232 driver for MX has been modified to implement 'putline' using the writev() function on those platforms that implement writev(). This should improve the efficiency with which characters are transmitted to RS-232 devices on those platforms. The 'rs232' command in 'motor' now has new options, namely, 'get signal_state' and 'set signal_state' which allow the user to read and specify the logic state of individual RS-232 pins. The multiword VME data transfer functions such as mx_vme_multi_in8(), mx_vme_multi_out8(), etc. have been modified to allow the VME address increment to be specified as a parameter to the function. Each read or write will increment the VME address pointer by the specified amount. The 'sis3100' MX VME interface driver has been enhanced to support multiword VME data transfers for all possible combinations of address type and data size. The controller natively only supports fast D32 transfers for A24 and A32 addresses. For other data sizes and address types, the MX driver now uses for() loops to transfer the data one element at a time. This is, of course, slower for those cases, but at least it will work. Nevertheless, it is best with the SIS3100 to use D32 for multielement data transfers and to try and avoid using D16 or D8. The mx_wait_for_motor_stop() and mx_wait_for_motor_array_stop() functions have been modified to report details such as following errors or drive fault of any fault that may have stopped the motor motion. The 'grelay_flags' field of the MX 'generic_relay' record has been modified to add a new flag value of 0x10 (MXF_GRELAY_IGNORE_STATUS) which when set in the database entry causes the 'generic_relay' to report the relay status as matching the last command sent, regardless of the actual position of the relay. There is also another flag value 0x1000 (MXF_GRELAY_SUPPRESS_ILLEGAL_STATUS_MESSAGE) which does check the actual position, but which suppresses the generation of an error message to the user if the position is invalid. If you have a relay that has no way of detecting its current open or closed position, you are probably better off using the 'blind_relay' record. The 'pmac_tc_motor' and 'pmac_bio_motor' MX drivers used to control PMACs via Tom Coleman's EPICS drivers has been modified to make configurable in the database the number of times the MX driver waits for the in position signal to remain the same. In principle, this should always be 1, but in actual experience this is not always sufficient. The 'pmac_cs_axis' driver for PMAC coordinate system axes has been internally slightly restructured to make use of the new functions mxd_pmac_cs_axis_get_variable() and mxd_pmac_cs_axis_set_variable(). This was done to make sure that the driver was always using the correct coordinate system. Revised the drivers for the Prarie Digital Model 45 data acquisition module. At this point, the analog and digital I/O drivers, the timer driver, and the pulse generator driver work. The scaler driver does not yet work correctly. A new utility function mx_process_id() reports the process ID of the current process as an unsigned long. Currently, this is primarily used by MX clients to tell remote MX servers what their process ID is for reporting purposes. Another new utility function is mx_start_debugger(). This function is designed to provide a platform independent way of starting a debugger like the Microsoft Visual Studio debugger or GDB. At present, most of the testing of this feature has been done on Win32 with the Visual Studio debugger. The 'motor' and 'mxserver' programs have been modified to take a new command line parameter '-D'. If '-D' is specified for one of these programs, then mx_start_debugger() will be invoked just after the point where command line parameters are parsed. It is now possible to specify for 'mxserver' whether the SIGINT signal (usually from ctrl-C) will cause the server to terminate or cause the server to display a stack traceback. If '-s' is specified on the 'mxserver' command line, a stack traceback will be generated. If '-S' is specified, the server will terminate. On Win32, the default is for the server to terminate, while on other platforms the default is for the server to display a stack traceback. The double duty nature of this arrangement is due to the fact that there are only a limited number of signals on all platforms that can be used in this way. The 'libMx/os_rtems_config.h' and 'libMx/os_rtems_startup.h' header files and the 'motor/mrtems.c' and 'server/ms_rtems.c' files have been modified to make it more straightforward to specify boot parameters for the RTEMS image file. The boot parameters can either be hard coded in the header or you can request that RTEMS use BOOTP to boot. See the header files for more information. The 'home' command in 'motor' now uses mx_motor_get_extended_status() which is more efficient and provides more information than the old calls to mx_motor_get_position() and mx_motor_is_busy(). Version 0.66.1 (08/24/03): Fixed a bug in 'mxupdate' that was preventing it from running. The MX architecture 'freebsd' has been renamed to 'bsd' to reflect the fact that it builds equally well on FreeBSD, NetBSD, and OpenBSD. Version 0.66.0 (08/15/03): New MX driver classes: ccd - This driver class supports remote control of CCD systems used for macromolecular crystallography. The initial release includes the drivers 'remote_marccd' and 'network_ccd'. New MX drivers: itc503_motor, itc503_status, itc503_control - These drivers are for reading out and controlling the Oxford Instruments ITC503 temperature controllers. The motor driver allows the temperature setpoint to be step-scanned in a normal MX scan. mdrive, mdrive_din, mdrive_dout, mdrive_ain - The drivers for the IMS MDrive series of motor controllers have now been successfully tested and used on a real beamline. network_ccd - This driver allows an MX client to send commands to a CCD system via a remote MX server. It it is intended for use in conjunction with a hardware interface driver like the 'remote_marccd' driver described below. pmac_cs_axis - This driver allows a PMAC coordinate system axis to be controlled as if it were a real motor. This driver expects that the coordinate system include a motion program for moving the axis that parametrizes destinations, speeds, and accelerations in terms of PMAC variables. In addition, a PLC program must exist that computes and writes the current position of the axis to a PMAC variable. position_select - This driver is intended to be used together with a new 'option selector' dependency type (type 9) for the MX monochromator record. This driver and the dependency type are used for things like automatically changing the undulator harmonic or the metal stripe on an X-ray mirror when the monochromator energy crosses specified thresholds. Thus, if one needed to switch from the Xx stripe to the Yy stripe on a mirror at ZZZZ eV, the option selector dependency would tell the position_select driver to horizontally move the mirror to the correct position for the new stripe when the monochromator energy was moved past the specified energy. Each mirror or undulator harmonic position has an associated energy range. If the energy ranges for different mirror positions overlap, the overlap region serves as a deadband for the mirror position change to prevent the mirror from being shifted back and forth repeatedly. remote_marccd - This driver uses the MarCCD remote mode described in the 'remote_mode.txt' file that comes with the MarCCD documentation. The remote mode allows an MX client to tell MarCCD to take frames, correct the frames, write frames to a file, set header variables and so forth. MX clients will use the new 'network_ccd' driver to send commands to the 'remote_marccd' driver running in an MX server that has been started by MarCCD. scaler_function_mcs - This is a pseudo-MCS driver that lets one use a specified 'scaler_function' pseudo-scaler in a quick scan. This driver assumes that the real scalers used by the 'scaler_function' pseudo-scaler are all MCS scalers. For a quick scan, the 'scaler_function_mcs' record computes the 'scaler_function' value for each point in the scan and saves them in its internal MCS data array. The record can then be read out by MX scanning software in the same manner as for a real MCS scaler. So far, this driver has been used to read out the sum of the signals from the pads of a 4-pad beam position monitor such that the sum can be used as an intensity monitor. xia_handel - This is an MX interface driver for XIA DXP-2X and Saturn multichannel analyzers that makes use of XIA's new Handel software interface library. For now, the old 'xia_xerxes' MX driver is still available and still works, but XIA is encouraging people to migrate to the new Handel library. In an MX database file, the only lines that would need to be changed to use this driver are lines that specified the 'xia_xerxes' driver. The database lines that mention the 'xia_dxp_mca', 'xia_dxp_input', and 'xia_dxp_sum' drivers will not need to be changed. The previous versions of the MX 'wavelength' and 'wavenumber' drivers have been replaced by new drivers derived from the existing MX 'energy' driver. Everything that used to work with the old versions should still work. However, the new versions of the 'wavelength' and 'wavenumber' drivers are now capable of being used by MX quick scans. MX motor drivers have been enhanced to support reading and modifying the following types of servo loop parameters: proportional_gain integral_gain derivative_gain velocity_feedforward_gain acceleration_feedforward_gain integral_limit extra_gain - ( a catchall for controller type specific gains ) The motor drivers have also added a facility for sending certain other useful commands in a controller independent way: axis_enable closed_loop - (reenable the servo loop if it has tripped off) fault_reset The new servo loop gain and control commands have not yet been implemented in all MX motor drivers. The drivers for which they _have_ been implemented include: compumotor epics_motor esp_motor mclennan mm4000_motor network_motor pmac_motor A new status bit (MXSF_MTR_OPEN_LOOP) has been added to the MX motor status word. When loading a scan database, MX now discards scan records that are incorrectly formatted without aborting the load. You _will_ get several warning and error messages about 'broken scans', but now the load will successfully complete. The MX database description for MCS records has now added an extra field called 'timer_record_name'. This field is intended to contain the timer record used to control the MCS. In some cases, one can put a blank string here, in which case the parts of the software that need an MCS timer name will attempt to find the MCS timer at run time. However, it is safer to just specify the name here. The presence of a timer name was not made mandatory since some uses of the MCS do not need the timer record at all. The new MCS field follows the existing 'external_prescale' field. For example, an old record that looks like sis3801 device mcs sis3801 "" "" 32 2000 0 0 vme1 a16 0 0x3800 0x6 0x0 should be changed to look like sis3801 device mcs sis3801 "" "" 32 2000 0 0 timer1 vme1 a16 0 0x3800 0x6 0x0 The MX 'delta_motor' driver has been enhanced to make it quick scan capable. Since 'e_minus_e0' is normally implemented as a 'delta_motor', this has the effect of making it possible to create XAFS quick scans whose energy range is specified relative to the current value of the MX 'edge_energy' variable. Thus, one XAFS quick scan record can be used, as is, for multiple absorption edges. Full use of this facility depends also on changes to datafile and plot support that are described below. Datafile and plot support in MX scans has been enhanced to allow the selection of optional features. The initial set of optional features include: Datafiles: x=motor1[,motor2[,motor3...]] Specifies one or more alternate X axis motors that will be written to the datafile and displayed in the scan progress _instead_ of the actual scan motors. Thus, you can do a quick scan of 'e_minus_e0' and have 'energy' be written to the datafile X axis instead. If more than one X axis is specified, they will all be written to the datafile as extra columns at the beginning. normalize_data Specifies that the data from scalers and some analog inputs should be written to the data file as counts per second rather than raw counts. xafs This is equivalent to specifying the options "x=energy" and "normalize_data". Plots: x=motor1[,motor2[,motor3...]] Same as the datafile support above. continuous_plot For a multiregion scan, such as an XAFS scan, this tells the plot driver to show all the regions in one plot, rather than a separate plot for each region. normalize_data Same as the datafile support above. xafs This is equivalent to specifying the options "x=energy", "continuous_plot", and "normalize_data". Datafile and plot option keywords can be abbreviated to whatever length still makes them unique. Thus, you could say 'n' rather than 'normalize_data'. However, I would recommend that you specify at least 'normalize' and 'continuous' for compatibility with future options. Datafile and plot options are specified in MX scan databases by appending them to the datafile and plot type separated from the type by a colon ':' character. Individual options are separated from each other by semicolon ';' characters. You should avoid putting spaces in the option strings. The original record fields 'datafile_type' and 'plot_type' have been renamed to 'datafile_description' and 'plot_description' to reflect there new, more general functionality. As an example, you can use plot options with the 'gnuplot' plot type to get a result equivalent to 'gnuxafs' by specifying a plot description of gnuplot:x=energy;continuous;normalize For a datafile, you can specify multiple axes to be written to the datafile. For example, sff:x=energy,theta Will cause the SFF datafile to write 'energy' in the first column and 'theta' in the second column with the input device values in the following columns. In an SFF format file, at least, you can record the identity of the alternate X motors through a new SFF file header token '%x_motors' which if specified in the MX 'sff_header_fmt' database variable will arrange for the list of alternate X motors to be written to the header. The alternate X axis support was initially designed to be embedded in the 'optimize.dat' scan database used by the MX 'optimize' and 'optimize_auto' GUIs. Thus, not a lot of work has been done yet for directly exposing the datafile and plot option functionality in user level programs. At the moment, the only program that makes options directly settable is the command line 'motor' program which has added two extra prompt to 'setup scan' and 'modify scan', namely: Enter datafile options -> Enter plot options -> If you just hit Enter (CR), no options will be set and the behavior of the scans will be the same as in previous MX releases. For scans that have datafile or plot options set, the prompts will look something like Enter datafile options -> (CR = 'x=energy,theta') Enter plot options -> (CR = 'x=energy;continuous') If you want to delete all such options for a scan in 'motor', the simplest way to do it is to type a space ' ' character followed by Enter (CR) at each of the prompts above. Due to the way that scan records are processed in MX, this will have the effect of specifying no options in the scan record. Please note that the new option processing is not supported for the datafile type 'xafs' and the plot type 'gnuxafs'. The assumption here is that these are specialized types anyway, so there is no reason to allow customization of them. You _can_ specify options with the 'xafs' datafile type and the 'gnuxafs' plot type, but they will be ignored. New support has been added for measuring and computing microsecond level time intervals for benchmarking and profiling on Linux and Win32. This support provides the functions mx_high_resolution_time() - Reports the current time with nanosecond resolution. mx_add_high_resolution_times() mx_subtract_high_resolution_times() mx_convert_high_resolution_time_to_microseconds() The high resolution time support is an extension to the preexisting mx_udelay() support for microsecond delays and currently only works as intended on Win32 and for x86 Linux running on CPUs that have the RDTSC instruction (first introduced in the Pentium CPU). The prototypes for these functions can now be found in libMx/mx_hrt.h. The next major release of MX will focus on performance improvements to the infrastructure of MX. In preparation for this work, I have ported the existing Linux code to two alternate compilers, namely the Intel C++ 7.1 compiler and the Borland Kylix 3 C++ compilers, so that I can see which compiler generates the fastest version of MX. There is also the beginnings of a port to the Win32 Borland C++ compiler, but this compilation target is not yet in a working state. VMS is now supported for OpenVMS 7.3.1 with both 'mxserver' and 'motor' having been successfully tested there. The makefiles expect that MX will be built there with Gnu Make, not MMS, and require the use of a special MX toplevel makefile found in the scripts subdirectory. There is preliminary support for a 'vms_terminal' RS-232 driver, but it cannot be said to be really working since the emulated serial ports in the TS10 VAX emulator I used do not work very well. The 'sis3100' and 'epics_vme' VME bus interface drivers have added support for optionally ignoring VME bus errors if the flag MXF_VME_IGNORE_BUS_ERRORS (0x1) is set in the new 'vme_flags' field. The MX 'mardtb' driver for the Mar Desktop Beamline goniostat was sometimes miscounting the number of characters it had received from the mardtb controller. This has now been fixed. The drivers for the Velmex VP9000 motor controller have now been revised based on suggestions by Terry Griffin of Axian, Inc. The 'vp9000_motor' driver now has an extra field called 'vp9000_flags'. If the flag MXF_VP9000_DISABLE_ENCODER_CHECK (0x1) is set, the 'vp9000_motor' driver does not attempt to verify that the encoder position matches the motor position. Set the flag to 0x0 if you do want the driver to cross check the encoder and motor positions. Also, the 'vp9000' driver now tells the controller to go back to Jog/Slew mode before closing down the connection to the controller during a shutdown. Finally, the 'vp9000' driver uses a command (G) to switch to On-Line mode that is not supported by versions of the Velmex firmware older than 2.8. Unfortunately, MX has no direct way of detecting the VP9000 firmware version in use, so if use of the 'G' command fails, the driver now generates an error message suggesting that the MX user verify that the VP9000 firmware is new enough to be used with the driver. Modified the 'scipe_motor' driver to use the 'motor->status' variable for the 'get_status' driver function. It was previously setting 'motor->busy', 'motor->positive_limit', and 'motor->negative_limit' directly, but those values are automatically overwritten by values generated from 'motor->status' after return from a 'get_status' motor driver function. A bug in the 'network_motor' driver's handling of quick scans has been found and fixed. During the computation of pseudomotor positions from quick scan encoder values, the 'network_motor' driver is supposed to automatically figure out whether or not it needs to make calls to the MX server to complete the computation. If a motor controlled by a remote MX server is _not_ a pseudomotor record, the client's 'network_motor' driver is supposed to know that it does not need to send a 'compute_pseudomotor_position_from_real_position' request to the MX server for each measurement. However, in MX 0.65.0, this test was incorrectly programmed and the MX client was sending unnecessary requests to the MX server. This has now been fixed in MX 0.66.0. The routine mx_autoscale_create_monitor_offset_array() no longer attempts to malloc() zero bytes if autoscale->num_monitor_offsets is zero. While malloc(0) may be valid for some systems, the Electric Fence memory allocation debugger flags it as an error, so it is simpler just to avoid doing malloc(0). Version 0.65.0 (04/02/03): MX clients now attempt to automatically reconnect to MX servers after a connection has been lost. This should eliminate the need to restart MX clients when an MX server is restarted. In addition, 'motor' can also do a 'resync' command on a server record to manually force server reconnection. A new flag 'tcpip_server_flags' has been added to the end of MX server record descriptions to allow automatic reconnection to be turned off if necessary for some reason. This means that MX server records should now look in the database like id2 server network tcpip_server "" "" localhost 9727 0x0 where the 0x0 is the new field. Replace the 0x0 with 0x1 to disable automatic reconnection. MX now supports quick scanning any of the 31 motors controlled by a given Turbo PMAC motor controller while requiring the use of only two counter channels in an multichannel scaler to read the encoder output. The way this works is that one of the 32 axes of the Turbo PMAC is dedicated to the task of generating the MX multichannel encoder signal by configuring it to generate step-and-direction outputs which are then converted to up pulses and down pulses which are recorded by the quick scan's multichannel scaler. The PMAC MCE motor axis is then slaved to the PMAC axis which is driving the real motor. Since it is possible to reprogram a slave axis to be connected to different master axes at run time, then any of the other 31 motor axes controlled by that PMAC controller may be quick scanned by reprogramming the master-slave relationship just before the quick scan starts. The new 'pmac_mce' record, together with the 'pmac_motor' and 'mcs_qscan' records arrange for all of this to happen automatically behind the scenes without the user needing to know anything about it. New MX driver classes: sca - This new driver class supports programmable single channel analyzers such as the Cyberstar X1000 mentioned below. New MX drivers: aps_adcmod2, aps_adcmod2_amplifier, aps_adcmod2_ainput - These are drivers for the ADCMOD2 electrometer system designed by Steve Ross of the Advanced Photon Source. cyberstar_x1000, cyberstar_x1000_aout - Single channel analyzer and analog output drivers for the Oxford Danfysik Cyberstar X1000 scintillation detector and pulse processing system. icplus, icplus_current, icplus_voltage, icplus_din, icplus_dout - Drivers for the Oxford Danfysik IC PLUS ion chamber system. network_sca - Driver for a single channel analyzer controlled by a remote MX server. pmac_double, pmac_long, pmac_ulong - MX variable records that allow direct control of individual PMAC variables in a Delta Tau PMAC motor controller. pmac_mce - This is the multichannel encoder (MCE) driver for use in quick scanning PMAC controlled motors that was described earlier in this changelog entry. soft_sca - Driver for a software emulated single channel analyzer. udt_tramp - Driver for the UDT Instruments TRAMP current amplifier. This amplifier is controlled via an MX digital output record. Unfinished MX drivers: mdrive, mdrive_din, mdrive_dout, mdrive_ain - A preliminary set of MX drivers have been written for the IMS MDrive motor controllers, but they have not been tested yet. si9650_motor, si9650_status - Drivers for the Scientific Instruments 9650 temperature controller. Not yet tested. MX has added support for QNX and FreeBSD. Partial support has also been added for RTEMS, but this work is not yet finished. The makefile variables ARCH and INSTALL_DIR have been renamed to MX_ARCH and MX_INSTALL_DIR. MX programs now internally store the version number of MX that they were compiled with in the mx_version element of the MX_LIST_HEAD structure. For MX servers, this information is available remotely via the record field 'mx_database.mx_version'. For MX version X.Y.Z, the mx_version value is computed by the equation mx_version = 1000000*X + 1000*Y + Z So, for a hypothetical MX version 1.14.9, the value of mx_version would be 1014009. For the current version of MX (0.65.0), the value is 65000. MX servers that do not have a record field called 'mx_database.mx_version' are assumed by MX clients to be older than MX version 0.65.0. The MX server processes 'mxserver' and 'mxupdate' now put a time stamp at the beginning of each message that they write to their log files /opt/mx/log/mxserver.log and /opt/mx/log/mxupdate.log. MX servers now have the beginnings of an internal status reporting facility. This facility is accessed by writing a string to the record field 'mx_database.status'. At present, if the string 'clients' is written to that record field, the MX server will display in its server log a list of the currently connected clients. Here is an example of what this looks like: Apr 01 18:28:25 Client 6 (socket 14) connected from host '127.0.0.1'. Apr 01 18:28:25 Num sync cbk type host user program Apr 01 18:28:25 --------------------------------------------------------------- Apr 01 18:28:25 0 8 -1 MX server mx mxserver Apr 01 18:28:25 1 9 -1 MX client 164.54.208.10 staff align_crystalApr 01 18:28:25 2 10 -1 MX client 164.54.208.10 staff motor Apr 01 18:28:25 3 11 -1 MX client 127.0.0.1 mx mxupdate Apr 01 18:28:25 4 12 -1 MX client 164.54.208.10 staff sergui Apr 01 18:28:25 5 13 -1 MX client 164.54.208.10 staff optimize Apr 01 18:28:25 6 14 -1 MX client 127.0.0.1 Apr 01 18:28:25 Client 6 (socket 14) disconnected. Future versions of this facility will provide ways of displaying more detailed information about individual clients. Sending SIGINT to 'mxserver' now causes it to print a stack traceback to the MX server log file. If stack tracebacks are not available on a specific MX platform, a message to that effect will be printed. The operation the server was performing may or may not be resumed after the traceback is printed. This depends on whether or not the underlying operating system automatically restarts system calls after a signal handler returns. This feature was added to help in figuring out why a non-responsive MX server is hung and should not be used routinely. MX client-side support for EPICS has been reorganized to funnel all EPICS interactions through a small set of front end wrappers, such as mx_caput_by_name() and mx_caget_by_name(). At present, MX does most of its EPICS-related I/O via the Ezca library. However, I currently plan to replace the Ezca-based interfaces with ones that directly calls the underlying Channel Access library. Hiding the EPICS I/O behind a small number of wrappers will make it easier to change the underlying infrastructure all at once. The mx_caget_by_name(), etc. wrapper functions also have the virtue that they return standard mx_status_type structures and therefore fit better into the MX error handling system. Some bugs in the parsing of Delta Tau PMAC error messages have been fixed. Thus, the 'pmac' interface should now correctly report the nature of the error. The 'epics_vme' record now makes use of EPICS synchronous groups to reduce the number of individual Channel Access messages that need to be sent. Multichannel encoder (MCE) support has been significantly revised for this release. The primary change has been to the interpretation of the 'scale' and 'offset' record fields in MCE records. Originally, the scale and offset were used to convert raw encoder values into user units. However, there is a problem if an MCE like the new 'pmac_mce' intends to make use of encoder values with more than one motor axis, since different motor axes may need different scale factors. Thus, the interpretation of the MCE scale factor has been changed so that now it is used to convert the MCE encoder values to _raw_ motor units rather than _user_ motor units. Then, the resulting value is multiplied by the motor scale factor of the motor used by the current quick scan. Speed and acceleration parameters have been reorganized for MX motor records to make clearer the distinction between user units and raw controller units. Previously, MX quick scan support did not work correctly if motor scale factors were set to values other than 1 at certain places. As far as I know, all of places in the code affected by this issue have now been found and corrected. Motor record fields affected by this change include: motor.acceleration_distance ==> split into 'motor.acceleration_distance' and 'motor.raw_acceleration_distance'. motor.acceleration_parameters ==> renamed to 'motor.raw_acceleration_parameters' motor.compute_extended_scan_range ==> split into 'motor.compute_extended_scan' and 'motor.raw_compute_extended_scan_range'. motor.speed_choice_parameters ==> split into 'motor.speed_choice_parameters' and 'motor.raw_speed_choice_parameters'. In addition, new functions were added: mx_motor_get_raw_speed() mx_motor_set_raw_speed() At the same time, a few other motor parameters and functions were also renamed. These include: deadband ==> raw_move_deadband mx_motor_raw_move_absolute() ==> mx_motor_internal_move_absolute() mx_motor_array_move_segment_with_report() ==> mx_motor_array_internal_move_with_report() Several MX network protocol functions have been renamed. These include: mx_get() ==> mx_get_by_name() mx_put() ==> mx_put_by_name() mx_get_array() ==> mx_get_array_by_name() mx_put_array() ==> mx_put_array_by_name() These changes were made to make room for new handle-based MX network functions that are to be added soon. MX and most related packages now support a new 'make distclean' makefile target. This target is intended to be used before packaging up the source into a distribution tar file. It does everything that 'make clean' does and also truncates the various Makefile.depend files to zero length. Implemented generic handlers for mx_rs232_read() and mx_rs232_write() which are used if the individual RS-232 driver does not have a handler for this. Version 0.62.0 (12/05/02): The MX 'xia_xerxes' MCA drivers have now been tested with X-Ray Instrumentation Associates' parallel port based Saturn multichannel analyzer (formerly known as the X10P). The tests were actually performed with an unmodified copy of MX 0.60.0, so that version works as well. Be sure to download the newest version of the XIA Handel/Xerxes drivers from www.xia.com before attempting to use the MX drivers. A new MX build platform 'irix-gcc' has been added. The addition of 'irix-gcc' was motivated by the fact that I was unsuccessful at building a working version of Tcl/Tk 8.3 or 8.4 with the vendor provided C compiler on the SGI Irix machines I have access to. However, versions of Tcl/Tk 8.4 compiled with GCC under Irix seem to work fine. Thus, I have decided, for now, that the simplest solution is to build MX and its extensions for Irix with GCC. However, if someone can show me how to get a working version of Tcl/Tk 8.4 with the SGI provided C compiler, I would be interested in knowing how they did that. An additional field called 'slit_flags' has been added to the database entry for 'slit_motor' pseudomotors. This new field is located right after the units field, and requires changing records that look like bv_center device motor slit_motor "" "" 0 0 -200000 200000 0 -1 -1 1 0 um 1 b_bottom b_top to look like bv_center device motor slit_motor "" "" 0 0 -200000 200000 0 -1 -1 1 0 um 0x0 1 b_bottom b_top Note the addition of the 0x0 value after the units 'um'. This new field was added to allow slit pseudomotors to be configured to do a simultaneous start. Set the field to 0x1 rather than 0x0 if you want the slit motors to start simultaneously. Thus, at present, the 'linear_function', 'translation_mtr', and 'slit_motor' drivers are the three general purpose pseudomotors that support simultaneous start. The 'compumotor_lin' and the 'compumotor_trans' drivers also currently support simultaneous start, but they are now considered obsolete, so you should start using the 'linear_function' and 'translation_mtr' drivers instead. Bear in mind that simultaneous start is only supported if all the real motors are controlled by the same MX driver and the same physical controller. In addition, the underlying MX driver for the real motors itself must support simultaneous start. At present, the only drivers that do are the 'compumotor', 'pmac_motor' and 'soft_motor' drivers. Support will be added for other drivers as time permits. New MX drivers: adsc_two_theta - This controls the two theta angle of the goniostat provided with the ADSC Quantum 210 detector by changing the detector height. Due to the design of the detector support, the detector angle has a relatively non-obvious dependence on the detector height, so a special driver was written specifically for this geometry. This driver has been used to give a MarCCD detector and control system the ability to control the ADSC goniostat via an MX-specific equivalent to the Mar provided 'goniostat' interface program. cryostream600_motor - This driver provides a way to control the cryostream temperature of an Oxford Cryosystems 600 series Cryostream controller as if it were a motor. It works together with a modified version of the 'cryostream600_status' driver introduced in 0.60.0. mclennan, mclennan_din, mclennan_dout, mclennan_ain, mclennan_aout - These drivers provide support for the McLennan PM600 and PM304 motor controllers and are intended to eventually replace the existing MX 'pm304' driver. The 'mclennan' driver is used to control the motor axis itself, while the 'mclennan_din' and 'mclennan_dout' drivers control the digital I/O ports that come with the controllers. The 'mclennan_ain' and 'mclennan_aout' drivers control the analog I/O ports that are only available on the PM600. At present, these drivers have only been tested with the PM600, although I expect to be able to test it with the PM304 during the January shutdown of the Advanced Photon Source. The drivers theoretically also support the PM301, PM341, and PM381 motor controllers, but this has not been tested since I do not have access to any of those controllers. network_relay - This driver allows an MX client to operate a relay record controlled by a remote MX server. pseudomotor_scan - This new scan type is intended to replace the existing 'slit_scan' scan type. Pseudomotor scans are designed to perform step scanning of pseudomotors that move more than one real motor in such a way that the relative position of the real motors remains constant throughout the scan. The 'pseudomotor_scan' driver use of the new MX library functions mx_motor_save_start_positions() and mx_motor_use_start_positions(). The idea here is that the pseudomotor scan record at the beginning of each step scan will tell the pseudomotor records to save the starting positions of each of the real motors. Then, before each step of the scan, the mx_motor_use_start_positions() function will be invoked to tell the pseudomotor to use the saved start positions in calculating the new destination for the pseudomotor rather than the current positions of the real motors. These new functions are currently implemented for the 'network_motor', 'slit_motor' and 'translation_mtr' drivers and more will be added as necessary. scipe_ain, scipe_aout - The 'scipe_aout' driver controls a SCIPE actuator as if it were an analog output register while the 'scipe_ain' driver controls a SCIPE detector as if it were an analog input register. sis3100 - This is an MX VME interface driver for the SIS1100/3100 PCI-to-VME bus interface from Struck. uglide, uglide_motor - These drivers control the BCW u-GLIDE micropositioning stage from Oceaneering Space Systems. The 'uglide_motor' driver is used to operate one of the two axes of the motor controller, while the 'uglide' driver is used to manage the controller as a whole. vsc16, vsc16_scaler, vsc16_timer - These drivers are used to control a Joerger VSC16 or VSC8 counter/timer module via an MX VME interface record. Modified MX drivers: compumotor - Support has been added to this driver for the simultaneous_start and get_status driver functions. compumotor_int - Added support for 'command', 'response', and 'command_with_response' fields to the MX driver. These are used by an MX server to allow remote clients to safely send direct commands to the underlying Compumotor controllers without disrupting the handshaking between the MX Compumotor interface driver and the Compumotor controller itself. This feature is used by the MX MarCCD goniostat interface program so that it can command an ADSC supplied goniostat to perform the motor and shutter commands required for taking a CCD image frame. cryostream600_status - This driver has been modified to request Cryostream 600 status information via the new 'cryostream600_motor' driver mentioned above. monochromator - This pseudomotor driver has been modified to use the new get_status driver function instead of the old motor_is_busy, positive_limit_hit, and negative_limit_hit functions which were removed from the driver. network_motor - Support has been added for the new get_status and get_extended_status driver functions. pmac - Added support for 'command', 'response', and 'command_with_response' fields to the MX driver. These are used by an MX server to allow remote clients to safely send direct commands to the underlying PMAC controllers without disrupting the handshaking between the MX PMAC interface driver and the PMAC controller itself. This feature is used by the MX MarCCD goniostat interface program so that it can command the SER-CAT goniostat to perform the motor and shutter commands required for taking a CCD image frame. pmac_motor - This driver has been modified to use the new get_status driver function rather than the old motor_is_busy, positive_limit_hit, and negative_limit_hit functions which were removed from the driver. In addition, the set_position function has been modified to do the computation of the internal PMAC position value in the PMAC itself rather than in the MX driver. The PMAC internally uses integers larger than the largest 32 bit integer, so this procedure avoids the potential of integer overflow in the MX driver. scipe_amplifier, scipe_din - DND-CAT has made some modifications to these MX drivers to make them fit better into their existing control systems and fix some bugs. sis3807, sis3807_pulser - These drivers have been changed to make use of modifications we requested to the Struck firmware to add a countdown (burst) register and a pulse width register. Unfortunately, the pulse width register is only 16 bits in size due to limitations in the FPGAs used, which limits its ability to be used as a standalone gate generator. slit_motor, translation_mtr - These drivers have been modified to use the new get_status driver function rather than the old motor_is_busy, positive_limit_hit, and negative_limit_hit functions which have been removed from the drivrs. In addition, support has been added for the new MXLV_MTR_SAVE_START_POSITIONS and MXLV_MTR_USE_START_POSITIONS parameters to the set_parameter functions in support of the new 'pseudomotor_scan' driver. In addition, 'slit_motor' record descriptions have a new 'slit_flags' field as described above. sr570 - A minor bug fix was made to this driver to fix a case in the set_offset function where a current and a voltage were erroneously being compared with each other. vme58, vme58_esrf - The old 'vme58' driver has now been revised to support communication with the OMS VME58 motor controller either via an MX VME interface record or via the Linux device driver written at ESRF. The driver code chooses which interface method to use based on the driver name you specify in the MX database. xia_xerxes - This driver can now be configured at run time to either use a specified 'xiasystems.cfg' file or else automatically generate one from the MX database configuration. Error reporting for MX network devices has been enhanced so that the names of the remote server and record field are reported in the MX error message when possible. The generation of datafile names for MCA files created during a step scan that saves an MCA spectrum at each point has been fixed so that it correctly constructs the new filenames. MX now uses the value hc = 12398.4186 eV-angstroms rather than the old value of 12398.5. This is compatible with both the values from the NIST website and with the values printed in the 2002 Physics Today Buyer's Guide. A new function mx_rs232_verify_configuration() has been added to allow drivers that use RS-232 ports to verify that the RS-232 port configuration is set up the way that the MX driver needs it. New functions called mx_process_exists() and mx_kill_process() have been added. These were added to make it possible for Imcagui to check for the completion of the external Chooch program without spawning a program to do the check. Currently these functions only are implemented for Unix-like platforms. A variety of minor bug fixes and enhancements were made to the new motor 'get_status' functionality. The 'motor' program now uses mx_motor_get_extended_status() to get the position and motion status rather than the previous method which required four function calls. This will help reduce the network traffic required for MX network motors. A new command 'set bypass_limit_switch' has been added to 'motor' to help with getting a motor off of a limit switch. When the command 'set bypass_limit_switch on' has been executed, then for the next move, 'motor' will not automatically abort moves when a limit switch contact has been detected. The 'bypass_limit_switch' feature is automatically reset to 'off' at the end of the move. 'mxupdate' now automatically exits if the file 'etc/mxupdate.dat' is empty, since for this case there is no productive work it can do. Version 0.60.0 (08/13/02): The 'xia_xerxes' based drivers for the X-Ray Instrumentation Associates DXP-2X multichannel analyzer system have now been tested with input count rates of around 1.5e6 counts per second per channel. A new 'pulse_generator' device class has been added to MX. This class supports programmable pulse periods, pulse widths, pulse delays, and pulse counts. However, the device drivers for this class that have been written so far only implement programmable periods and counts. New MX drivers: mardtb, mardtb_motor, mardtb_status - These are MX drivers for controlling the Mar Research Desktop Beamline goniostat controller. The 'mardtb_motor' drivers allows MX to control the various motors attached to the Desktop Beamline goniometer system. The 'mardtb_status' driver can be used to read out the Mar provided ion chambers. The 'mardtb_status' driver is configured as an analog input driver rather than as a scaler since we have no way of controlling the measurement time. sr570 - This driver controls the Stanford Research Systems SR570 current preamplifier. sis3807, sis3807_pulser - These drivers are used to control the Struck SIS3807 pulse generator. sis3801_pulser - This driver uses the Struck SIS3801 MCS as a pulse generator rather than as a multichannel scaler using the procedure documented in the SIS3801 manual. network_pulser - This driver communicates with a pulse generator controlled by a remote MX server. mcs_time_mce - This multichannel encoder driver allows MCS quick scans to use elapsed time pseudomotors as the scan motor. This is a way of allowing the X axis for quick scan to be elapsed time rather than a motor position. cryostream600_status - This driver reports the cryostream temperature for a Oxford Cryosystems 600 series Cryostream controller. lpt, lpt_in, lpt_out - These drivers use PC-style parallel ports as digital I/O devices. At present, only SPP mode is supported. portio_dinput, portio_doutput - These drivers treat a specified PC I/O port address as a digital I/O port. soft_ainput, soft_aoutput - These drivers are software emulations of analog input and output ports. The value reported by the soft_ainput port is set by the value of a corresponding soft_aoutput port. scipe_din, scipe_dout - These drivers treat SCIPE actuators as if they were digital I/O ports. scipe_amplifier - This driver treats a collection of SCIPE actuators as if they were a current amplifier. The driver assumes that the device controlled by the SCIPE server is actually a Stanford Research Systems SR570 amplifier. epics_vme - This is an MX VME driver that uses Mark Rivers' EPICS VME driver to read from and write to memory addresses in an EPICS controlled VME crate. Please note that since every VME I/O operation is sent across the network, this method of controlling a VME device is very slow. However, for devices with low I/O requirements like pulse generators, the available speed is entirely adequate to the job. linux_iopl, linux_ioperm - These are alternates to my 'linux_portio' driver that use the iopl() and ioperm() functions to gain access to the I/O ports. Please note that while the drivers _should_ be completely functional, they have not yet been tested. External channel advance support has been added to the MCS device class together with support for an external prescale factor. External channel advance allows MCS data acquisition to be controlled via an external pulse generator. This makes it possible to have a master clock for a beamline such that all data acquisition devices acquire data at exactly the same time. A measurement type of 'preset_pulse_period' has been added to support MCS quick scans that use a pulse generator as their external channel advance signal. MCS quick scans now support using scaler channels from multiple MCSs. This is only available if the scan uses an external pulse generator for its master clock. MCS quick scans now attempt to only read out scaler channels from the MCS that are used by the scan. In many circumstances, this will significantly speed up the data readout portion of the scan. Unfortunately, not all MCSs are capable of supporting this, so for some MCSs all the scaler channels will be read out anyway. New measurement functions mx_get_measurement_time() and mx_get_measurement_counts() have been added for use by MX scans. New 'get_status' and 'get_extended_status' functions have been added to motor drivers. This reflects the fact that most motor controllers have a single motor status reporting command rather than separate command for 'busy', 'limit_hit', etc. This change allows motor drivers to ask _once_ for the information and then update all of the flags in the MX motor driver in one operation. Depending on the driver, this may result in a significant improvement in the speed of the driver. The new motor 'status' variable also provides a place to store additional information like following error, drive fault, and axis enable status that was not being saved by the motor drivers up to now. The difference between 'get_status' and 'get_extended_status' is that 'get_extended_status' also reports back the motor position. 'get_status' and 'get_extended_status' are intended to ultimately replace the 'motor_is_busy', 'positive_limit_hit', and 'negative_limit_hit' functions in motor drivers. However, most of the motor drivers have not yet been modified to take advantage of them. Thus, the generic code in 'mx_motor.c' currently has a fallback strategy. If the new status functions are called, but the new status driver functions have not been implemented for a given driver, the generic code synthesizes a status word by invoking the traditional busy and limit hit functions. Support for global scaler dark current values has been added. In previous versions of MX, each instance of an MX client program had its own independent notion of what the scaler dark current was. Thus, measuring the dark current in one client did not automatically update the dark current in the other clients. In MX 0.60.0, it is now possible to configure scalers to use global dark current values maintained in an MX or EPICS server. This feature is configured using the new 'scaler_flags' field in MX scaler records which replaces the old 'subtract_dark_current' field. The allowed values of 'scaler_flags' are: 0x0 - No dark current subtraction. 0x1 - Subtract the dark current using a local value maintained in the client program. 0x2 - Subtract the dark current using a global value maintained in a remote MX or EPICS server. The values for 'scaler_flags' are designed to be compatible with the values for the old 'subtract_dark_current' field, so you do not need to change that field in your database if you do not intend to use global dark currents. Global dark current subtraction is currently supported for 'network_scaler', 'epics_scaler', and 'mcs_scaler' records. Other items related to global dark currents: Adding support for global dark currents has made it necessary to modify the format of scaler records in 'mxserver.dat' and 'motor.dat' files. This change inserts the name of the timer that gates this scaler right after the 'scaler_flags' field. This modification gives the scaler records a way to find out what the last measurement time was by directly querying the timer record. For example, the old record scaler2 device scaler epics_scaler "" "" 0 0 1 s17bm:scaler1 2 would be modified to read scaler2 device scaler epics_scaler "" "" 0 0 0x1 timer1 s17bm:scaler1 2 If you use global dark currents with MX server managed scalers, then you must set the 'scaler_flags' in 'mxserver.dat' for that scaler to 0x1, while 'scaler_flags' in the corresponding 'motor.dat' records must be set to 0x2. If you use global dark currents with EPICS managed scalers, then you must add some records to the EPICS database to contain these values. For Joerger scalers, read the file 'mx/driver_info/epics_scaler/README' for a description of what is necessary. For Struck multichannel scalers, the necessary description is in 'mx/driver_info/epics_mcs/README'. You must still set 'scaler_flags' to 0x2 in the corresponding 'motor.dat' records. mx_scaler_read() now automatically performs a dark current subtraction before returning a value. Correspondingly, a new mx_scaler_read_raw() function has been added to allow an application to read the scaler value without dark current subtraction. For many device classes, it is no longer necessary to include empty stub routines for functionality that is not available for a particular driver. Now, if a given driver function is defined as a NULL pointer in the relevant MX_..._FUNCTION_LIST, then the generic part of the driver code will take an appropriate default action. For example, if the set_position function for a given motor driver is defined as NULL, the generic code will assume that redefining this motor's position is not possible and will return an error message to that effect. So far, this type of change has been made for the motor, scaler, amplifier, mce, and mcs device classes. The rest of the classes will be converted in a future release. A similar change has been made to how the MX_RECORD_FUNCTION_LIST driver functions are handled. In this version of MX, the only driver function in MX_RECORD_FUNCTION_LIST that absolutely _must_ be defined is the create_record_structures function. This is because create_record_structures is the function responsible for allocating memory for driver specific data structures. One of the reasons for introducing default driver actions is to shorten the length of individual device drivers so that they can be made simpler to understand and also take up less memory. Correspondingly, stub driver routines have now been removed from a number of device drivers. However, there are many drivers for which this has not been done yet. Default get and set parameter functions have been added for the 'mcs', 'pulse_generator', and 'scaler' device classes. This is in addition to the already existing ones for the 'amplifier', 'autoscale', 'mca', and 'motor' device classes. Several modifications have been made to the 'sis3801' driver for Struck multichannel scalers. These are: 1. The 'sis3801' driver now supports external channel advance. 2. The driver now supports 28 bit prescale factors if the SIS3801 is running a version of its firmware that supports this. This allows the measurement time to be 16 times longer than the maximum supported by the standard firmware. 3. The control inputs are now programmable. This was needed to support external channel advance. 'motor' has been modified such that scans will be resaved to the scan database file if the scan has autoincremented its datafile number. This feature has not yet been added to 'mxgui' though. 'motor' now has new 'set pulser', 'show pulser', and 'start' commands that may be used to directly control pulse generators. Some test routines that generate digital output signals have been added to MX. The idea is to use digital output signals to generate timing pulses that can be observed on an oscilloscope. These functions currently include mx_test_output_on(), mx_test_output_off(), mx_test_pulse(), and mx_test_dip(). If a programmer places calls to these functions in their code, they can use an oscilloscope to measure how long it takes for the program to get from one point in the code to another point. The functions are defined in the header file 'mx/libMx/mx_test.h'. A new function mx_udelay() has been added that waits for the specified number of microseconds _without_ yielding control back to the operating system. This was done to support the test digital output functions mentioned in the previous paragraph. So far mx_udelay() is only implemented on x86 Linux and Win32. On other platforms it falls back to using mx_usleep(). Fixed a bug in several MCE (multichannel encoder) drivers. Previously, the drivers that interfaced with MCS drivers did not check for the possibility that the MCS record was configured for a larger number of measurements than the MCE record was. This meant that it was possible for the routine that computed encoder position to write beyond the end of the array in the MCE driver. The MCE drivers now return an error message if the MCS record is configured for a larger number of measurements than the MCE record. A new flag MXF_SOCKET_USE_LINE_TERMINATORS has been added to request mx_socket_send() and mx_socket_receive() to pay attention to line terminator characters. New RS-232 functions mx_rs232_get_signal_state(), mx_rs232_set_signal_state(), and mx_rs232_print_signal_state() have been added to permit the manipulation of individual RS-232 signal pins. At present, only the Unix 'tty' driver implements the corresponding new driver functions 'get_signal_state' and 'set_signal_state'. Modified the Pontech STP-100 driver to allow the motor speed and acceleration to be set at program startup time. The 'ortec974_timer' driver now sends a 'STOP' command and a 'CLEAR_COUNTERS' command before starting a new measurement. SCIPE servers expect that counter presets will be integers. Consequently, the MX 'scipe_timer' has been changed to round timer presets to the nearest integer before sending the value to a SCIPE server. Added a '%date' header token for the SFF datafile type. The 'is_at_home_switch' flag in motor drivers has been renamed to 'home_search_succeeded'. This more accurately reflects what the relevant driver routines were actually doing. All references to the OS_MPW port for the Macintosh Programmer's Workshop under MacOS 9.x and before have been removed. This port never got even close to a working state and has become irrelevant since we are now focusing our effort on the Unix-based MacOS X. SIGINT (ctrl-c) is no longer configured to automatically be ignored by mx_setup_database(). Applications that want to ignore SIGINT must do this on their own. Added new macros MX_AM9513_INSERT_DELAYS and MX_AM9513_DELAY_TIME to 'mx/libMx/i_am9513.h'. It seems that the explicit delays inserted into previous versions of the Am9513 drivers were not really necessary. Thus, if MX_AM9513_INSERT_DELAYS is set to FALSE, then no explicit delays will be inserted. Some functions in 'mx/libMx/mx_socket.c' that were specific to the MX network protocol have been moved to a separate file called 'mx/libMx/mx_net_socket.c'. The new file 'mx/README.install' contains some installation instructions. Added a new directory named 'mx/driver_info'. This directory contains information on how to set up certain MX drivers that have special requirements. Ultimately this information will go into the main MX documentation. Version 0.56.1 (04/04/02): Added a simultaneous_start entry point to the definition of the MX_MOTOR_FUNCTION_LIST structure. This is to allow several motors controlled by the same controller to be started at the same time. This feature can also be used by pseudomotors that are modified to take advantage of it and is intended as a more general replacement for things like the 'compumotor_lin' driver. At present, the only motor drivers that implement simultaneous_start entry points are the 'pmac' and the 'soft_motor' drivers. Other drivers such as the 'compumotor' driver will have this functionality added soon. The 'linear_function' and 'translation_mtr' drivers have been modified to optionally use the simultaneous_start function described above. Since this behavior is intended to be optional, it unfortunately means that the database entries for 'linear_function' and 'translation_mtr' records must be modified to include an additional flags field. This field is inserted in the database entry immediately after the 'units' field. Modified the 'pmac_motor' driver to support both set_position and simultaneous_start commands. Simultaneous start is implemented by specifying the move commands for all the motors on one command line. Redefining the motor positions is implemented by using the PMAC Mx64 variable as described in the document "PMAC position registers" on the Delta Tau CDROM. Added a pseudomotor driver 'aframe_det_motor' to control the motors of an A-frame style CCD detector support as used by SBC-CAT and SER-CAT at the Advanced Photon Source. This creates a coupled motion of the real motors to implement three pseudomotors: 1. detector angle 2. detector distance 3. detector offset A move of any of the three pseudomotors is programmed to keep the values of the other two constant. Please note that this driver only implements moving to the correct pseudomotor position at the end of the move. It does not attempt to try to maintain the pseudomotor geometry while the move is in process. Implemented a 'scaler_function' pseudoscaler. This allows the construction of pseudoscalers that are sums or differences of real scaler values. The driver is currently used with SER-CAT's four element beam position monitor detector system to permit the construction of pseudoscalers that record the total intensity from all four elements, the difference between the top and bottom element, and so forth. The 'aps_gap' motor driver for Advanced Photon Source insertion devices did not yet define a function to handle the 'save_speed' and 'restore_speed' operations. This was interfering with the use of the 'aps_gap' pseudomotor together with the 'monochromator' pseudomotor in situations where the monochromator record is located in a remote server. The 'aps_gap' driver has now been modified to ignore 'save_speed' and 'restore_speed' commands since APS beamlines do not have direct control over the insertion device speeds anyway. APS insertion device quick scans _do_ indirectly control that speed, but that feature is handled in the context of the 'aps_id_qscan' driver. Modified several scaler drivers that were not setting the value of the automatic_overflow_check flag so that they now set it to FALSE. Dead reckoning calculations (where used) for motor moves can now specify that the start time for the move is some time other than the current time. More work was done on the XIA MCA support. This is still a work in progress. The MX server has been modified to ignore keyboard interrupts, since it is not normally attached to a keyboard. This should always have been the case, but somehow it had been overlooked. The test scripts in the 'test' and 'testserv' directory have been modified to use the -F flag when invoking 'motor'. This means that they will no longer rewrite their motor database file upon exit. All uses of the mx_strncpy() macro were checked to see if they were using the macro correctly, that is, specifying the correct value for the length argument. Version 0.56.0 (03/04/02): Changes were made to support the new Python interface to MX called MP. MP exports an object oriented interface to the MX control system in a manner similar to the preexisting MxTcl package for [incr Tcl]. However, MP exports a much larger subset of the functionality of MX to Python than MxTcl currently does. Most of the C callable interface for MX devices and interfaces has been exported to Python as MP methods. MP does not currently depend on any particular Python GUI package such as Tkinter, so you should be able to create graphical user interfaces with any of the available GUI toolkits for Python. MP has been ported to the Cygwin, HP/UX, Irix, Linux, MacOS X, Solaris, and Win32 platforms. This release contains a variety of updates to the XIA DXP MCA support. The MX drivers have now been tested with new XIA DXP-2X firmware that has successfully been used to take MCA spectrum data at input count rates of up to around 250,000 count/sec/channel and a peaking time of 1 microsecond or greater. A new 'xia_network' driver was written to export across the network more of the internal functionality of the MX drivers than the 'network_mca' record does. Some performance improvements have been made to the MX drivers but there is more to be done. These drivers have not been tested yet with the DXP-X10P, but we hope to do that in March. Added a 'tangent_arm' and 'sine_arm' motor driver. This allows the control of angles via linear motors attached to long lever arms. Infrastructure was added for supporting quick scans with these motors, but this has not been tested yet. The 'delta_motor' and 'translation_mtr' drivers were revised to make them compatible with being used to implement the theta axis of a 'monochromator' pseudomotor. The 'mathop' driver has been revised to permit writing to 'mathop' variables. The database record structure has also been reorganized to make the record simpler to configure. The 'mathop' driver currently supports the computation of simple arithmetic, trigonometric, exponential, and logarithmic functions of database record values. Quick scans synchronized with an Advanced Photon Source undulator have now been successfully tested. Unfortunately, these scans have a minimum scanning speed that is set by the base speed of the stepping motors that move the APS undulators. Thus, APS undulator "quick scans" that want to scan the energy very slowly cannot be done since this would require the undulator stepping motors to move at below their base speed. However, undulator quick scans that scan the energy at higher speeds seem to work just fine. A procedure has been devised to allow the synchronization of an external program with an MX scan record such that the external program performs some action before each step in a step scan. This is currently used to move a sample from point to point on an X-Y grid grid such that each point in the step scan hits a different spot on the sample. This is done to cope with samples that degrade rapidly in the X-ray beam. The procedure works by configuring a 'simple' fault reset record and a 'simple' measurement permit record to be the same actual record. The external program then monitors the state of this record. Thus, before each step in a step scan, the fault reset serves as a signal to the external program to move the X-Y stage to the next position. The external program then signals that it is done by setting the measurement permit flag. Theoretically, this could be use to implement almost any kind of external action before each data point. Unfortunately, this procedure currently requires the user to manually start the external program. Some effort will be put into making this more automatic in a future release. Contact me if you want more information on how to do something like this. MX on the Cygwin platform now optionally supports building and using a DLL version of the libMx library in addition to the static version libMx.a. Building libMx.dll is currently optional because the build of the corresponding import library, libMx.dll.a, is extremely slow. On my machine it takes 10 minutes or so. However, linking to libMx.dll.a is very fast once it is built. The only way Cygwin currently provides for speeding up the build of the import library is by the use of a .def file that lists all of the entry points exported by libMx. However, I do not wish to do this since such a file would contain thousands of entries and would be hard to keep up to date. At present, I suggest that you build the static library if you are making changes to libMx or its drivers on Cygwin and only build the DLL when you are done. A new 'special_processing_setup' entry point has been added to the MX_RECORD_FUNCTION_LIST structure. This gives MX drivers a way to add custom network record fields that are specific to that driver. The first driver to use this is the 'xia_xerxes' driver which uses this to provide a network accessible way of changing the currently loaded XIA configuration via a command like mxput xiaserver:xia.config_filename c:\\progra~1\\xia\\mesa2x~1.0\\configs\\myconfig.sav The 'special_processing_setup' routine either augments or replaces the default server processing routines depending on whether or not the MXF_PROC_BYPASS_DEFAULT_PROCESSING bit is set in the "record_processing_flags' field of the MX_RECORD structure by the MX driver. A variety of changes were made in the MX server code to support special processing setup routines. MX database files now support an !include directive. This takes the form of a line in the database file that looks something like !include /opt/mx/etc/mbase.dat where the exclamation point (!) must be in column 1. This allows different MX databases to load commonly used records from the same file. This way, changes to the common files are automatically visible is all databases that include the file. Please note that the presence of !include directives is not preserved when files are written out, so !include directives are only really useful for MX database files that are read only. The 'motor' program has been modified to allow motor startup scripts to be bypassed via the new -i option. 'motor' has also been changed to allow the motor prompt string to be set via the new -p option. This makes it possible for different copies of motor that are using different databases to have different prompts. The 'mxserver' program can now be asked on its command line to redirect mxserver output to a file via the new -e and -E options. This is mostly of use for platforms like Win32 that do not provide easy ways to redirect stderr to a file. -e and -E differ in that -E write the output in unbuffered mode. -E has all the potential advantages and disadvantages of unbuffered I/O. The database record parsing routines check for string tokens that are too long to fit in the defined length of the string and now generate a warning message that they are truncating the string token. Modified the makefiles to eliminate the use of the various MX_LIBRARY_BUILD..., MX_MOTOR_INSTALL..., etc. variables. The new organization is more compatible with the way that makefiles are normally written. The Win32 makefile for the tools subdirectory has been modified so that it automatically figures out where Visual C++ is installed by reading libMx/Makehead.win32. It is no longer necessary to separately set the value of MSDEV in tools/Makefile.win32. The HAVE_GNUPLOT and HAVE_PERL entries in mxconfig.h have been removed since compiling them in does not require linking to external libraries that may not be present and it is just as easy to check for their presence at run time. Modified the user startup scripts to add ${MXDIR}/lib/mp to the PYTHONPATH environment variable. Added mx_mca_get_preset_type() and mx_mca_set_preset_type() to libMx so that they can be invoked from Python by the MP package. Added a so far untested driver 'epics_mca' for the EPICS MCA record. Version 0.55.0 (12/18/01): The 'xia_xerxes' interface driver has now been tested for multiple regions of interest using the X-Ray Instrumentation Associates' XerXes C interface library. The 'xia_xerxes' driver has proven to be much faster than the old 'xia_mds' driver which uses the LabVIEW-based XIA Mesa Data Server. So far, most of the testing has been done using the DXP-2X, although we plan to support the DXP-X10P as well within a month or so. There is still much more room for improvements in the speed of MX's side of the drivers. We are scheduled to do more testing with beam at the start of the next run in January. The MCA drivers have been modified to support the use of multiple regions of interest (ROIs) for MCAs that support them in hardware. This was needed for the XIA MCA drivers. The MCA drivers have also been modified to support software emulated regions of interest (soft_rois). These ROIs are completely independent of the hardware ROI support and implement computation of the ROI integral entirely in the MX driver. This allows multiple regions of interest to be used for MCAs that only implement one ROI in hardware such as Ortec Trump MCAs. Added support in 'motor' for using the soft ROIs via the new 'mca' command options 'get soft_roi', 'set soft_roi', and 'get soft_integral'. Added an 'mca_value' driver that allows uncorrected and corrected ROIs to be calculated for any MX supported MCA. Added a 'xia_dxp_input' driver that allows a variety of values to be reported for XIA DXP MCAs. This is similar to the 'mca_value' driver, but also can handle a variety of XIA specific information. Added support for an optional additional backlash correction that can be performed at the start of a quick scan. Joerger quick scans can now only be performed if they are enabled in the MX database. This is to prevent the use of the Joerger quick scan with versions of the EPICS scaler driver that do not support it well. Added a 'set autosave' command to 'motor' that can turn on or off the automatic saving of modified scans to 'scan.dat'. The Compumotor drivers have been modified to allow the use of arbitrary controller addresses. Up to now, the Compumotor drivers have required that a single controller have address 1 and a daisy chain of controllers have addresses from 1 to N (the number of controllers). However, this does require a small change in the format of 'compumotor_int' records in the database file. The change is the insertion of a new 'controller_number' field in between the 'num_controllers' field and the 'num_axes' field. For example, if Zeta 6104 controllers numbered 1, 2, 3, and 4 were daisy chained on the same serial port, the old record would have looked like ctl interface generic compumotor_int "" "" ctl_rs232 0x0 4 1 1 1 1 With this modification, the record now looks like ctl interface generic compumotor_int "" "" ctl_rs232 0x0 4 1 2 3 4 1 1 1 1 For an eight motor Compumotor 6K with address 1, the old record looked like 6k interface generic compumotor_int "" "" 6k_rs232 0x0 1 8 and the new record looks like 6k interface generic compumotor_int "" "" 6k_rs232 0x0 1 1 8 Fixed a bug in the Compumotor drivers for multidrop configuration such as a daisy chain of Zeta 6104 controllers. Apparently, multidrop configurations require turning on echoing of all commands sent via the ECHO1 command. If echoing is not turned on, commands sometimes make it to daisy chained controllers anyway, but the occurrence of this is somewhat unpredictable. Hopefully, this will eliminate problems we have had with the Zeta 6104s in the past. Added support for a 'mathop' record type. This supports performing various simple mathematical operations on the values of other MX records. The mathematical operations currently supported are addition, subtraction, multiplication, division, negation, square, square root, sine, cosine, tangent, arcsine, arccosine arctangent, exponential, logarithm and log10. The syntax for this record type is currently rather ugly and is not nearly as versatile as a record implemented using Tcl or Python scripts would be, but it is all we have time for at the moment. Added support for normalizing analog input values using the integration time. This allows analog input values whose values are a function of the integration time to be correctly written out to MRCAT XAFS format data files. Modified the MX analog I/O device classes so that they can support both analog I/O devices that report values as integers and analog I/O devices that report values as floating point numbers. This is analogous to the way that motor drivers distinguish between "stepper" motors and "analog" motors. The 'mxserver' and 'mxupdate' programs now report the version of MX they were compiled with at startup time. Added new '-s' and '-S' command line options to 'mxserver' that allow the automatic stack tracebacks that normally occur when an MX program crashes to be turned on or off. This was done so that the Microsoft Visual Studio debugger can gain control when an MX program crashes on Win32 platforms. Since automatic stack tracebacks are not yet supported on Win32, this was thought best. Reading or writing an MX network variable record now causes the either the mx_receive_variable() function or the mx_send_variable() function to be invoked depending on whether or not the operation is a read or a write. Added a function mx_open_temporary_file() that can be used to create temporary files in a more or less portable manner. Version 0.50.2 (10/30/01): Fixed a bug in the Compumotor digital I/O drivers that was found when the drivers were finally used. Modified the 'generic_relay' driver so that the 'input_record' field can actually refer to a digital output record. This allows the driver to handle cases where a digital output driver does know how to read the status of its output. Version 0.50.1 (10/25/01): MCS quick scanning using the EPICS MCS record has now been successfully tested at APS Sector 10 (MRCAT). This test had been held up for a long time since the old motor controller for the theta axis at Sector 10 did not put out a useable encoder signal that could be recorded by the SIS3801 MCS. The old controller has now been replaced by a controller that _does_ put out a useable encoder signal, so MCS quick scans of the monochromator are now possible. I anticipate that MCS quick scanning will be the normal mode of operation for monochromator scans at Sector 10 now. MCS quick scanning has also been successfully testing using the 'sis3801' MCS record (non-EPICS) in combination with the 'pmac_motor' driver. The PMAC motor positions are recorded by slaving another PMAC axis to the real motor axis with the slave axis commanded to put out step and direction signals. A small electronic circuit is then used to change the step and direction signals into up and down pulse trains. The up and down pulses are then fed into two channels of the MCS and the rest of the process is the same as with the EPICS MCS driver. 'mxserver' and the MX clients have been modified so that they do not abort and exit if one or more of the records mentioned in the database fail in mx_initialize_hardware(). This means that 'mxserver', 'motor', and others theoretically can now start up even if some of the hardware described in the database file is missing, turned off, or otherwise broken. Instead, a flag 'is_faulted' is set to TRUE in the offending record(s). Bear in mind that virtually none of the routines in MX currently check the new 'is_faulted' flag, so it is possible that an attempt to use a faulted record will cause 'mxserver' or an MX client to crash, but this is unlikely. In addition, this, as yet, does nothing about drivers that block if the hardware is not available instead of aborting. However, this is sufficient to allow MX clients like 'motor' to start up even if one or more of the MX servers are not running which is the most common scenario. This is only the first step in the fault tolerance upgrade that I have been talking about, so there is a lot more to come. Changed the start routine for the 'sis3801' driver so that it now sends commands to the SIS3801 in the correct order as recommended by the engineers at Struck. With the old version of the driver, the first measurement would always be for an interval that was slightly less than the requested interval. The new version of the driver no longer has this problem. Added to 'motor' and 'mxserver' the ability to trace the startup of an MX database by adding '-t' to the command line. This makes it easier to determine which record is failing in mx_open_hardware() if an error is occurring at program startup. This was implemented by using the new 'inithw_flags' argument to mx_initialize_hardware(). Found and fixed a serious bug in the handling of limit switch detection by the MX server. Essentially, the MX server was reporting information about the negative limit when asked about the positive limit and vice versa. The consequences of this error have been limited up to now by the fact that I usually test both limits regardless of which direction the motor is moving in, but it is better to get it right. Added support for segmented move pseudomotors. A segmented move pseudomotor breaks up a long move into a series of short move segments. This is to support motors that can successfully perform short moves, but not long ones. Added support for Compumotor 6K and 6000 series digital input and digital output ports. This support has not been tested yet. However, I plan to use this driver to control the shutters that come with the ADSC CCD system recently installed at APS Sector 17, so the drivers should be tested soon. Fixed a bug in the PMAC motor driver so that it now correctly handles motor speed and acceleration. Improved the handling of error conditions by the driver. Added support for 'network_rs232' devices. This allows an MX server controlled RS-232 port to be used remotely from an MX client. At the moment it is very slow, because it is using single character I/O. This will be fixed later. Also added support for 'soft_rs232' devices. This was added to make it simpler to test the 'network_rs232' devices. All a 'soft_rs232' record does is echo back the last string sent to it. The energy pseudomotor now checks for the MX scan fast_mode flag when looking up the crystal D spacing. The assumption here is that the current value of 'd_spacing' is unlikely to change while a scan is in progress, so there is no point in repeatedly asking for its value for each point in the scan. Deleted four unnecessary Channel Access calls from the initialization routine mxd_epics_motor_open(). These calls were initializing the speed and acceleration fields and getting the version number of the EPICS motor record. Now the speeds and accelerations will only be read if they are about to be used, which is generally only at the start of quick scans. Making this one change reduced the startup time of 'motor' at MRCAT from 24 seconds to 4 seconds. MX scan records that include multiple MCAs as input devices will now correctly save the counts from all the MCAs in the MCA data files that are created at each point of a scan. In this case, the MCA data will be recorded in the data files in multiple columns. The first column will correspond to the first MCA in the input device list, the second column will correspond to the second MCA, and so forth. The 'measure dark_current' command in 'motor' by default now uses an MX timer called 'dark_timer'. However, if 'dark_timer' does not exist, it uses the timer 'timer1' instead. The 'count' command in 'motor' can now specify the timer to be used for counting. If the first device listed after the measurement time is a timer record, then that record is used as the timer for the measurement. Otherwise, 'timer1' is used as before. MX 'network_motor' records now ask the remote server for the value of the 'motor_flags' field in the remote record. This is used to determine whether or not computations of pseudomotor positions from real motor positions and vice versa should recurse across the network connection or not. This is important for MCS quick scans, since the computation of the pseudomotor position from the encoder position for the real motor can take a substantial amount of time if the computation recurses across the network into a remote MX server. mx_open_hardware() now calls both the open and write_parms_to_hardware driver functions and mx_write_parms_to_hardware() has been deleted. In some future release, the write_parms_to_hardware driver function will disappear, so drivers using it should move that code to the open function. In addition, the read_parms_from_hardware driver function will probably be renamed at some point to something like update_record_values. Also, mx_read_parms_from_hardware() will probably be consolidated with mx_update_record_values(), since they are both attempting to do approximately the same thing. Version 0.50.0 (08/19/01): Since the beginning, MX has used a file naming scheme that required source code file names to fit into the old MSDOS convention of 8 characters for the file name and 3 characters for the extension. This was done because back in 1995 MSDOS was still an important platform and I felt the need to support it. Here in 2001 though, MSDOS is no longer that important a platform. Since I believe strongly in the documentation value of long, descriptive names, I have taken this opportunity to rename many of the files in the source code to longer names. Some examples of this include renaming 'mx_ain.h' to 'mx_analog_input.h', renaming 'mx_usint.c' to 'mx_user_interrupt.c', and so forth. This is a change that I have wanted to make for some time now. The motivation for doing it now is that we plan to put the MX source code under CVS control soon. Renaming the files after they are in CVS would leave a lot of relict files in the CVS repository under their old names, so I felt this was better to do now. For the most part, this should only affect people who are writing programs that use the C language interface to MX. For the most part, the name changes to MX header files should be fairly obvious, but if you have any problems, please contact me and I will help you make the change. However, there are three changes that potentially affect all users of MX: 1. The directory structure of the source code tar files has been changed such that there is a new top level directory in the tar file with the same name as the package. Thus, directories such as 'libMx', 'motor', 'server', etc. that used to be top level directories in the old source code tar files, are now one level down as 'mx/libMx', 'mx/motor', 'mx/server', and so forth. Similar changes have been made to the other MX-related source code tar files as well. For example, 'mxtcl-0.50.0.tar.gz' now has a top level directory called 'mxtcl' and 'optimize-0.50.0.tar.gz' now has a top level directory called 'optimize'. This change allows (indeed expects) the user to unpack all of the tar files in the same directory with all of the necessary directories being created by the extraction process. The online documentation at the MX web site has not yet been changed to reflect this, but I will do that as soon as I can. 2. The names of the architecture targets in MX have changed. The architecture targets used to be restricted to three letters since this is how many letters would fit into the MSDOS style file extension of a file like 'Makehead.lin' or 'Makehead.w32'. Since this restriction has now been lifted, I have made the following changes to the architecture names: in the top level Makefile in libMx --------------------------------------------------------------------- ARCH = djg --> ARCH = djgpp Makehead.djg --> Makehead.djgpp ARCH = hp --> ARCH = hpux Makehead.hp --> Makehead.hpux ARCH = sgi --> ARCH = irix Makehead.sgi --> Makehead.irix ARCH = lin --> ARCH = linux Makehead.lin --> Makehead.linux ARCH = osx --> ARCH = macosx Makehead.osx --> Makehead.macosx ARCH = sol --> ARCH = solaris Makehead.sol --> Makehead.solaris ARCH = solgcc Makehead.solgcc --> ARCH = solaris-gcc --> Makehead.solaris-gcc ARCH = sun --> ARCH = sunos4 Makehead.sun --> Makehead.sunos4 ARCH = w32 --> ARCH = win32 Makehead.w32 --> Makehead.win32 3. The names used to specify several drivers in MX database files such as 'motor.dat' and 'mxserver.dat' have been changed. The following name changes have occurred: Old name New name -------------------------------------- win32com --> win32_com com --> dos_com s10id_motor --> aps_10id_motor s18id_motor --> aps_18id_motor apsid_qscan --> aps_id_qscan The first two were renamed to reduce the potential for confusion with Microsoft's DCOM and COM+. The second two were renamed to make it clearer that they were for use at particular beamlines of the Advanced Photon Source. The 'aps_id_qscan' driver is not in general use yet, so it was easy to rename it to match the other APS specific drivers. With these changes, it is no longer possible to compile the MSDOS DJGPP port directly under MSDOS 6.22 and below. It should be possible to compile it using the MSDOS 7 that underlies Windows 9x, but I have not tested this yet. The mxdriverinfo program that was previously packaged separately has now been bundled with the main MX source distribution. mxdriverinfo is a command line utility that can be used to display the available MX driver types and the individual record fields in a particular driver. It was originally written to be used by the Python-based GUI for editing MX database files that is currently under development, but will now be bundled with the primary MX distribution since it is potentially of more general interest. The source code for mxdriverinfo is located in the new 'mx/util' subdirectory, while the documentation for it is in 'mx/doc'. Please note that essentially no other features besides mxdriverinfo have been added to this release over version 0.27.3 because the whole purpose of this release was to rename most of the files. I did fold in one bugfix to the compumotor_lin driver to make it compatible with quick scanning, but that was it. You may note that this version is called 0.50.0 rather than 0.28.0. This happened because several people have pointed out to me that MX has been stable for quite some time now in spite of having a 0.x version number. It was asserted that a 0.x version number implies that the code is not stable yet and suggested that I bump the version number up to 1.0. However, there are still a couple of features that I want to include before declaring a release to be version 1.0. In particular, I want to include the first version of the fault tolerance upgrade in a 1.0 release, so 1.0 probably will not happen for a couple of months. However, I will probably bump the version number up to 0.99 sometime in the near future. In the meantime, I have bumped the version up to 0.50 to reflect the fact that the renaming of most of the files is a moderately large change. Version 0.27.3 (07/19/01): The port of MX to the release version of MacOS X is now complete. A preliminary port of the MX Tcl/Tk extensions is also available. Read the change log for the MxTcl package to see more on that. Added a port to the Cygwin Unix-like environment for Microsoft Win32. The basic functionality is now present including MX network communications. Serial port support using the Unix 'tty' driver has been implemented, but not tested. Some work has been done to implement a Cygwin port of the MX Tcl/Tk extensions, but this port is not fully functional yet. In addition, support for compiling libMx as a DLL has not been implemented yet, so libMx is statically linked into each binary. Prototype checking at compile time of the printf-like mx_info(), mx_warning, mx_error, and MX_DEBUG() functions has now been implemented under GCC. Adding this test found a variety of cases where format strings did not match the arguments. Hopefully, this will reduce the number of opportunities for MX to core dump while attempting to print out seldom-triggered error messages. Added a new interface class to MX for VME crate control. The first interface driver for this class uses the National Instruments VISA library to control VME-PCI8026 crate controllers via the VXI::MEMACC resource. Added an as yet untested MX VME driver for communicating with VME devices via the EPICS VME record. Added a driver to control the SIS 3801 MCS via an MX VME record. At present, this driver handles single point measurements that are gated by the internal clock inefficiently, since there is no way to synchronize with the internal clock. This will be fixed later by changing the clock speed for such measurements or using an external clock. Added MX digital I/O drivers to read from and write to VME memory addresses via the MX VME record. Added a first cut at support of the X-Ray Instrumentation Associates DXP-2X multichannel analyzers. Currently, there are two versions of this driver. One version uses the new Mesa Data Server while the other version uses the XerXes MCA control library. At present, the drivers for this MCA do work, but there are performance problems in the drivers and MX that will need to be solved before this device can be used routinely on a beamline. Ensured that network MCA records initialize their regions of interest from the remote server. Added support for writing out an MCA spectrum at each point of an MX scan. At present, this support does not yet handle the presence of multiple MCAs correctly, so there is more work that will need to be done here. Added support in 'motor' for commanding the MCA to count for a specified real time instead of a specified live time. Dark current measurements now are only performed for scalers with the 'suppress_dark_current' field set to 0. MX analog input and output drivers now distinguish between drivers for which the raw device interface uses long integers and for which the raw device interface uses doubles. This support uses a subclass flag in the MX_ANALOG_INPUT or MX_ANALOG_OUTPUT structure which is analogous to the corresponding subclass flag in MX_MOTOR structures. Added new scan header token %scan for SFF format. This allows fields from the scan record such as 'num_measurements' to be written to the SFF file header. Added support for recording the values of analog output, digital output, and amplifier gain for an MX scan in the scan output file. Support was also added to 'motor' for displaying these as part of the output of a 'count' command. Added support for the Newport ESP series of motor controllers. So far this support has been tested with an ESP300 motor controller. Since this series does not use the prefix MM in its model names, I have renamed the old *_mmx000.* files to *_newport.* Modified the PMAC interface driver to remove the section that initialized certain common I-variables. It has been decided that this would be better handled by saving the PMAC's configuration with these I-variables set. Other minor changes to delete string termination characters from returned strings were also made. Added support to the PMAC motor driver for setting the current position of a PMAC motor to 0. Added analog and digital I/O records for manipulating PMAC internal variables. PMAC analog I/O records can be used with PMAC variables that use either floating point or integer numbers. PMAC digital I/O records should be used only with PMAC variables that represent integer quantities. MX now has support for autoscaling Keithley gain settings and/or filter thicknesses as the incident X-ray flux goes up or down. This feature allows the detector electronics to stay in their most sensitive range as the X-ray flux changes. This addition was motivated by the needs of powder diffraction, but is clearly useful for other kinds of experiments. Added support in 'motor' for specifying autoscaling parameters. Revised support for scan measurement fault and measurement permit records to become more modular. This makes it easier to add new types of measurement faults and measurement permit records for scans. This change was motivated by the fact that autoscaling support for scans now makes use of the measurement fault support. Also supported are some APS topup related interlock variables. Added the concept of 'fast' and 'slow' mode to the MX database. In 'slow' mode, the MX database will operate the same as always, but in 'fast' mode, a flag will be set that will allow certain MX driver types to skip certain time consuming operations that are not always necessary. At present, fast mode is only enabled while a scan is in progress. Modified the Keithley 428 amplifier driver to take advantange of the fast mode described in the previous paragraph. In fast mode, the Keithley driver now returns the amplifier gain last set by the driver rather than querying the Keithley for the gain. Since Keithleys tend to respond very slowly to commands, this makes it more practical to document the Keithley gain in scans that are using autoscaling. In slow mode, the Keithley driver behaves the same as it always has. Modified the MX amplifier support to add the ability to report the allowed range of gains supported by the amplifier. Modified the 'soft_amplifier' driver to only allow amplifier gains in the range from 1 to 1e10. This was added to aid in the testing of code that handles out of range gain requests. Added support to the 'net_amplifier' driver for requesting the allowed gain range from a remote server. Added support to the 'monochromator' pseudomotor for quick scanning dependent motors like 'normal', 'parallel', and so forth. Modified the LakeShore 330 temperature controller motor driver to handle error codes returned by the controller. Added support for 'synchronous_motion_mode' to the MX motor class. This sets a flag that instructs pseudomotors that are comprised of multiple real motors to attempt to synchronize the motion of the various motors such that they reach the destination at the same time. Not all pseudomotors currently support this and some of them probably can't support it. Added 'bit_in' and 'bit_out' drivers to manipulate individual bits of digital I/O registers and other records using integer fields. Added a 'blind_relay' driver to support the manipulation of filter settings and anything else that can be controlled by a digital output register. This driver differs from the 'generic_relay' driver in that it does not attempt to verify that the output value has had the desired effect on the external hardware. Added flags to the 'generic_relay' driver to relax some of the conditions under which it generates error messages due to mismatches between the commanded and measured relay position. Moved multi-axis start functionality for the Compumotor drivers into a new function called mxi_compumotor_multiaxis_move() in the Compumotor interface driver. This function is used to implement both simultaneous starts and linear interpolation moves, although the linear interpolation moves do not use the correct motor speeds as of yet. Added a new 'compumotor_trans' driver. This driver supports simultaneous start of a group of Compumotor motors and uses the support described in the previous paragraph. Added support to the 'translation_mtr' driver for speed changes required by quick scans. This driver does not support simultaneous starts, so there is a limit to how well this functionality will work. Added a driver for the Pontech STP-100 motor controller. This is a very capable, but inexpensive motor controller and driver for stepping motors of up to 2 amps per phase. The 'soft_motor' record has now been enhanced to include support for finite speeds and accelerations. This version of the driver assumes that the soft motor has a trapezoidal velocity profile and computes simulated positions for the motor based on the requested speeds and acceleration. The 'soft_motor' record now uses new support for dead reckoning calculations of motor positions. Up to now, the 'soft_motor' driver has also been used to effectively comment out a motor in the MX database, since it did not have any driver specific fields and thus was compatible with any other kind of motor record. Since the new version of the soft motor record now includes speed, base speed, and acceleration fields, it is no longer possible to use the soft motor record in this fashion. Consequently, I have now created a new driver called 'disabled_motor' which functions identically to the old 'soft_motor' driver in previous versions of MX except for the name. In the future, one should used 'disabled_motor' records to comment out motors in the database and use 'soft_motor' records only for emulating real motors. The 'soft_scaler' record has been modified to support the use of intensity modifiers. The intensity modifiers tell the soft scaler record to consult the values of amplifier and/or filter control records to compute modifiers for the computed value of the soft scaler. This allows the soft scaler record to correctly simulate the response of the scaler to simulated gain changes of an amplifier or insertion and removal of attenuating filters. This support was used extensively in the testing of the autoscaling support mentioned above. The 'elapsed_time' pseudomotor has been enhanced to use the mx_clock functions for generating delays and displaying time intervals. This will allow delays and time intervals to be specified at subsecond resolution with the same time granularity as the operating system clock. On x86 Linux, this means that delays and time intervals can be specified to 0.01 second resolution. On other operating systems, your mileage may vary. Examine libMx/mx_clock.c to see what the granularity will be for your operating system. The old 'ni488' driver for GPIB has now been revised so that it can be compiled under Linux using either the National Instruments distributed GPIB driver for their recent GPIB cards or using the Linux Lab Project driver. This revised version has not been significantly tested yet. The DOS port has now been tested with the most recent version of the Watt32 TCP/IP library and networking support seems to be fully functional now. The MX variable record support has now been enhanced to provide simple convenience functions for gets and puts of 1-dimensional MX variables. Added new generic functions mx_socket_send() and mx_socket_receive(). This change encapsulates the retry loop for synchronously reading from and writing to sockets such that it does not need to be replicated everywhere that needs such a loop. At present, only the XIA MCA drivers make use of these new functions. Changed the name of the MX error code MXE_UNDEFINED_RECORD to MXE_NOT_FOUND. This is a more general name that can be used for a wider variety of situations, but still handles the old meaning of the error code. Added two new MX error codes, namely, MXE_HARDWARE_FAULT and MXE_HARDWARE_CONFIGURATION_ERROR. Added two new driver related functions: mx_get_driver_for_record() - returns a pointer to the MX_DRIVER structure used by the specified MX_RECORD. mx_get_driver_name() - returns the name of the driver used by the specified MX_RECORD. This is useful for specifying the name of the driver in error messages. Lengthened various buffers that control the maximum size of an MX record description to allow up to 1200 characters. Checked to verify that strings whose lengths are defined using MXU_..._LENGTH style macros are adding an extra byte to the length as a guard against trivial programming mistakes. Added a simplified function mx_get_record_field() for returning a pointer to an MX_RECORD_FIELD structure for a given MX record. Added a convenience function called mx_scaler_read_dark_current_subtracted_value(). Deleted unused MX_GENERIC_FUNCTION_LIST tables from the 'mc6821' driver. Version 0.27.2 (02/07/01): MX has now successfully been ported to the beta version of MacOS X. Unfortunately, the MX Tcl/Tk GUIs have not yet been ported since the Tk and [incr Tcl] packages that the GUIs depend on have not yet been ported to MacOS X. I expect that this port will be only of limited interest to Mac users until the Tcl/Tk GUIs are available. The Joerger quick scan driver has been modified to include the acceleration distance and pseudomotor scanning support that the MCS quick scan driver already had. It should now be possible to quick scan any motor or pseudomotor on beamlines with EPICS- based Joerger scalers that does not cause more than one motor to move. Warning: It has now been verified experimentally that the recorded motor position for Joerger quick scans has a systematic error as expected. Only experiments that can cope with the systematic error should use Joerger quick scans. For example, most XAFS experiments can use the Joerger quick scan, while protein crystallography MAD experiments should _not_ attempt to use it. The monochromator pseudomotor has been enhanced so that it can control the bending radius of a sagittally focusing crystal as a function of the monochromator theta angle. The ability to control motors as a polynomial function of the monochromator energy has also been added. In addition, fixed exit control of monochromator crystal separation and longitudinal translation has now been successfully tested with X-rays. The quick scan support added to the Compumotor drivers in 0.27.1 worked correctly for Zeta 6104 controllers, but was found to prevent Compumotor 6K controllers from running at all. The Compumotor drivers have now been modified so that the new version works correctly with 6K controllers as well. This version also improves the reporting of motor errors such as stalls and faults to application programs. Quick scans now check to see if the motor hit a limit switch during the course of the quick scan. The MX driver for the EPICS motor record has been modified to leave the backlash velocity alone when motor speeds are changed. An MCA related scaler driver called 'mca_alt_time' was added. Since MCAs can make measurements using either the live time or the real time, this driver was added so that the real time can be read out when the live time is being used as a gate and vice versa. Please note that currently scaler drivers only report results back as long integers. Thus, a configurable 'timer_scale' factor was added to the driver. The reported alternate time value is multiplied by this timer scale factor before being rounded to the nearest integer. This allows the real/live time to be reported to subsecond accuracy. A mistake in the MX_MCS_FUNCTION_LIST array for the 'soft_mcs' driver was fixed. One of the array elements was missing, so the wrong functions were being invoked when mx_mcs_get_parameter and mx_mcs_set_parameter were called. A small amount of header file rearrangement was done. The changes were that the ioctl.h header file was deleted, while the select.h header file was renamed to mx_select.h and modified to include more operating system dependencies. The mx_current_clock_tick() function for SunOS 4 was fixed so that it works correctly. Support for using usleep() to implement the mx_sleep() family of functions was added in order to support MacOS X. 'Motor' now has support for directly changing the motor speed from the command line using the 'set motor ... speed' command. Some minor editing of warning messages was done. Version 0.27.1 (12/24/00): Made many improvements to multichannel scaler (MCS) quick scans. Added support for recording motor positions using encoder readout of the position. The technique used is to send the motor encoder signal into electronics that synthesize a pair of pulse trains with one set of pulses recording motion in the positive direction and the other set recording motion in the negative direction. These pulse trains are fed into two channels of the multichannel scaler and the incremental change in position of the motor is found by taking the difference between the number of positive counts and negative counts. Added the ability to perform MCS quick scans of pseudomotors that move only a single real motor. This support does not attempt to handle quick scans of pseudomotors that depend on multiple real motors, such as table pseudomotors, since this would be difficult to get working correctly without hardware support. Quick scanning is now available for the following MX motor drivers: compumotor - Compumotor 6000/6K databox_motor - Radix Databox motor epics_motor - EPICS motor record (VME58, et. al.) mm4000_motor - Newport MM-4000/4005 network_motor - MX network motor pmac_tc_motor and pmac_bio_motor - EPICS PMAC record (from the Argonne ECT division) pm304 - McLennan PM-304 soft_motor - MX soft motor Quick scanning is also available for the following MX pseudomotors: energy_motor - X-ray energy pseudomotor monochromator - Monochromator pseudomotor q_motor - Q pseudomotor s18id_motor - Sector 18-ID-specific monochromator pseudomotor Quick scan support for other motor and pseudomotor drivers will be added as time permits. Added several drivers to support the Radix Instruments Databox controller. This controller is normally used to control an X-ray generator system with a single stepping motor and a single detector readout. The drivers support preset time measurements either in a step scan mode or an MCS quick scan mode. Preset count measurements are supported in step scan mode. The drivers added include: databox - Interface driver for the Databox. databox_motor - Controls the Databox motor. databox_scaler - Reads out the Databox counter channel. databox_timer - Controls the Databox measurement time. databox_encoder - Used to store motor positions from a Databox quick scan. databox_mcs - MCS record used to store recorded measurements from a Databox quick scan. Added support for the 'theta_2theta' pseudomotor type. This pseudomotor attempts to move a theta-2 theta pair of motors as a coupled unit. It also reprograms the speed of the 2 theta motor to be twice that of the theta motor so that the motors are moving approximately in sync. Since this coupling is implemented in software, the synchronization is only approximate. Added support for the 'q_motor' pseudomotor type. This pseudomotor controls the quantity q = (4 * pi * sin(theta))/lambda = (2 * pi)/d. It was added in support of pair distribution function measurements, but it can be useful for other types of measurements as well. Reclassified the 'dac_motor' driver as a non-pseudomotor driver for the purposes of quick scans. Modified the support added in version 0.27.0 for running MX as a non-root user. In this version, there is only one script for starting the MX servers, namely, '/opt/mx/sbin/mx'. Now the servers will always be run under the correct userid even if the script was started by root. The behavior of the 'mx' script can be modified by the use of three one-line configuration files: /opt/mx/etc/mxuser.dat - User that MX servers are run as (default = 'mx') /opt/mx/etc/mxserver.opt - Command line options for the MX server (default = '') /opt/mx/etc/mxupdate.opt - Command line options for the MX update process (default = '') If the listed file does not exist, then the default value listed above will be used. Generally, one would use the command line options files to turn on debugging or to enable syslog message support as discussed below. Added support for sending MX log messages to the Unix syslog daemon. This support makes use of one of the syslog facility values from the local use only range LOG_LOCAL0 through LOG_LOCAL7. The particular facility used may be selected at run time, since other locally installed software may also be using values from this range of facility values. See the Unix man page for openlog(3) for more information on this topic. For now, this is only supported under Unix. 'mxserver' and 'mxupdate' have been upgraded to make use of the syslog support mentioned in the previous paragraph. Both programs now support command line arguments like '-l7' or '-L7' to turn on the support. For the above examples, the number 7 uses syslog facility number LOG_LOCAL7. Any value from 0 to 7 may be used as long as it does not conflict with other software on the system. The difference between '-l' and '-L' is that '-l' sends the messages from mxserver and mxupdate only to the syslog daemon, while '-L' sends the messages both to the syslog daemon and to stderr. If neither '-l' or '-L' are specified, messages are sent only to stderr. Please note that a line should be added to /etc/syslog.conf to handle the messages being generated. Using the above example, you might use a line like local7.* /var/log/mx.log to handle the messages being generated. You may also need to suppress the generation of messages in other log files controlled by /etc/syslog.conf, since the rather verbose output of MX may make it hard to find messages sent by other programs. Added some support for error messages to be generated if the MX server or update processes crash. These consist of signal handlers that intercept signals like SIGSEGV, SIGFPE, etc. A stack traceback is printed on operating systems that support it. Naturally, if the error that has caused the server to crash is severe enough, these signal handlers may not run successfully, but it is better than nothing. Added infrastructure to support the new MX server control utility 'mxcontrol'. This mostly consisted of adding record field support to the list head record. It was the last record type still using the old record support, so it was overdue. Renamed the MX list head record. The old name was 'list_head', while the new name is 'mx_database'. This is more in line with the policy that reserved record names should start with 'mx_...' and should also be more obvious to the average user. This change was made in support of the new MX server remote control program 'mxcontrol'. As part of the work described above, I fixed a bug in the MX server event loop that prevented queued events for the 'mx_database' from ever being processed. Modified the APS insertion device gap driver 'apsgap' so that it returns an MXE_PERMISSION_DENIED error status rather than MXE_DEVICE_IO_ERROR when the gap is not under user control. Renamed a number of functions in libMx/mx_var.c in order to get a more consistent naming pattern. Most of the changes take the form of renaming all the old mx_get_..._variable() functions to have names of the form mx_get_..._variable_by_name() to reflect the fact that they are passed record names rather than record pointers. Also mx_get_variable_with_type() was renamed to mx_get_1d_array_by_name() and mx_get_variable_from_record() was renamed to mx_get_1d_array() to more clearly reflect their actual usage. At present, scalar get and set variable functions have not yet been defined for all reasonable variable types. This deficiency will be fixed in a later version of MX. Version 0.27.0 (09/05/00): Revised the old Delta Tau PMAC drivers to match the current style of MX driver code. Also added some support for Turbo PMACs. Please note that this revised version has not yet been tested with a real Turbo PMAC, since I have not yet received one, so the driver initialization may not work correctly yet. This will be fixed as soon as possible. Added the 'network_mca' driver to support MX network multichannel analyzers (MCAs). This support has been tested with up to 8192 channels using the 'trump_mca' driver for the EG&G Ortec Trump MCA to control the raw hardware. Made minor changes and bugfixes in the 'trump_mca' driver. This was mostly related to reading out the MCA spectrum across the network via the 'network_mca' driver. Added three MCA related drivers. The first driver called 'mca_channel' treats an individual channel of a MCA as if it were a scaler. The second driver called 'mca_roi_integral' treats the region of interest (ROI) integral as if it were a scaler. The last driver is a timer driver called 'mca_timer' that turns on and off the counting of the MCA as if it were a timer. Added a timer fanout driver called 'timer_fanout' to trigger multiple timers for a given measurement. The timers are not started at exactly the same time, so this record should only be used if there is no way to use one timer or to synchronize the timers in hardware. Users should be warned that systematic errors may appear in their data if they are not careful in the use of this driver. Modified the 'soft_timer' driver to use MX clock tick support functions rather than blocking in sleep(). This allows the simulated timer to return before the requested counting interval is over so that it more accurately simulates the behavior of a real timer module. Changed the client side of MX network connections to use a dynamically allocated buffer for network messages instead of allocating them on the stack. Also enlarged the maximum message size to 163840. Some associated bugs in the handling of large record fields were fixed as well. Fixed a bug in the handling of MX message response codes in the MX server that was always forcing the response code to 0. Noticed that many MX programs were not invoking the function mx_initialize_clock_ticks(). Most client-side programs will never need this function, but the MX server also was not invoking it, which might have been slowing down its operation. Added support for running the MX server and MX update processes as a non-root user (by default "mx"). At present, this consists of adding an extra startup script called 'scripts/mxuser' which is copied to /opt/mx/sbin/mxuser by 'make install'. In later versions of MX, this is likely to be the default way of running. Modified the 'mxupdate' program so that it deletes old autosave files before trying to replace them. This allows 'mxupdate' to overwrite autosave files owned by another account as long as the directory containing them is writeable by 'mxupdate'. This change was made to make it easier to support running the 'mxupdate' process under a non-root userid. Version 0.26.5 (06/26/00): This version adds support for quick scans using multichannel scalers. So far this has only been tested using SIS 3801 (Struck-compatible) scalers using the EPICS MCA record written by Mark Rivers of the University of Chicago. Support has been added for using GCC 2.8.1 with Solaris 2.6. In the build system, this is called the 'solgcc' target. The table record added in version 0.26.3 has now been tested with real beamline hardware and a few bugs found were fixed. Added support for a software interlock that prevents data from being acquired during an Advanced Photon Source top-up injection. Version 0.26.4 (05/05/00): Added support for home searches to the 'pcstep' driver. Enhanced the support of home searches by the 'motor' program. Added digital input and output drivers for the Motorola MC6821 digital I/O chip. Added support for 'warning' level messages using mx_warning(). This is to be used for messages that reflect a possible problem, but are not serious enough to warrant returning an error code with mx_error(). Version 0.26.3 (04/20/00): Added a table record driver 'adc_table' for the ADC table used by IMCA-CAT at APS Sector 17. Also added a table pseudomotor driver 'table_motor' that uses the table record to perform pure rotations and translations of a fixed point on the goniostat. Fixed a bug in the handling of timer busy status for MX network timers. Fixed a different bug in the handling of scaler clears for MX network scalers. Split off part of the 'libMx/mxconfig.h' header file into a new 'libMx/mx_osdef.h' header file. This was done because the part that was split off into the new mx_osdef.h header had almost nothing to do with the rest of what is in the header. By putting only installation dependent defines in mxconfig.h, this should make it a little easier for installers to figure out what has to be customized for their particular beamline. Version 0.26.2 (03/16/00): Added MX drivers that support the SCIPE network protocol developed by John Quintana for motors, scalers, and timers. Updated the motor driver for Panther HI and Panther HE motor controllers from Intelligent Motion Systems, Inc. The driver now has separate record types for the HI and the HE, namely, 'panther_hi' and 'panther_he'. Added two sets of drivers for National Instruments ValueMotion stepper motor controllers like the PC-Step controller. One set of drivers ('pcmotion32' and 'pcmotion32_motor') uses the pcMotion32.dll interface for Win32 that is bundled with the board. The other set ('pcstep' and 'pcstep_motor') uses the MX port I/O interface and works on any platform that has a port I/O driver. The 'pcstep' drivers were tested under Linux and Windows NT. Please note that this is the series of controllers that was formerly sold by nuLogic as the pcStep family before nuLogic was bought by National Instruments. Finished testing the 'win32com' driver that controls RS-232 COM ports on the Win32 platform (Windows 95/98/NT). Fixed a few bugs in error handling that were still present. Added a Windows NT port I/O interface driver called 'dl_portio'. This driver uses the DriverLINX port I/O NT driver written by Scientific Software Tools, Inc. and downloadable from the web page http://www.sstnet.com/dnload/dnload.htm. You should note that this driver is a bit of a blunt instrument since it enables access to all I/O ports from 0x0100 to 0xFFFF. The MCA driver for EG&G Ortec Trump MCA has now been tested and works. This is the first MCA driver that has been written for MX, so MCA support should be regarded as somewhat immature. The most important feature missing at present is an MX network MCA driver which would allow the MCA to be used from other computers via the network. The primary thing holding this up at present is a limitation on the length of messages that can be transmitted via the MX protocol. Increasing this limit or removing the limit altogether is on the list of things to do. A command called 'mca' has been added to the 'motor' program which can be used to control an MX supported MCA. Added a macro called MX_API_PRIVATE. It is intended to serve as an indication that a function defined in an MX header file is not meant to be used by ordinary application programs. However, many of them _are_ used by device drivers. At present, MX_API_PRIVATE is just an alias for MX_API, but this may change in a later version. Fixed mx_username() on the Win32 platform so that it works correctly. On Windows NT, you get back the user name that the current process belongs to. On Windows 95/98, you will get back the user name that was used to log into the network. If the user has not logged into the network, MX will return the string "unknown". Since the AIX port is extremely out of date, I have moved the files for it to the 'old' subdirectory. Version 0.26.1 (02/01/00): Added a motor driver for Oregon Microsystems VME58 motor controllers operated via MVME162 controllers running an m68k version of Linux. This driver uses a Linux device driver that is available from ESRF at http://www.esrf.fr/computing/cs/sysadmin/rtk/emlinux/oregon.htm. The home page for VME-based versions of m68k Linux is located at http://www.sleepie.demon.co.uk/linuxvme/index.html. Please note that in order to compile MX on 2.0.x versions of m68k Linux, you must add HWTYPE_FLAGS = -Wno-missing-prototypes to libMx/Makehead.lin to work around a bug in glibc 2.0.x. Fixed some serious bugs in the drivers for the HSC-1 Huber Slit Controller from X-ray Instrumentation Associates. Errors in the handling of HSC-1 module names for old versions of the drivers occasionally resulted in illegal memory accesses that would cause the running program to be killed. Version 0.26.0 (01/05/00): Added a new startup function mx_setup_database() in analogy to the similarly named setup_database method in the MX Tcl package. mx_setup_database() is intended as a simplified MX startup routine for application programs that invokes all of the normal MX setup routines. This is to reduce the amount of knowledge of MX internals required to write simple MX programs. Renamed the MX_DISPLAY_MOTOR_MOVE_FPTR typedef to MX_MOTOR_MOVE_REPORT_FUNCTION. The name change is intended to make it clearer that functions of this type are used to display the progress of a motor move. At present, only 'motor' makes use of MX_MOTOR_MOVE_REPORT_FUNCTIONs. For this reason, all the functions in mx_motor.h that have pointer arguments of type MX_MOTOR_MOVE_REPORT_FUNCTION have been renamed to add the string '_with_report' to the end of the name. The function names mx_motor_move_absolute(), mx_motor_move_relative(), and mx_motor_array_move_absolute() have now become macros that call the underlying '_with_report' functions with a NULL argument. Split the old motor 'setpoint' field into separate 'destination' and 'set_position' fields since that should be more intuitive for other people reading the code. Modified the MX_NETMSG_... message type values in libMx/mx_net.h to have a more logical pattern. Changed mx_perform_scan() to use an MX_RECORD pointer as its argument rather than an MX_SCAN pointer. mx_perform_scan() is intended to be a publicly usable function so it should not be requiring pointers to internal data structures. Version 0.25.1 (11/30/99): Added support for the 'editline' command line editing package as an alternative to GNU Readline on Unix platforms. Editline supports the most commonly used subset of features of GNU Readline and is now bundled with MX. From now on, 'editline' will be linked into 'motor' by default, but you can change back to GNU Readline by uncommenting the appropriate set of READLINE_... definitions at the top of libMx/Makehead.$(ARCH). Added a wildcard capability to the 'show' command for 'motor'. For each 'show' command that can display a list of records, it is now possible to include wildcards. For example: show motors hslit* might show all horizontal slits, while show motors ?slit* might show all slits of any type. The supported wildcards are '*' to represent a sequence of any character, while '?' represents a single character. Modified the 'linear_function' pseudomotor to allow the linear function to depend on database variables as well as motors. Added the 'compumotor_lin' device driver. This allows the use of the linear interpolation moves supported by the Compumotor 6K controller. The 'compumotor_lin' driver is not yet fully debugged. Also improved the reliability of the various Compumotor device drivers. Fixed collisions of record field names with the new motor speed and acceleration fields. Made minor changes to allow MX to be compiled with the SGI Irix 6.5 compiler. Most of the changes were due to warnings about implicit type conversions. For example, assigning an unsigned long value to a signed long variable without a cast. Deleted remnants of an obsolete and unused stack and heap checking system. Version 0.25.0 (09/22/99): Implemented the new concept of "measurement types" in analogy to the already existing datafile and plot types. At present, the only measurement types that are implemented are "preset time" and "preset count". However, the measurement type code is written in such a way to allow other types of measurements to be added such as MCA related measurements. Implemented much of the infrastructure needed for quick scans. This includes the ability to get and set motor speeds and accelerations. It also includes the ability to command a motor to move until told to stop. At present, the quick scans built on top of this support are only useable with Joerger VSC 8/16 scalers via EPICS. This support has been lightly tested and seems to work at least for transmission XAFS measurements. However, the author of the Joerger EPICS driver has warned that the technique currently used does not guarantee that all scaler readings were taken from the same time interval, so the use of an alternate method he suggested that works via an EPICS scan record in the VME crate will be investigated for a release in the next couple of months. At present, the current implementation of Joerger quick scan should be regarded merely as a proof of concept and probably should not be relied on for routine data collection. There is also some support included for quick scans via the EPICS Struck MCS driver. However, this support has not yet been tested with real hardware, so I am fairly certain that it does not work as is. MX has now been ported to HP/UX 10.20. All of the associated MX Tcl/TK packages have been ported as well, so MX should now run on HP/UX just as well as it runs on Linux, SGI Irix, and Solaris 2. The DJGPP port of MX has been retargetted to use the WATT32 TCP/IP package from http://www.bgnett.no/~giva/. The TCP/IP part of this port has not yet been tested since I will not have time for that until after the upcoming SRI conference. Added untested support for scan enable/disable input signals. These would allow the scan enable signals to either be MX or EPICS database variables or be digital I/O signals. The interface will not be tested until I have a chance to install the Advanced Photon Source's VME-based software interface to machine status signals. Added support to MX to allow users to pause scans in progress and then either continue the scan or abort the scan. Settling times are now implemented using operating system timers rather than by using the 'timer1' clock. The effect should be about the same and it reduces the network traffic required to implement a scan. Renamed the 'superclass', 'class', and 'type' fields of MX_RECORDS to 'mx_superclass', 'mx_class', and 'mx_type'. This was to allow the MX header files to be compilable by C++ compilers since C++ compilers treat 'class' as a reserved word even inside 'extern "C"' blocks. Other incompatibilities will be fixed as they are found. Removed the MXFT_DATAFILE and MXFT_PLOT field types since there isn't a good enough reason to maintain them as fundamental record field types. Instead, each field is replaced with a pair of MXFT_STRING fields whose contents are copied to the corresponding MX_DATAFILE and MX_PLOT structures by the new function mx_scan_finish_record_initialization(). Added an 'after_scan_action' field to scan records. At some point in the future, this will be used to request that motors be moved back to their start positions or prescan positions, but this feature is not implemented yet. The only reason this is being added to the scan record at this time is due to the fact that the format of scan descriptions is being changed at this time. By adding the after_scan_action field now, we avoid yet another file format change for scan records in the near future. Added a placeholder for an 'ACL description' field. This is a placeholder for future support of access control lists in MX. No actual support of ACLs has yet been included. This field was introduced now for reasons similar to the 'after_scan_action' field mentioned above. Removed explicit dial units from motor records since this is now better handled via linear function pseudomotors. Fixed a bug in the 'set position' function for XIA HSC-1 motors. Fixed a different bug in the 'set position' function for Compumotor motors. Renamed the 'pmac_dpr_motor' record to 'pmac_tc_motor'. This indicates more clearly that this is the interface to Tom Coleman's EPICS PMAC software than the previous relatively obscure name. Deleted the remaining bits of the old segmented scan code. Deleted the remaining bits of the old attempt at an EPICS server interface. This interface is to be replaced by the mxca_server package which is currently under development and which uses the Portable Channel Access server. Version 0.24.1 (07/07/99): Added an incomplete port to VMS. This port is not yet useable. Version 0.24.0 (07/02/99): Added a "num_scans" field to all scan records. This allows the user to specify that a given scan be repeated several times. 'motor' and 'mxgui' were modified to support this change. Added the beginnings of a log facility to libMx. At present, this facility only supports the recording of scan starts and scan ends to a log file. Version 0.23.3 (06/18/99): Wrote a motor driver for the X-ray Instrumentation Associates HSC-1 Huber Slit Controller. The network scaler driver was writing the wrong value when it was trying to clear the remote scaler. This has been fixed. Modified mx_parse_hex_field() so that it can handle numbers in hexadecimal, decimal, and octal. This has the side effect of making MX network I/O for fields of type MXFT_HEX work correctly which was affecting the MX network digital input and output records. Version 0.23.2 (05/10/99): Permission has been granted by IIT to make the source code freely available on the Internet. Added IIT copyright messages to all the source code files. Added PC I/O port record types for Linux ("linux_portio") and for Windows 95/98, Windows 3.1, and MSDOS ("dos_portio"). Port I/O for Windows NT is not supported at this time. The "linux_portio" record uses a custom Linux device driver module rather than using ioperm(), iopl(), or /dev/mem. See the "portio-0.3.tar.gz" source distribution for the reasons why. So far, only the "linux_portio" driver has had significant testing. Added drivers to use Intel 8255 chips for digital input and output using the new "portio" interfaces. Only 8255 Mode 0 is supported. Added drivers to use AMD 9513 counter/timer chips via the new "portio" interfaces. The 9513 chips can be used as scalers, timers, and even as a low performance stepper motor controller. Added a motor driver for Physik Instrumente E-662 piezo controllers. Added MX network record types for analog I/O, digital I/O, scalers and timers. This allows a much larger fraction of a beamline's devices to be controlled by an MX server if desired. The driver for COM ports on Win32 platforms has now been tested and should work correctly. Added RS-232 record support for handshaking via the DTR-DSR lines in support of the Win32 platform. Realized there are some inconsistencies in the way that network analog input and output records are handled related to whether values should be transmitted as floating point numbers or as raw digital ADC values. Deciding what the correct behavior should be will require some consultation with user. Added an extra initialization function to the MX_RECORD_FUNCTION_LIST structure, namely, "finish_delayed_initialization". This is to allow a driver to perform a few final initialization steps after most of the MX system is up and running. This was added for the benefit of the Intel 8255 digital I/O chip drivers. The 8255 has the interesting feature that any time it's configuration register is reprogrammed, all of it's outputs are reset to zero. Thus, the programming of the configuration register by the interface driver must be delayed until after all of the dependent 8255 device drivers have been set up. So far, the 8255 drivers are the only ones that use a "finish_delayed_initialization" function. Modified the standard usage of MX_INTERFACE structures so that they are included directly in MX record structures rather than including pointers to MX_INTERFACE structures. The original behavior was brought about by an invalid analogy to the way that MX_RECORD pointers are handled. The analogy was invalid since MX_RECORD pointers can only be set up at run time, while in most cases MX_INTERFACE structures can be set up at compile time. This change allows MX_INTERFACE record field types to be treated the same as the intrinsic types for ints, floats, etc. The change leaves only record fields as a special case (not counting the fields at the start of each record field array). Added the function mx_timer_finish_record_initialization() to initialize some fields in MX_TIMER structures that were not being initialized correctly. On SGI, the Irix 6.5 compiler emits remarks about implicit type conversions in libMx/mx_net.c, libMx/mx_sock.c, and server/ms_mxsrv.c. These do not prevent the files from compiling. I will take care of fixing these implicit conversions sometime in the next release or two. The record field defaults structure for a "ks3063_out" record was incorrectly including the #define MX_DIGITAL_INPUT_STANDARD_FIELDS. This has been changed to MX_DIGITAL_OUTPUT_STANDARD_FIELDS as it should be. Modified the DSP 6001 CAMAC interface record to use the new "portio" functions for I/O access. Since I do not currently have access to a DSP 6001, this change is untested. Added support for analog output and digital output records to mx_update_record_values() since there are circumstances where it is useful to be able to read what the hardware says the output value is. The "motor" program now displays the value of digital I/O records in hexadecimal notation since this is more consistent with the way such ports are normally used. It is also possible to set the value of digital output records using decimal, octal, or hexadecimal notation via the "set device" command. Version 0.23.1 (02/09/99): Fixed a bug in the new version of the Unix TTY driver that was preventing it from working correctly. The unintended omission of the initialization for tty->file_handle was resulting in standard input being closed any time a tty record was contained in an MX database. Have written an interface driver and a motor driver for Velmex VP9000 motor controllers. Modified "motor" to allow MX variable records to be used as input devices in a scan. This allows the recording of things like the storage ring current from EPICS. "mxgui" already permitted this. Version 0.23.0 (01/27/99): Added a "make install" target in the makefiles. The makefiles and the code have been restructured so that all MX related code and data is placed under one directory tree, typically, "/opt/mx". An environment variable, MXDIR, is used at run time for MX programs to find where this directory tree is. Under normal circumstances, one can now install MX by merely running "make install" and then modifying the configuration files in the directory "${MXDIR}/etc" after the install is done. Have finished porting all of the C and Tcl/Tk code to Microsoft Win32, including scan plotting with Gnuplot and EPICS support. This means that the Unix and Win32 platforms should have equal levels of support from now on. So far, the code has been tested on Windows NT 4.0 and Windows 98. It should work on Windows 95, but this has not yet been tested. Converted all of the MX records to the new record support mechanism. Made modifications to the record field code that, if requested, allow new scan records to overwrite old scan records. Please note that a caller must specifically request this behavior for it to happen. This change was made in support of modifications to 'motor' that allow it to read multiple scan database files at startup time just like 'mxgui' can. Fixed a bug in 'motor' where SFF and XAFS scan header variables were not being propagated to the MX server. Added a 'resynchronize' function to the Compumotor drivers, so that users can manually recover from synchronization errors at run time. By default, 'motor' no longer tries to write to 'motor.dat'. However, it can be told to behave in the old manner via command line arguments. Modified 'motor' so that, by default, it does not write out scan databases every time they are changed. Instead, it prompts the user to save the scan database when they try to exit 'motor'. Modified the 'soft_scaler' record to look for its data files in the directory ${MXDIR}/etc if the environment variable MXDIR is defined. Found and fixed a number of places where variables were being used before being initialized. Adding the flags "-g -O" to CFLAGS when using gcc should prevent this from happening again. Version 0.22.7 (11/04/98): Version number incremented to keep up with the 'mxtcl' version number. Version 0.22.6 (10/29/98): Deleted ACE GUI code since we will not be going that route. Version 0.22.5 (10/21/98): Modified the handling of the mx_info(), mx_error(), and MX_DEBUG() families of functions so that it is possible for an application program such as the MX Tcl GUI to install its own handlers and redirect the output to GUI windows. A function family associated with mx_user_requested_interrupt() was written to provide a similar functionality for aborting motor moves and scans from within a GUI. There is now a working version of a motor driver for the Bruker D8 motor controller. The driver is not completely functional since it has no way of recovering from hitting a limit switch, but since the D8 controller is still only a prototype, this may be possible to add later. Wrote a driver for MX network amplifers in analogy to the MX network motor driver that already exists. Also wrote a driver for software emulated amplifiers to aid in offline testing. Fixed a bug in mxd_keithley428_write_parms_to_hardware() that was causing Keithley 428 electrometer offsets to always be reset to zero every time an MX application controlling the 428 was started. Version 0.22.4 (09/11/98): This version released only to keep the version number synchronized with the 'mxtcl' package version number. The only change of any note at all was a bugfix to the record creation routines for slit scans. Version 0.22.3 (08/21/98): In the process of building the Tcl wrapper library, some bugs in the handle support in mx_handl.c were found and fixed. Modified many of the MX_DEBUG calls in mx_field.c to use debug levels of 6, 7, or 8. This makes it easier to ignore output from record description parsing routines. Version 0.22.2 (07/15/98): Addition of more support for being invoked from Tcl. This release had few changes with most of the changes being in the MxTcl library. Version 0.22.1 (06/23/98): Added MX handle functions to make it easier to manipulate MX records from other languages like Tcl/Tk. First compile of MX using Linux libc version 6 (GNU libc 2) under Debian Linux. This led to the addition of the line "#include " or "#include " to several files that had not needed it before. Modified mx_insert_after_record() so that it no longer creates the record it is inserting. Creating the record is now handled by mx_create_record(). This required changing the function call interface to mx_insert_after_record() and mx_insert_before_record() to add the new record pointer as an extra argument. Version 0.22.0 (06/18/98): Shared library versions of "libMx" are now available for Linux, SGI Irix, and Solaris 2. There is also a DLL version for Win32 called "libMx.dll". "libmx" has been renamed to "libMx" to avoid a naming conflict. It seems that SGI Irix 6.3 is distributed with a shared library (known as dynamic shared objects there) named "/usr/lib/libmx.so". "/usr/lib/libmx.so" is apparently a modified version of the normal C math library "libm.so" that has enhanced error handling abilities. By putting an upper case character in the name "libMx", I make it much less likely that there will be a library name conflict under Unix in the future. Modified "motor/msclin.c" to fix a bug in the handling of scan setups and modifies for analog motors. The bug was that the scale and offset were not being applied in calculating the limits, so it was not straightforward to setup a scan for an analog motor with a scale that was not equal to 1. There are also bugs in the display of limits for various analog motor drivers, but that will not be fixed at this time. Version 0.21.10 (06/09/98): The MX server to EPICS server interface has been tested on a Silicon Graphics Irix 6.3 machine. Currently, move commands, position readback, motion status, and limit status have been tested and work at a basic level of functionality. In general, records for real motor controllers currently work better than those for pseudomotors. This is due to the way the "motor move absolute" command is currently handled in the MX server and will be updated at a later date. Note that in the present implementation, EPICS server mailbox records should not be used in servers that also contain EPICS client side records like the VME 58 motor driver, the Joerger scaler driver, etc. This is because the handling of EPICS events for the server mailbox records is currently incompatible with the handling of EPICS events for client records. At present, this is handled by placing the EPICS server and client records in separate MX servers and allowing the two to communicate via MX network protocol. For example, instead of including an "epics_motor" record in the same server as an EPICS mailbox record, place a "network_motor" record in the server. The "epics_motor" record will be located in the second server that the "network_motor" record refers to. Display of the deadband value has been added to the "print structure" driver function (aka, "show motor ???") for many motor types. The handling of backlash corrections has been modified so that a command to move to the same place that the motor is already at should no longer result in a backlash correction for the majority of motor types. Also discovered that for some analog motors a move request that about the same size or smaller than the intrinsic resolution of the motor can result in pathological backlash behavior. At present, this should be handled by establishing a small deadband for such a motor, but this deserves more examination later. Version 0.21.9 (05/27/98): The new monochromator pseudomotor has successfully been tested on APS Sector 17-BM using the main theta axis and the omega axis. Currently, it remains to be tested on Sector 17-ID under real use. More testing of the server and the update process has been performed. Three memory leaks were found and fixed in "mxserver". A motion deadband feature has been added to motor records. It is controlled by the 'deadband' field. A bug was found in the handling of Keithley 428 overflow conditions that caused the "motor" program to intermittently crash. This is now fixed. The timeout on TCP232 connections has been raised from 1 second to 5 seconds. This reflects the fact that currently there is a lot of garbage traffic on our local subnets. Added a 'resynchronize' command to allow the user to recover from handshaking errors between MX and the motor controllers. Currently, this is only supported for the McLennan PM304 driver, the Newport MM3000/4000/4005 driver, the MX network motor driver, and the MX soft motor driver. Version 0.21.8 (05/15/98): mx_motor_array_move_absolute() has been modified so that backlash corrections are handled better. Now the routine causes all the motors to move to the backlash position before starting the final move. The initialization for EPICS variable records has been changed so that a failure to find the given EPICS pvname does not cause the initialization routine to return an error status. This is allows programs like "motor" to run even if some EPICS variables defined in the MX database are not found at the time of program startup. All motor record types have now been converted so that they use new record field support. The MX routine mx_motor_read_record_description() that was used by old record type support has not been removed yet, but it will be removed soon. Version 0.21.7 (05/04/98): The most important addition for this release is the porting of the current version of the MX code to run under Windows NT 4.0 using Visual C++ 4.0. Most of the necessary work for non-networking parts of the code had been done for an earlier release. Thus, most of the work was just making sure that the Winsock support worked correctly. Theoretically, this version of the code should work under Windows 95, but this has not been tested yet. Any line in an MX database file that starts with the character '#' is now treated as a comment line. The '#' _must_ be the first character on the line. The following new commands have been added to Motor: count 'counting_time' 'scaler1' 'scaler2' ... set motor 'motorname' positive_limit 'limitvalue' set motor 'motorname' negative_limit 'limitvalue' set motor 'motorname' backlash 'backlash_distance' The 'count' command allows one to perform a single measurement of multiple input devices without requiring the setup of a scan. The various 'set motor' commands all have variants that allow specifying the argument in steps rather than engineering units. For example: set motor theta backlash -0.5 Version 0.21.6 (04/24/98): The primary addition for this release is an MX update/autosave/restore program called "mxupdate". This program provides the capability of periodically saving MX database value from the MX server so that they can be restored the next time the MX server is started. "mxupdate" also handles periodic polling of a selected list of variables so that their values are current. MX network variables now work correctly. They have been tested using multidimensional arrays including multidimensional arrays of strings. As part of the above development, a variety of bugs in the MX network protocol software have been found and fixed. Added 'set plot nowait' option to "motor". This allows a scan being run from a script to display a plot while the scan is in progress. However, the user is not required to hit a key to make the plot disappear at the end of the scan. Changed the name of the 'pm300' driver to 'pm304' to reflect the fact that it has only been tested with McLennan PM304 controllers and not any other McLennan controllers. Changed the 'pm304' driver so that it only restores a position value if the McLennan appears to have been power cycled since the last time MX spoke to it. Version 0.21.5 (03/26/98): The most important change in this release is the introduction of record dependency code. Now when a record is created, the routine mx_finish_record_initialization() looks to see if any MXFF_RECORD or MXFF_INTERFACE fields are in it. For each field of these types, parent-child dependency pointers are set up to reflect the dependency of the records to each other. Correspondingly, mx_delete_record() removes any child links and refuses to delete a record if it has any parent links. Renamed the MX_TYPE_LIST_ENTRY structure to MX_DRIVER. This resulted in changing the names of the functions mx_get_type_list_entry_by_name() and mx_get_type_list_entry_by_type() to mx_get_driver_by_name() and mx_get_driver_by_type(). I have split the 'field_number' structure element into two new elements, namely, 'field_number' and 'label_value'. Now 'field_number' simply maintains the array index number in the array of record fields which will change as the number of defined record fields for a given type is changed. 'label_value' will contain static values set by #define statements that can be used in case labels in the MX server. Added new record fields to all groups: num_groups, group_array, num_parent_records, parent_record_array, num_child_records, child_record_array. Added a 'linear_function' pseudomotor type that constructs the pseudomotor value from a linear combination of other motor records. Modified 'energy' and 'wavenumber' pseudomotors to better avoid getting 'Inf' results. Partially implemented a motor driver for Bruker GGCS controlled motors. Partially implemented a new monochromator pseudomotor. Version 0.21.4 (03/09/98): The National Instruments GPIB driver has now been tested under Linux with a National Instruments PC-II/A card. It works successfully with a Keithley 428 electrometer. An attempt to use the driver with an Ortec 974 counter/timer was only partially successful. Work has been started on adding support to the "motor" program for interoperating with the GRACE gui written by John Skinner of NSLS. This is only partially implemented at this time. Version 0.21.3 (03/03/98): MXC_RELAY and MXC_AMPLIFIER device record classes have been added. For relays, the only currently implemented device type is "generic_relay" which remaps bit patterns onto digital output and input records. For amplifiers, the only currently implemented device type is "keithley428" for the Keithley 428 Current Amplifier. The MRCAT XAFS datafile type has been modified to look for a record called "amplifier_list". If it finds one, this record is used as a list of MXC_AMPLIFIER devices. The amplifiers are queried for their current gain settings at the start of a scan and those values are written into the data file header rather than the values from the "keithley_gains" record. The MX scan routines now check for the presence of a variable named "shutter_policy". If this variable is set to 1, then at the start of a scan an MXF_OPEN_RELAY command will be invoked on a shutter record which is expected to be named "shutter". At the end of the scan the MXF_CLOSE_RELAY command is used to close the shutter. If "shutter_policy" is set to 0, then the scan will not attempt to look for a shutter. In addition, "open" and "close" commands have been added to motor to support the operation of a shutter. These commands have aliases of "retract" and "insert" since that terminology seems more natural when the "generic_relay" record is used to implement a filter. A "soft_scaler" record type has been implemented that reads a file of scaler values vs. motor positions for a user specified motor. This allows for more useful offline testing of scan software than the previous practice of using a real CAMAC scaler driver talking to a simulated CAMAC crate. A "label" field has been added to the MX_RECORD structure. It is called "label" rather than "description" since the present code base uses the term "description" to refer to the character string that represents the record in a static ASCII database file. A "set label" command has been added to "motor" to allow for the safe manipulation of these fields. Also, the MRCAT XAFS datafile type driver has been modified to take advantage of the label field. When generating column titles for the scaler channels, the XAFS datafile driver now looks to see if the given scaler has a label field for which the result of strlen() is greater than zero. If it is, then the "label" field is copied to the column header rather than the "name" field. A record field flag MXFF_READ_ONLY has been added. This is to prevent motor's "set field" command from modifying this particular field. In the future, the MX server will also use this flag to prevent clients from changing those fields either. This will generally only be used for fields that should only be modified at the time the record is created and which potentially would cause the program to crash if changed. Examples of this are record fields that set the dimensions of MXFF_VARARGS fields, where if the value was increased would probably cause the process to core dump. Note that this is not the start of an access security package. I intend to implement access security in a different manner using access security structures. This is merely to mark fields that should never be changed by anybody including the server except when the record is created. The function mx_update_record_values() has been added as a replacement for the motor record specific mx_update_position(). The purpose of this function is to do whatever it takes to synchronize the contents of the MX_RECORD structure and its dependent data structures with the current state of the actual device. In support of this, an "update_record_values" entry point has been added to the MX_RECORD_FUNCTION_LIST. The majority of record types will probably leave this entry point set to NULL and use a generic response coded into the mx_update_record_values() function. But some record types have special needs and this entry point will take care of that. In addition, once the MX server adds support for periodically polling the state of certain devices, I intend to use the mx_update_record_values() function to perform that update. Thus, it is important that nothing be done in the update_record_values entry point that would prohibit it from being invoked in a daemon process. All of the scaler, ADC, DAC, and digital I/O records have now been modified to use the record field interface. The only types of records that still use the old style of records are 3 infrequently used motor record types, all of the timer record types, the one existing encoder record type, all of the RS-232 interface record types, and to some extent the CAMAC interface record types. Support for the LabPC+ scaler and timer record types has been removed since even with external hardware to help them, the two record types have very limited functionality. On the other hand, support for the LabPC+ ADC, DAC, and DIO record types has been retained and is fully functional. The GPIB driver and function call interface has been revised to be more consistent with traditional ways of interfacing with GPIB devices. The mx_camac_... function definitions have been revised to use MX_RECORD pointers rather than MX_CAMAC pointers. This is part of the program to make different records talk to each other almost exclusively through MX_RECORD pointers. Some parameter testing that was inadvertently removed from the E500 driver has been restored. A command line parameter "-u" has been added to motor to allow motor to operate correctly when its standard input and output have been redirected to pipes. This flag sets standard input and output to be unbuffered. In addition, the functions mx_unix_kbhit, cmd_read_next_command_line, and motor_get_string() have been modified to call isatty() before invoking any functions that expect standard input or output to be a TTY device. If they are not TTY devices, then alternate lower functionality code is invoked. A global motorrc file has been added. Its default location for Unix is "/usr/local/lib/mx/motorrc". Commands from this file are executed before the user's personal motorrc file "~/.motorrc". A "set parameter_warning_flag" command has been added to motor. This is to implement a relatively low quality security check on changing of motor parameters that was specifically requested by a user. Some improvements to the Keithley 500-SERIAL RS-232 to GPIB interface driver have been made. This is to allow the setting of the EOI parameter and more flexible setting of the line terminators. Some minor renaming has occurred. The "motor_subclass" for motor records has been renamed to "subclass" since the "motor_" part was redundant. For RS-232 drivers, functions and entry points with names ending in "_unread_chars" or "_unwritten_chars" have been renamed to "_unread_input" and "_unwritten_output" correspondingly. This is to make the names more like the corresponding functions for GPIB interfaces. An mx_difference() has been implemented. This implements a relative difference function of a type I saw suggested in a book. An mx_match() function has been added for simple wildcard matching which was found in the same book. The PDI40 and PDI45 drivers have been disabled for now, since I currently don't have the time free to do the non-trivial amount of work required to update them. The d_epain.c driver has been disabled. This functionality will be replaced by new drivers for EPICS process variables in the MXR_VARIABLE superclass which have not been written yet, but which are imminent. Version 0.21.2 (02/13/98): A GPIB interface driver has been developed for the Keithley 500-SERIAL module. This unit is an RS-232 to GPIB converter that should be able to interface with any RS-232 driver that MX supports. So far the driver has been tested using the 'tty' driver under Linux and using an Ortec 974 counter/timer module as a test module. This is the first MX GPIB driver that has been tested to any great extent. A driver for National Instruments style GPIB interface libraries has also been written, but has not yet been tested due to problems in getting the TNT-4882 board I have working with the Linux GPIB driver. The CAMAC E500 motor driver has been updated to use the new record support routines. The E500 driver has not recently been tested, but I will do this the next time I am at NSLS. Also, a motor driver for the NSLS MMC32 motor controller via GPIB has been written using the manual as a guide. This should be tested sometime in the next three months. Three drivers have been written to interface with the Ortec 974 counter/timer NIM module. The first driver is an interface driver to talk to the module as a whole via either RS-232 or GPIB, while the other two drivers include a scaler driver for the counter channels and a timer driver. The module has been successfully operated via both RS-232 and GPIB. A new MXFT_INTERFACE record field type was introduced in order to simplify the support of devices that can be accessed via multiple types of interfaces (like the Ortec 974). This helps avoid the problem of needing varying numbers of parameters depending on the interface type. For example, suppose one wants to talk to an Ortec 974 via either an RS-232 interface record 'ttyS1' or via a GPIB interface record 'gpib0' at GPIB address 3. For the first case, the MXFT_INTERFACE field would merely be the record name 'ttyS1'. For the second case, the MXFT_INTERFACE field would become 'gpib0:3'. The general form is 'record_name:addressing_info' where the ':addressing_info' part can be left out for an interface that does not need it. The 'addressing_info' part can include any information that the given interface requires as long as the record specific routines understand it. Another record field type named MXFT_HEX has been added. This is to allow the specification of numbers that are most conveniently expressed in hexadecimal units into the record description. For example, a PC I/O port address might be described by such a field. Internally, the values in an MXFT_HEX field are always stored as unsigned long values since I did not want to create all the various permutations of short, long, int, etc. as duplicates of the regular integer fields. The top level function interfaces for RS-232 records has been changed to use MX_RECORD pointers rather than MX_RS232 pointers as before. This change was made since my ultimate goal is that different records refer to each other only via their MX_RECORD pointers. This helps avoid the problem of having inconsistent pointers to record data structures. The RS-232 record class has been modified to add read and write line terminator record fields for use with devices that use mostly printable character strings and little to no binary data. This allows one to implement generic mx_rs232_getline() and mx_rs232_putline() routines to match the generic mx_gpib_getline() and mx_gpib_putline() routines that have just been implemented. Some RS-232 devices have such sufficiently arcane serial protocols that a generic getline or putline function will not be sufficient to interface to them, but it is hoped that in the future most new RS-232 interface support will use the getline and putline interfaces. An interrupted scan now explicitly calls the function mx_timer_stop() to stop the counters from counting. This was necessary in order to support the Ortec 974 counter/timer for which the scaler channels can only be accessed if the timer is not running. Versions of the mx_msleep() and mx_usleep() routines have been developed that make use of the Posix.1b ( or Posix 4 ) routine called nanosleep() which gives a higher level of timing precision on those platforms that support it. Currently three MX platforms support nanosleep(), namely, Linux, Solaris 2, and SGI Irix. The header file 'libmx/mxconfig.h' has been massively reorganized for this release. Most of the operating system dependent symbols that were being defined in that file were only used in one source code file. Thus it seemed more convenient to define those symbols in the file that uses them. A more general configuration system for MX is still needed. I would use 'autoconf' for this if: 1. I could find a clear explanation of the details of how to set up 'autoconf'. I do not regard the 'info' files that come with it as a 'clear' explanation. 2. I could find an easy way to make 'autoconf' coexist with compilation on Microsoft operating systems and others without requiring too many files that need to be independently updated. The LabPC+ drivers have been updated to version 0.5 of the device driver. While doing this, I chose to delete the scaler and timer drivers that used to be included. This is because using those drivers required the construction of an external box of hardware in order to be used. Besides, after using two of the three counter channels to implement the timer, only one 16-bit scaler channel was left. Thus, I've decided that the scaler and timer drivers for this card are not sufficiently useful to warrant keeping them up to date. In any case, the LabPC+ card works just fine for ADC, DAC, and DIO applications. The EPICS timer driver has been modified to ensure that the Joerger module is in one-shot mode before the starting of counting. This is to avoid the problem of people forgetting that they have left the Joerger in continuous count mode. Version 0.21.1 (01/27/98): The basic functionality of the prototype MX server is now in place. So far the handling of queued incoming events has only been tested for devices with the event interval set to zero. Testing of a non-zero event interval awaits the opportunity to test with a device that is slow enough and recalcitrant enough to require the queueing. At present, there is no mechanism for a list of devices to be polled automatically. Currently this can be simulated by the use of a 'motor' client that runs an extremely long time scan reading in all the input devices you want to poll, but this feature will need to be improved. Version 0.21.0 (01/19/98): The primary feature of this release is an early test version of the MX client/server network code. This code is not yet ready to be used in production systems, but is getting close. At present, the MX server supports network connections using a primarily ASCII based protocol. Also, an EPICS database for control of motors has been devised that interfaces with the MX server through EPICS Channel Access value changed callbacks that are sent from the EPICS IOC to the MX server. Another change is that the APS undulator gap driver has been changed to match the revised naming convention of the EPICS process variables for APS undulators. Fixed a rather surprising bug in the motor_is_busy routine for the translation_mtr driver. Namely, if none of the motors reported themselves as busy, the value of 'motor->busy' didn't get a value assigned to it. It's rather interesting that this worked correctly on SGIs in spite of the bug. Version 0.20.0 (11/19/97): The major change in this release is that most of the motor records have been converted into record field style records. A few that we are not currently using, like the CAMAC based motor records have not been converted, but I will go back and fix them up later. The primary changes in support of this are: 1. The creation of the necessary STANDARD_FIELDS macros for the record fields and associated data structures that allow other routines to find the record fields. 2. The replacement of the read_record_description and write_record_description entry points in the drivers by create_record_structures and finish_record_initialization entry points. In addition, the print_summary functions were eliminated. A related change is the deletion of the record->units field in the MX_RECORD structure and its replacement by motor->units, dac->units, or adc->units fields in the corresponding MX_MOTOR, MX_ANALOG_OUTPUT, and MX_ANALOG_INPUT structures. Version 0.19.0 (11/12/97): The primary feature of this release is a restructuring of the MX_MOTOR structure to prepare it for use with the record field support. The change was to break up the big union of stepper and analog parameters into little individual unions for each of the motor parameters. This allows individual parameters for both stepper and analog motors to always have the same memory address, which is necessary for MX_RECORD_FIELD support. In addition, the high level APIs for motors, scalers, and timers was changed so that they are always invoked by passing them an MX_RECORD pointer rather than MX_MOTOR, MX_SCALER, or MX_TIMER pointers. By making the MX_RECORD pointer be a single point of contact between records, this makes it easier to insure the correctness of pointer links between records. This will also make it easier to add dynamic creation and deletion of general record types beyond just scan records and to create interfaces to scripting languages like Tcl and Perl. A number of changes were made to the "motor" program to make the handling of user input in the "setup scan" and "modify scan" commands. Most of the prompts for these commands now have default values even for the "setup scan" command. In addition, more code to reject invalid input by the user has been added. This work was prompted by the discovery that entering an invalid datafile name, datafile type, or plot type could cause a core dump at a later stage in the program. The ultimate cause of the core dumps mentioned above is a design flaw in the current version of the record creation function "mx_create_record_from_description". The nature of the flaw is that the record being created is added to the record list before the correctness of the information in its string description has been verified. The result is that it is possible for a broken record to be left in the record list if "mx_create_record_from_description" fails. This is not so much of a problem at program startup, since "motor" currently aborts if any problems are found in its description files, but is definitely a problem with the dynamic creation and deletion of scan records. The most likely events likely to cause core dumps due to this design flaw are anytime the scan record database is written back to disk ( which results in the loss of all scans ) or if a broken record is accessed by a later command. The best solution to this problem is to delay the adding of new records until the end of "mx_create_record_description". However, this fix will be deferred at this time since it is not known how much code depends on the current behavior. Instead, the "setup scan" and "modify scan" commands now attempt to prevent the creation of record descriptions with invalid data in them in the first place. An additional consideration is that it is not enough that broken records are not added to the record list. Some of the core dumps were caused by attempts to invoke free() on invalid pointers. Thus, it must be made possible to ensure that one can safely deallocate memory that has been allocated on behalf of the broken record. However, due to present priorities, this fix must unfortunately be deferred to later. A minor change is that the code in the S10ID pseudomotor has been modified to ensure that the omega motor is always the last one commanded to start moving. Since the real theta motor and the insertion device gap motors do not perform backlash corrections, this allows the time spent waiting for the omega backlash correction to finish to overlap with the initial movement of theta and the insertion device gap pseudomotor. Version 0.18.9 (11/05/97): Added the ability to handle slit motors for the case where the positive directions for the individual slit blade motors are in opposite directions. Two flag variables have been added to the "motor" program called "overwrite" and "header_prompt". The command "set overwrite off" (which is the default) causes the "motor" program to prompt the user for permission to overwrite preexisting files with new datafiles. "set overwrite on" give one the old behavior where old datafiles were overwritten without any prompting. For the other new flag "header_prompt", the command "set header_prompt off" causes the "motor" program to not prompt for changes to the text header lines in SFF and XAFS format files. The contents of the text header lines will remain what they were before. This is primarily of use to scripts which also set "set plot off" so that the script can run unattended. You can have different defaults for these parameters by putting these lines in your startup file for "motor" called ~/.motorrc The MRCAT XAFS data file format now normalizes scaler channel output to counts per second. A "cd" command has been added to "motor" which allows one to change the directory that output files are being written to without exiting and restarting the program. However, the "motor.dat" and "scan.dat" files will still be written to the same directory that they were originally read from at program startup time. During execution of a "take" or "&" script, "motor" now sends a string like "$motor(0)\n" or "$motor(1)\n" at the end of output sent to the child process rather than "motor(1)" without a newline at the end. This should make the processing of output from "motor" simpler. Replaced several messages to the user with hopefully clearer alternative messages. In particular, the "Hit ctrl-D to abort setup" and "Coprocess has terminated" messages have been changed. "motor" now beeps at the end of a scan if plotting is turned on and at the end of an @command script in any case. "motor" has been modified to ignore the "ctrl-C" key rather than the previous behavior of abnormally terminating the program. Version 0.18.8 (11/02/97): A driver for Compumotor 6000 series stand-alone controllers has been developed that uses RS-232 for either a single controller or multiple controllers in a daisy chain configuration. 'mx_shutdown_hardware()' has been modified so that it starts at the last record in the record list and works its way back to the first record. This is to allow device and interface close() operations to occur in the reverse order of the open() operations. It is surprising that this problem hasn't come up before. More special tokens have been added to the SFF file format. They are '%motors' to list only the motors used in the scan, '%inputs' to list only the input devices for the scan, and '%integration_time' to display the integration time for the scan. "plotgnu" has been modified to include its process id in the name of its temporary file. This is to allow multiple copies of "plotgnu" to run at the same time, which can happen now that the "showplot" and "plot2ps" commands exist. Version 0.18.7 (10/14/97): "motor" now can be told to take commands from an external program. If you type "take commandname" or "&commandname", "motor" searches for an executable program named "commandname" and starts it up as a child process. In the child process, standard output (stdout) is redirected to the "motor" program command interpreter, while responses from "motor" are redirected back to the standard input (stdin) of the child process. This allows the child process to take over control of the "motor" program's operation, including moving motors, setting up and running scans, changing variables, etc. If the child process wants to directly interact with the user, it should open its own direct connection to "/dev/tty". In addition, when the child process exits, control returns to the original "motor" command prompt. In support of the above feature, the following features have also been added: 1. A "show field" command has been added to display the contents of individual record fields. 2. A "load record" command has been added. The part of the "motor" command line after the words "load record" are interpreted as a record description string using the same format as is found in the "motor.dat" and "scan.dat" files. This feature was added to make it easy for an external program to create a new scan record and then run the scan, since programming responses to the interactive "setup scan" command would make the job of the external program more difficult than necessary. At present, only scan records can be created in this way. 3. The "measure dark_currents" command now allows one to specify the integration time and number of measurements on the command line. For example, "measure dark_currents 1 10". A "showplot" command and a "plot2ps" command have been implemented. This allows the user to replot data in an old data file in either text format or SFF format. This should make it easier to routinely use SFF format files rather than headerless text files. The format of the "showplot" command is: showplot input_filename [ 'plot_arguments' ] while the format of the "plot2ps" command is: plot2ps input_filename output_filename [ 'plot_arguments' ] 'plot_arguments' uses the same format that is used for the Plot arguments prompt of the "setup scan" or "modify scan" commands. For example, 'log($f[1]/$f[0])' will plot the natural logarithm of the second scaler channel value divided by the first scaler channel. It is safest and best to enclose the plot arguments with single quote marks (') on the Unix command line in order to prevent the Unix shell from interpreting strings that begin with $ in an unexpected way. The EPICS PMAC dual ported ram driver has now been tested and appears to be working correctly. The 'set motor ... position' command is now implemented for EPICS motors that use the APS OMS VME 58 motor driver. The actual behavior of the EPICS motor record in response to this command depends on the setting of the EPICS record field '.FOFF'. If .FOFF is set to 1, a change in the user position will cause a change in the EPICS raw position, while if .FOFF is set to 0, changing the user position results in a change to the EPICS motor offset field instead. When written to a data file or during scan progress updates, the readback values of analog motors were having their scale and offset factors being applied twice. This has been fixed. If the last point of an XAFS scan region occurred at exactly the same energy as the first point of the next scan region, "motor" was putting both measurements into the data file. This has been changed so that if the last point of the current region is less than 0.01 eV away from the first point of the next region, the last point of the current region is not taken. This is to ensure that the energy value in an XAFS format file is always increasing in value from measurement to measurement. mx_motor_record_array_move_absolute() was not checking for keyboard interrupts while a move was in progress. This was the reason why moves to a start position could not be interrupted. This has now been fixed. Command names in "motor" may now be abbrieviated to the shortest length that uniquely distinguishes between commands. For example, one may type "sh m" rather than "show motors". It is no longer necessary to insert a space after the '!','@', '$', or '&' characters when used as commands. So now one can say "!ls -l" rather than "! ls -l". The SFF file format now allows one to specify a "%devices" token in the "sff_header_fmt" variable to allow the motors and input devices for a scan to be automatically written into the scan header. Any scan using the XAFS or SFF output format will now prompt the user for the contents of the header text fields at the time that the scan is started. For the XAFS format, three standard header fields 'xafs_header1', 'xafs_header2', and 'xafs_header3' will automatically be prompted for. For the SFF format, "motor" will start with 'sff_header1', 'sff_header2', and continue on until it discovers that the next record of the form 'sff_headern' does not exist. The descriptions of the different scan classes at the first prompt of the "setup scan" command have been improved to give the user more of an indication of what a "linear scan" or a "list scan" actually means. The "mjog" command has been enhanced with additional keystrokes available. Now, the '+' key will cause the motor to jog one jog unit in the positive direction, while the '-' key will cause the motor to jog one jog unit in the negative direction. Also, the '>' key will cause the motor to jog by 10 jog units in the positive direction, while the '<' key will cause the motor to jog by 10 jog units in the negative direction. The previous set of keystrokes, 'h','l', etc. still work, but '+' and '-' are thought to be more intuitive. The APS undulator gap motor drivers have been updated to reflect a change in the values that the EPICS undulator gap busy flag "ID$(xx):UN:busyBO.VAL" can have. Version 0.18.6 (09/16/97): Added support for controlling untapered APS undulator gaps as a motor through MX. Both the 'mm' and the 'keV' interfaces are supported. Support has been added for linking the undulator keV interface into the 's10id_motor' pseudomotor. Added support for controlling PMAC motors through Tom Coleman's EPICS dual-ported RAM interface. The 'energy_motor', 'wavelength_motor', and 'wavenumber_motor' pseudomotors have been updated to get the monochromator d spacing through a double MX variable that should normally be named 'd_spacing' although other names are possible. Version 0.18.5 (09/10/97): Added 'set debug' command to 'motor'. This allows the MX debugging level to be modified while the motor program is running. Added a new datafile type to MX called SFF (Simple File Format). Hopefully, I will come up with a better name later. SFF allows one to set the format of the files header by setting the value of a format string called 'sff_header_fmt'. While debugging the SFF file type, I discovered that the segment header function and the trailer function are apparently never being called. I will investigate this later. Renamed the 'run' function to 'exec' (although 'run' is left as an alias). Also added '@' as another alias to 'exec'. Added 'system' command that allows one to execute external commands from within motor. Added '!' as an alias to 'system'. Added a pseudomotor type called 's10id_motor'. This type is for experimenting with monochromator control algorithms at the APS Sector 10-ID beamline. Any general results from this experimentation will probably be folded into a more general motor type. For now, this type allows one to define another motor as a slave to a master motor. The position of the slave motor can either be a linear function of the master motor's position or a cubic function of that position. Version 0.18.4 (08/22/97): The new version of the XAFS scan record has been written. This version is a better match to the requirements of XAFS scans and should be used in preference to the old version. Command processing for the 'motor' program has been modified so that quoted strings are copied verbatim into a single argument. This allows for command arguments that have spaces in them. For example, 'set variable xafs_header3 "This is a test"'. Version 0.18.3 (08/18/97): The first significant addition in this version is the addition of 'set variable' and 'set field' commands to the motor program, which depended on the addition of an mx_get_token_parser() function to 'libmx/mx_field.c'. The other significant addition is a change in 'plotgnu/plotgnu' to prevent it from aborting if a math error occurs. Version 0.18.2 (08/15/97): Added 'delta_motor' pseudomotor. While this pseudomotor has multiple uses, its primary motivation is to allow for the definition of an 'E - E0' motor that can be used by the XAFS scan type to define the boundaries of XAFS scan regions before the edge in an edge energy independent manner. The XAFS scan type will expect this motor to normally be called 'e_minus_e0'. The current version of the XAFS scan type has now been modified to use the 'e_minus_e0' motor. This allows an XAFS scan that was defined for one absorption edge to be used for another absorption edge by just changing the value of the 'edge_energy' variable. Added an 'elapsed_time' pseudomotor. This pseudomotor maintains an internal time marker called 'time_of_last_reset' which is reset by commanding a move to an absolute position of 0 or less. After the marker is reset, then a move absolute command will interpret the specified position as a time, namely, the number of seconds since the last reset. In this case, the move absolute command will wait until this time has arrived before returning. Also, a get position command will return the number of seconds since the last reset. This implementation of an 'elapsed_time' pseudomotor is limited in resolution to integral numbers of seconds. The 'elapsed_time' pseudomotor is useful as an alternate to scaler scans, since during a motor scan of this pseudomotor, the X axis will be actual wall clock time rather than the 'live time' value you get with a scaler scan. The 'plotgnu' Perl script and the associated files 'libmx/p_gnuplt.c' and 'libmx/p_gnuxaf.c' have been rewritten to make far more efficient use of CPU time, which should speed up plotting in the 'motor' program. The Perl script is now written in the way that it should have originally been written, rather than stupidly requiring the entire dataset to be reprocessed essentially from scratch on each point. Implemented optional automatic subtraction of scaler dark currents. Improved the error messages for MM4000 motor controllers when either the motor driver power is turned off or the controller front panel menus are not at the top level of the menu tree. Improved the error messages for TCP232 connections that fail. Along the way, discovered and fixed an error in the handling of connect() attempts. Version 0.18.1 (08/01/97): An XAFS scan type has now been implemented. As part of this, the new pseudomotor XAFS_WAVELENGTH_MOTOR has been implemented. In addition a new plot type called 'gnuxafs' has been implemented in order to allow all the regions of an XAFS scan to appear on the same plot. An erroneous limit setting on the size of a scan step has been removed. The values of the motor positive and negative limits was being used directly for the limits, while the correct values are +-(positive_limit - negative_limit). Version 0.18.0 (07/11/97): Implemented a new record superclass called MXR_VARIABLE. This is a record superclass for storing things like absorption edge energy, scan header text, and so forth. As part of this work, the record field code was upgraded so that statically allocated and dynamically allocated field data values are handled more or less equally well. This involved straightening out some inconsistencies as to when it was necessary to invoke the function mx_read_void_pointer_from_memory_location() on the pointer value located at record_field->data_pointer. One restriction that has proven to be necessary is to prohibit the use of varargs field that have 0 dimensions (a scalar). However, it is perfectly possible to have a 1 dimensional array that has only one element instead, which is what I plan to do. Verified that "libmx" and "motor" still compile on Microsoft Win32 platforms. Only a few minor tweaks were required. Version 0.17.5 (06/24/97): Support for general segmented scan regions has been added. In the description that follows, "scan segments" and "scan regions" should be viewed as synonymous. Currently, not all operations on them that can be envisioned have been implemented, but a basic set that should be sufficient for now exists. The operations that have been implemented include: 1. Setup of a general segmented scan with a more or less arbitrary number of regions. 2. Copying of a segmented scan and its children as a group to a different name. The copying of individual children by themselves is not allowed. 3. Deletion of an entire segmented scan group or of one of the child regions. 4. Modification of an individual child scan region. 5. Modification of the segmented scan group as a whole. _However_, it is not currently possible to change the number of scans in a scan group or to change the scan type of an individual child scan. The raising of this restriction at some point in the future is likely. An MX driver for Delta Tau PMAC motor controllers has been written. Note that this particular driver only supports simple uncoordinated moves of individual PMAC motors using the jog mode commands. So far, this driver has only been tested using Tom Coleman's EPICS drivers for the PMAC-VME. The MX PMAC driver also contains some code for controlling a PMAC through its RS-422 serial interface. However, the RS-422 section of the code has not been tested with real hardware yet and thus is not likely to work without some further tweaking. A newer release of the MM4000 firmware (version 2.06) has been tested with the MX library. For this version of the firmware, the motor drivers are still turned off when a limit is hit, but it is now possible to turn them back on and command a move away from the limit under computer control. Also, the MX error code returned due to a Newport MM4000 controller response of 'TBD Execution not allowed' has been changed from MXE_ILLEGAL_ARGUMENT to MXE_DEVICE_ACTION_FAILED, since that seems to better reflect the situations under which it occurs. The driver for a 'translation_mtr' pseudo motor has been written. This pseudo motor moves a group of real motors in the same direction by the same amount. This allows things like tables with 3 supports to be moved up and down uniformly. Added the ability to automatically increment the file extension of any filename that looks like 'arbitrary_string.integer_number'. For example, after a scan has created the datafile 'test.017', the next time the same scan is run, the scan will write to the file 'test.018'. Record superclasses are no longer the bits in a bitmask. Leaving them this way would unnecessarily limit the number of possible record superclasses. The only functions that had to be modified to accomodate this change were mx_write_database_file() in "libmx/mx_rec.c" and motor_save_fn() in "motor/msave.c". 'set plot on' is now the default for 'motor'. A problem in 'motor' was found for the case of a scan with 'M' characters in its name was being copied to a scan name with 'N' characters in its name if M > N. Essentially, the last M-N characters of the old name were tacked onto the end of the new scan's name. This has been fixed. Did away with the 'cin' files, since having executable code in an include file is a bad idea. Version 0.17.4 (06/08/97): A bug was fixed in the handling of backlash corrections during scans, namely, the command to move to the desired position was being sent before the backlash correction was complete. The bug only affected motor moves where 'motor' was _not_ asking for a continuous display of the move while it was in progress. Thus, it affected the 'scan' command, but not the 'mabs' command. This bug should have shown up before now, but didn't somehow. This particular fix has a side effect on scans involving multiple motors. Namely, if a given motor has a backlash correction, the 'motor' program will wait until that backlash correction is complete before starting the next motor. This restriction will be lifted when the motor move functions are rewritten for the client/server version of this code. The 'mrcat' datafile type has been renamed to the 'xafs' datafile type. Correspondingly, the files 'f_mrcat.h' and 'f_mrcat.c' have been renamed to 'f_xafs.h' and 'f_xafs.c'. In addition, the newly renamed 'xafs' datafile type has been modified so that the monochromator energy is the only motor whose position is written to the datafile. Part of the support for segmented scans has been added. The main scanning routine has been written and a 'child' datafile type has been added to allow child scans to write their data to the parent's datafile. What remains is the adding of equivalent 'child' plot support and the user interface code for setting up a scan. If there had not been a need to release a bugfix for the backlash problem mentioned above, I would have waited until the segmented scan code was finished before releasing 0.17.4. As it is, the segmented scan code should be finished in 0.17.5. Version 0.17.3 (06/02/97): Added motors to the list of allowed input devices. The idea for this is to allow the actual position of the motors to be recorded in a data file as just another input device channel. Added support for slit scans. Scans were not waiting for the settling time to be over. This has been fixed. Version 0.17.2 (05/28/97): Support for list scans plus some of the code for segmented scans has been added. Fixed some bugs concerning the interaction with the Perl 'plotgnu' script. There were two main problems: 1) If the motor program aborted for some reason while plotgnu was active, plotgnu was not necessarily killed. This could result in the orphaned copy of plotgnu consuming large amounts of CPU time due to repeated attempts to read from its input pipe. This should now be fixed. 2) An error in the plotgnu program which caused it to abort would also cause 'motor' to be killed by a SIGPIPE the next time it tried to write to the plotgnu pipe. For now, the fix is for the 'motor' program to ignore the SIGPIPE signal. Version 0.17.1 (05/13/97): Support for plotting relatively arbitrary functions of the scan data has been added to the 'gnuplot' scan type. This now lets you plot things like log(I/I0). Note that most of the new gnuplot functionality is implemented by calling an external script written in Perl. This script uses only features from Perl version 4, so it should work with the versions of Perl that are distributed with systems like SGI. The 'motor_scan' scan type now supports multidimensional scans with, in principle, no fixed maximum as to the number of dimensions. In practice, the number of dimensions is currently limited by the length of record description string buffers. Hopefully, this will not be true forever. Found a bug in the MM4000 motor driver code, namely, the record scale and offset were never being used. This bug is now fixed. Two new commands have been added to 'motor': 'copy scan' and 'modify scan'. Regions of interest will be the next thing to be implemented. Version 0.17.0 (04/29/97): Development of the new scan code has reached the point where it is now possible to set up and perform "linear_scan"s within the new scan type framework. Implementation of regions of interest will be added in 0.17.1 or 0.17.2. Almost all of the infrastructure for it is present. All that should need to be written is the segmented scan driver itself. Also included are pseudomotors for slits, wavenumber, and wavelength. Version 0.17.pre2 (03/28/97): Implementation of new scan type support has reached the point where it is now possible to enter and then exit the 'motor' program and have the scan parameters be written out again correctly. This includes the reading and writing of MX_DATAFILE and MX_PLOT record fields. Thus, we are now to the point where scan record descriptions are being parsed correctly and the data structures are being set up correctly. The next step is to get the actual running of a scan working correctly including adding data to datafiles for multisegment scans and handling real time plotting of the data correctly for multisegment scans. It has become clear that there needs to be a distinction between the default values of a record field and the runtime values. Otherwise, it will not be possible to set the size of a dimension, for example, at runtime. For that reason, the structure type MX_RECORD_FIELD_DEFAULTS has been invented. The intention is that the contents of the MX_RECORD_FIELD_DEFAULTS are first modified by the "initialize_type" function at program startup and then are copied to each record's MX_RECORD_FIELD array when the record is created. Version 0.17.pre1 (03/09/97): Started implementation of new scan type support. The old MX_SCAN_1D scan types have been removed. Realized that for scan records, it may be convenient to have both a superclass level specific function list and a class level specific function list. Accordingly, entries for 'superclass_specific_function_list' and 'class_specific_function_list' have been added to the MX_RECORD structure. Other changes associated with this include: In the typedef of MX_TYPE_LIST_ENTRY in "libmx/mx_rec.h", replaced the field "specific_function_list" with the two fields "superclass_specific_function_list" and "class_specific_function_list". This requires corresponding changes to the entries in "libmx/mx_drivr.c". For all record superclasses except MXR_SCAN, the previous "specific_function_list" pointer was reassigned to the "class_specific_function_list" pointer. Type specific record fields should be defined in the header files for that type and not in the '.c' files. Fixed this for the couple of record field type records that currently exist. The function "mx_initialize_record_types()" already has a pointer to the MX_TYPE_LIST_ENTRY for a given record type when it invokes the type specific "initialize_type" function. That means that "mx_initialize_record_types()" can call the function "mx_setup_typeinfo_for_record_type_fields()" without the type specific "initialize_type" function needing to. Version 0.16.0 (03/04/97): In "libmx/i_scamac.c", discovered that the log file was never actually being opened. This mistake happened during the changeover to record field support. I don't know how this escaped notice up to now. Version 0.16.pre2 (02/28/97): In "libmx/i_tty.c", moved the calls to cfsetispeed() and cfsetospeed() to before the first call to tcgetattr(). Setting the serial port speed after the call to tcgetattr() was interfering with my test of whether serial port characteristics were set correctly. Under Unix, added command line argument processing using getopt(). This allows for the specifying of an alternate motor savefile or scan savefile. Porting this to other operating systems just means coming up with a version of getopt() for them. Version 0.16.pre1 (02/21/97): Renamed "mx_scan.h" and "mx_scan.c" to "mx_scn1d.h" and "mx_scn1d.c" respectively. This is a step along the path to more powerful scan support. In the new scan support, "mx_scan.h" and "mx_scan.c" will be the files to include the generic MX_SCAN superclass support, while MX_SCAN_1D will be one particular class of this superclass. Began work on adding new datafile type support to MX. Much of the basic structure is in place, although it will have to be modified somewhat when more advanced scan support is implemented. So far, a simple text datafile with no header has been reimplemented using the new methods. As it happens, the work on adding new datafile type support affects the Gnuplot plot display driver "libmx/p_gnuplt.h" as well. The Gnuplot driver had been relying on being able to do plots by just sending Gnuplot the command "plot 'datafilename'", where "datafilename" was the name of the current data file. With the new datafile type support, one can no longer rely on the current data file being in the correct format for Gnuplot. My solution to this is to write the current data to both the real data file and to a temporary file just for Gnuplot. That way Gnuplot always has a file in the right format to work with. This has the disadvantage of requiring more disk space for the temporary file, but the alternatives seemed even less desirable. Plan to reduce the number of arguments to scan and plot functions ( ideally to 1 argument ) by putting pointers to the necessary information in either the scan or plot structures. In this way, it is easier to write function interfaces that do not need to know that much about the details of the scan and/or plot in progress. Instead, they will hand off control to lower level record driver functions that will be responsible for knowing these details. "independent_variable" and "motor_position" are now part of the MX_SCAN_1D structure, so the scan function arguments that referred to them have been removed. Version 0.15.1 (02/16/97): Forgot to change savefile token "dev" to "device" in the file "libmx/d_mmx000.c" when writing a Newport MM4000's status out to a save file. This is now fixed. In "libmx/mx_field.c", the format strings for parsing and constructing signed and unsigned short fields were incorrect. In "libmx/d_qs450.h", the slot and subaddress fields were declared as ints, but the MX_RECORD_FIELD definition in "libmx/d_qs450.c" declared the field type to be MXFT_SHORT. On Linux, this worked anyway, but Solaris 2.5 doesn't let you get away with this. Solution: The definitions of the slot and subaddress fields in the header file "libmx/d_qs450.h" were changed to shorts. Did portability check by compiling on the other supported platforms. Version 0.15.0 (02/12/97): Record Fields: The initial stage of development of the record field support is now essentially complete. So far the support has been tested with the "camac_soft" CAMAC interface and "qs450" CAMAC scaler record types. I've been using the CAMAC device record types as my test bed since they are not critical to current operations. All of the datatypes I initially intend to support have been tested as well as multidimensional array support. Newport MM4000 and MM3000 Support: The Newport MM3000 and MM4000 motor controller driver is now complete and has been tested with Newport 850F DC servo motors on both controller types. It is possible that changes may be necessary for stepper motors (which haven't been tested), but I think it will work as is. I have found a way of coping with the MM3000's long delays in reporting hitting a limit that does not slow down normal operation. Newport reports that one can shorten this delay by disabling front panel display of error messages, but not eliminate it altogether. The Newport MM4000 controller has its own idiosyncracy with respect to hitting limits. If any MM4000 motor hits a limit, the MM4000 turns off motor power to _all_ the motors it controls. Further, it is difficult to move the motor off the limit under computer control, since the MM4000 keeps detecting that a limit is tripped and keeps turning off the motors on you. In practice, I have found that it is necessary to use the front panel manual jog buttons on the front of the MM4000 to get the motor off the limit. It would be possible to command the MM4000 to turn the motors back on automatically after a limit is tripped, but the controller apparently uses turning off the motor drivers as its way of handling faults other than just tripping limits, so automatically turning the motors back on might not be wise. It probably wouldn't help in getting the motor off the limit under computer control anyway. Other: Deleted 'interface_class', 'motor_type', 'scaler_type', etc. fields from the various record class structures, since the 'type' field in the MX_RECORD structure already contains this information. The only record that was making use of this to any extent was the CAMAC DSP QS450 and KS3610 scaler driver and all that was required to fix this was the replacement of the string 'scaler->scaler_type' with 'scaler->record->type'. Added 'record_superclass_struct', since some record superclasses may want a structure that applies to all members. Renamed the savefile tokens "int" and "dev" to "interface" and "device" respectively, since there's no advantage to abbreviating them when we don't abbreviate anything else. Modified the "initialize_type" record driver entry point definition to pass the record type of the record being initialized along to the "initialize_type" function. This allows one set of driver routines to be able to handle more than one record type. One example is the DSP QS450 and KS 3610 combined driver. Another example is the Newport MM3000 and MM4000 combined driver. In the "motor" program, renamed the global "record_list" to "motor_record_list". The primary reason for this was to flush out any lurking dependencies in the "libmx" code on the name of the record list being "record_list". As it turned out, there weren't any, which is good. In any case, the name "motor_record_list" better reflects the fact that it is a global specific to the "motor" program. Version 0.15.pre3 (01/23/97): Developed first version of Newport MM3000 & MM4000 driver. It is still using the old driver interface, since record field support is not yet ready for the task. The driver has successfully been used to move a Newport 850F linear actuator. It needs some further work to improve its response to error conditions, since the Newport MM3000 has some idiosyncracies in its error message handling that I need to find a way to work around. For example, if the motor hits a hardware limit switch, the first thing the MM3000 controller box does is make an audible beeping sound for about 1.5 seconds ( which is OK ). But the MM3000 doesn't send an error message down the RS-232 channel until after the audible beep is over. So, if the actuator trips a limit switch, the computer control program can't find out about it for about 1.5 seconds. This is _not_ OK. Things would be fine if the MM3000 always sent back an acknowledgement after each successful command, but for many commands, the MM3000 sends no response back whatsoever if the command succeeds. This poses problems for closed loop control using the MM3000. Hopefully, the MM4000 doesn't have this behavior or perhaps there is a way to turn the delay off. Put mx_create_record_from_description() into a new file called "libmx/mx_field.c". mx_parse_record_fields() and other record field support will go into this new file. The functions in it will still be prototyped in "libmx/mx_rec.h". Worked on mx_parse_record_fields() for parsing individual descriptor string items. Not done yet. Renamed MX_GENERIC_FUNCTION_LIST to MX_RECORD_FUNCTION_LIST and the various mxx_xxxx_generic_function_list's to mxx_xxxx_record_function_list. The immediate reason was my desire to create a new record class of generic serial interfaces to aid in handling devices that can be talked to both from RS-232 and GPIB (among other things). Also, this name is more in line with the naming style of the other function list structures. Changed function prototypes for read and write operations in mx_rs232.h, mx_gpib.h, and mx_gener.h to flip the order of the buffer argument and the length of buffer argument to match the order of the Unix read() and write() system calls. Making the prototypes more like read() and write() helps eliminate one more source of confusion. Version 0.15.pre2 (01/15/97): Added "mx_create_record_from_description()" as a MX_RECORD_FIELD oriented replacement for "mx_read_record_description()". Also modified "mx_read_database_file()" to use "mx_create_record_from_description()". Added several fields to MX_RECORD as discussed with Jonathan Schug: list_head - Pointer to MX_RECORD which is the head of the record list. superclass - A start towards cleaning up the terminology of what is a class, a type, etc. allocated_by - An MX_RECORD that has exclusively allocated the current record for its use. container_record_array, num_container_records - Lists all the container records that include this record. dependent_record_array, num_dependent_records - Lists all the records that use values from this record. The following is the implementation status of all the above fields: Finished: list_head Set to zero or NULL: all the rest. Split "initialize_record" in MX_GENERIC_FUNCTION_LIST into "create_record_structures" and "finish_record_initialization". Started work on implementing the code that uses MX_RECORD_FIELD structures. At present, MX decides whether to use MX_RECORD_FIELD algorithms or the old algorithms by looking at that record type's MX_TYPE_LIST_ENTRY. If either the "num_record_field" pointer is NULL, or the "record_field_array_ptr" pointer is NULL, then the old description parsing and displaying algorithms are used. The record type "camac_soft" that is implemented by the files "libmx/i_scamac.c" and "libmx/i_scamac.h" has been nominated as the first record type to undergo this conversion. Also started working on changing the old messed up "class" and "type" terminology to the new whiter, brighter terminology of "superclass", "class", and "type". Most (all?) of these changes so far have been in "libmx/mx_rec.h", "libmx/mx_rec.c", "libmx/mx_drivr.c", "libmx/i_scamac.h", and "libmx/i_scamac.c". "Motor" program: The "setup scan" command has been modified to be able to use GNU Readline, just like the main command prompts do. This way, editing of already entered characters will work more sensibly. Version 0.15.pre1 (01/07/97): WML - Started adding features in support of network I/O and to simplify ASCII record file handling. Added to libmx/mx_rec.h: MX_RECORD_FIELD and MX_PROCESS_FUNCTION. Also additions to MX_RECORD and MX_TYPE_LIST_ENTRY in support of the record field entries. "record_data" field in MX_RECORD renamed to "record_class_struct". "device_data" and "interface_data" fields in MX_MOTOR, MX_SCALER, etc. renamed to "record_type_struct". Version 0.14.4 (12/26/96): WML - First release to internal users.