Current Tasks for MX
- 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
- 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
- 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
- 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
Rigaku MSC robot interfacing for IMCA-CAT