search

mxcube / mxcubeweb

MXCuBE-Web
http://mxcube.github.io/mxcubeweb/
GNU Lesser General Public License v3.0
20 stars 37 forks source link

How to deal with Hardware Object classes that don't have an adapter? #1260

Closed HilbertCorsair closed 4 days ago

HilbertCorsair commented 1 week ago

In the file mxcubeweb/core/util/adapterutils.py there is the funtion get_adapter_cls_from_hardware_object(). This function takes a hardware object and returns either the appropriate addaper or None. In our case I noticed a lot of important hardware objects (such as Smargon.Smargon, our PX1 diffractometer, RedisMpegVideo, SampleView, QueueModel, QueeueManager and others) for which this function can't find a match for their class and thus returns None. What is the best way to deal with this issue? 1 - Creating a special adapter for each class then changing the above mentioned function to check for these new clases 2 - Changing the inheritence of the specific HO such that it becomes an instance of a class within the scope of the get_adapter_cls_from_hardware_object() function. This is what I tried so far although it feels a bit like a hack. This is how I managed to get the diffractometer and some of the diffractometer.motor HOs "connected" to the Beamline. The results so far are mixed, there are motors for which the function returns teh wrong adaprer resunling in pydantic validation errors but perhapes it could be a tactic that can be improved. These are my main ideas for integrading our Specific HardwareObjects into the Beamline object. This is in the context of the old configuration via xml files and I'm aware that whatewer fix we find in this context is temporary until we develop the new yaml configuration. This hints at a third posibility : 3 - Leaving the current branch aside and moving to a new branch to develop the appropriate pydantic models, addapters and yml configuration files. This does't feel like the best approach if I want to have a working version of the MxcubeWeb App at PX1 as soon as possible. Pleas share your ideas and suggestions, I'm pretty shure there might also be somthin I missed. Thank you @jbflo for your help with this issue.

jbflo commented 5 days ago

Hi @HilbertCorsair I think approach 2 is the correct way to move on. Continue on that side, adjust your specific Hardware object and config. you are not far from getting it to work :wink:.

beteva commented 5 days ago

Hi, the best, if you can, is to revamp your HardwareObject, so it corresponds to already existing adapter. E.g. motorised device with finite number of positions can inherit from AbstractNState.

marcus-oscarsson commented 5 days ago

The adapter objects in mxucbe-web "adapts" or translates the HardwareObjects to the "web world", meaning that certain attributes are serialized, signals are sent over web sockets and so on.

All the standard HardwareObjects in mxcubecore already have an adapter so its very likely that you can use one of those. The adapter for a HardwareObject is selected based on its abstract class, so simply inheriting the right abstract class should solve your issue.

Certain objects like QueueManger, QueueModel and SampleView are handled natively by mxcube-web. The idea/philosophy was that everybody has/wants a queue and a sample view and those are thus more or less hardwired from mxcubecore to mxcubeweb. That is why there is no adapter for those objects.

From what I can see above the only object in the list the only object that would need a adapter is the diffractometer and that adapter already exists. I imagine that the smargon is your goniometer and is accessed via the diffractometer.

marcus-oscarsson commented 4 days ago

I take it that we can close this issue now, please feel free to re-open it if needed