Skip to content

meguiraun/mxcube3

This branch is 850 commits behind mxcube/mxcubeweb:master.

Folders and files

NameName
Last commit message
Last commit date
Apr 4, 2016
May 2, 2018
Feb 9, 2018
Sep 30, 2017
May 4, 2017
Dec 15, 2017
Jun 19, 2017
Sep 17, 2015
May 22, 2017
Jun 19, 2017
Nov 28, 2017
Dec 12, 2017
Aug 22, 2017
Jun 30, 2017
Mar 12, 2018
Nov 7, 2017
Nov 28, 2017
Apr 24, 2018
Apr 24, 2018
Mar 14, 2018

Repository files navigation

MXCuBE 3 (web)

MXCuBE stands for Macromolecular Xtallography Customized Beamline Environment. The project started in 2005 at ESRF, since then it has been adopted by other institutes in Europe. In 2010, a collaboration agreement has been signed for the development of mxCuBE with the following partners:

This version corresponds to the web-based interface (aka MXCuBE 3), currently under development. Although it shares the code that talks to equipment with the original version. The original project is based on Qt (Qt3 initially but moving to Qt4), see the main repository.

Latest information about the MXCuBE project can be found in the project webpage.

Technologies in use

For the backend we are using Python-flask as the microwebframework, with the SocketIO library for handling internal messages of the Hardware Objects (see below). The web server tries to provide to the client a Rest like api. See here for the documentation.

And for the client interface a react based development, configured through webpack for an easy developemnt. Among others, we are also using socket-io and bootstrap.

HardwareObjects

As the Qt version, the Hardware objects are self-contained pieces of software code with links to the underlying instrumentation control software. Their purpose is to provide a way for an application to interact with an instrument (e.g. sample changer) or motor (e.g. monochromator rotation axis). It is common for one hardware object to interact with more than one piece of underlying control software in order to implement a workflow which uses multiple hardware components or procedures. There are methods for creating hardware objects which are configured using eXtensible Markup Language (XML) files loaded through a server. Only one instance of a hardware object runs for a given piece of instrumentation and this instance is available to handle requests made by other hardware objects or bricks. A hardware object provides a Python application programming interface (API) and handles asynchronous communication between other hardware objects by emitting signals.

For the web development we are using the branch 2.1, as well as a set of HardwareObject mockups so no real hardware is needed, repository.

Installation and testing

Follow the instructions here

About

MXCuBE 3 (web)

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • JavaScript 67.2%
  • Python 29.1%
  • CSS 3.4%
  • Other 0.3%