Implement ParameterTree for FR adapter

[GDYendell]

No description provided.

[GDYendell]

This should just work with the new generic OdinDataAdapter. Check this.

[GDYendell]

@jsouter did you do this while working on DiamondLightSource/fastcs-odin#33?

[jsouter]

I changed the templated odin_server.cfg files to use OdinDataAdapter instead FrameReceiverAdapter, no changes were required to odin-data's fastcs-dev branch. There's a few places where frame_receiver_adapter.py is broken (I think I got it to run by just changing self._endpoints to self._controller._endpoints, but I didn't properly check if it's functional besides that). I figured frame_receiver_adapter.py would be deleted.

[GDYendell]

That is pretty much all I did for the meta writer so that may be all that is required.

[jsouter]

Here is the diff of a branch I made that makes OdinDataController generic, and makes subclasses for FrameProcessorController and FrameReceiverController (which is actually an alias for the base OdinDataController), and FrameReceiver(/Processor)Adapter classes that use these controllers.

This would mean we could still use the existing odin_server.cfg's module paths without having to specify a frame_processor flag.
If we'd rather keep fastcs-dev as it is, I can make a PR to just delete frame_receiver_adapter.py as OdinDataAdapter makes it redundant.

fastcs-dev...jsouter:odin-data:controllers

[GDYendell]

I think I would like to see that diff as PR to fastcs-dev for discussion.

Do we understand why the fr check is commented out, currently? @ajgdls?

[jsouter]

Okay, PR here https://github.com/odin-detector/odin-data/pull/362/files

[ajgdls]

The check was never implemented during development of the new version of the Odin data classes. What is commented out there is a stub which needs an implementation to check on availability of buffers from the FR. I'm not sure if it can simply be an exact copy of the previous version, which is why it was not copied over.

[ajgdls]

Oh sorry, for some context... In the previous version of the frame processor adapter, the FP adapter would connect to and check the number of free buffers according to the FR adapter. It would test this against a defined threshold and refuse to send the command to start writing if the check failed.
The idea was to give prior warning if the system was being starved of buffers rather than allowing it to start and then potentially fail quickly.

[GDYendell]

Completed in #362. Added #364 for further work.