Current Tasks for MX

Performance optimization

• A lot of benchmarking and profiling needs to take place first.
• The monochromator pseudomotor is known to be slow.

MxTcl package upgrade

• MxTcl is currently statically linked to the rest of Tcl/Tk and [incrTcl].
• The Tcl/Tk developers are moving towards only supporting dynamically loaded modules.
• MxTcl cannot be built on RedHat Linux 7.2 and 7.3 using the vendor provided versions of Tcl/Tk and [incr Tcl].
• We cannot yet do away with the Tcl/Tk applications.
• I need to spend a few days figuring out how to make MxTcl a dynamically loaded module.

MX network transport changes

• Automatic reconnection of client connections to servers.
• Make sure that client-server network I/O is always non-blocking on both ends.
• Use numerical handles rather than looking up the record by name all over again on each message.

MX server restructuring

• Much of the MX server code is in the form of event handlers for MX network messages.
• Split this event handling code out into a libMxEvent library.
• This split will make it much easier to embed the libMxEvent code in an alternate server or even a client.
• Add value changed callback support.

Using libMx in an EPICS server.

• In beta versions of EPICS 3.14.0, the EPICS iocCore code has been ported to run under Linux, Solaris, Win32, and RTEMS.
• All previously existing EPICS device support only works under under vxWorks.
• It might be relatively straightforward to embed libMx into EPICS iocCore.
• My initial plan would be to have the EPICS code treat the libMx library as if it were an unusual motor controller.
• It may be better to make use of the future libMxEvent library as a front end to libMx.
• This will require some more thought and discussion with the EPICS people.

XIA MCA work

• What should happen next?

Rigaku MSC robot interfacing for IMCA-CAT