@danielballan Thanks! I did not know about this option. A small hurdle is that my module is not installed...and not really structured to be a proper package. I suppose pip install -e . could be used temporarily though.
In the interim, Dylan has pointed me to a FITS handler that is ready to be installed. I will give that a try next.
import types
import sys
my_module = types.ModuleType('my_module')
my_module.FitsHandler = FitsHandler
sys.modules['my_module'] = my_module
from my_module import FitsHandler as _FitsHandlerUPDATE: Databroker is now using the FITS handler that Dylan shared with me
Hooray!
I ended up needing to rewrite the stored data (ummm, 'datum's?) with "frame_per_point" passed as a keyword argument when creating the resource. Otherwise extract_shape() would raise RuntimeError(f"Could not figure out shape of {key}") for key="ccd", even though the shape is explicitly set in the event descriptor.
This is the relevant section where the documents are being generated from existing data...
...
descriptor_keys['ccd']['shape'][0] = sample_fits['Images'].data.shape[0]
descriptor_keys['ccd']['shape'][1] = sample_fits['Images'].data.shape[1]
primary_stream_bundle = run_bundle.compose_descriptor(
data_keys=descriptor_keys,
name=primary_stream_bundle_name)
yield 'descriptor', primary_stream_bundle.descriptor_doc
...It looks like extract_shape() might not be expecting the simple case of descriptor['data_keys'][key]['shape'] already defined correctly; so it raises an exception instead of simply returning return descriptor['data_keys'][key]['shape']?
This is probably just my ignorance of databroker in general (and extract_shape() in particular), but I'm curious whether you see this as an issue in the logic of extract_shape()?
I finally managed to get debug information on the recursion condition. It appears that the recursion loop is caused by
intakeforcing a reload of information every time it checks the property/attribute of an Entry/Catalog.
It turns out that the inifite recursion I was experiencing (see my post from Jan. 11) was related to an outdated (and beta) version of databroker / its dependencies. Upgrading to databroker 1.2.0 fixed this problem. Thanks, Dylan!
It seems strange that conda pulled databroker 1.0.0b9 on 2021-01-05, when issuing the following commands.
conda create --name fits-env python=3.8 pandas astropy requests event-model suitcase-mongo -c lightsource2-tag
conda activate fits-env
conda install conda-build
conda install -c nsls2forge databroker
conda install scikit-imageJust to clarify, databroker now works as expected. I'm posting this simply for informational purposes.
HI @ksubrama_gitlab
Yes, spaces in paths was a problem that we found and fixed on master of yaqd-control (needed to be quoted in a subprocess call):
https://gitlab.com/yaq/yaqd-control/-/blob/master/CHANGELOG.md
I thought we had done a release since then, but apparently not (I think we have one other thing that we were planning on putting in the release, that just kept getting bumped down the priority list)
Anyway, I pinged you on our matrix channel if you want to talk more.
anywho https://matrix.to/#/#yaq:matrix.org?via=matrix.org
you came to this chatroom in the past, with username selfification
To get the entry points they do need to be installed. yaqd-control is more for production machines than dev (though it can be useful in some dev circumstances)
for dev work I tend to just run the entry point directly in a terminal e.g. $ yaqd-horiba-micro-hr -v (-v to get verbose outputs)
that prints logs to stderr so I can see what is going on.
you can install in editable mode to be able to make changes without having to re pip install every time
flit install --pth-file (or on systems like linux/mac that have symlinks flit install -s)
yaqd edit-config horiba-micro-hr will open up notepad (or actually whatever is in $EDITOR) with that file directly
I don’t think we have set up a DOI for the project itself (via e.g. Zenodo). Here is a paper that people cite: https://www.tandfonline.com/doi/full/10.1080/08940886.2019.1608121 (DOI: https://doi.org/10.1080/08940886.2019.1608121)
credit to mrakitin on the slack for answering a similar question a week ago
Hi, Bluesky mates. The following code:
ThetaS = EpicsMotor('31a:DCM:ThetaS', name='ThetaS')
print('ThetaS position', ThetaS.position)
will cause exception DisconnectedError:
Traceback (most recent call last):
File "ztest_ac.py", line 69, in <module>
print('ThetaS position', ThetaS.position)
File "/home/chiang.lc/anaconda3/envs/py37bluesky/lib/python3.7/site-packages/ophyd/utils/epics_pvs.py", line 200, in wrapper
raise DisconnectedError('{} is not connected'.format(self.name))
ophyd.utils.errors.DisconnectedError: ThetaS is not connected
In the same environment, I can use pyepics module ( motor = epics.Motor('31a:DCM:ThetaS') ) to move the motor and to read its position without any problem.
Would you please provide hints for debugging and finding causes?
print('ThetaS.read()', ThetaS.read())
ophyd.utils.errors.DisconnectedError: ThetaS is not connected
suitcase.csv.export will raise exception ValueError: I/O operation on closed file.
The 'export' does successfully create and write to a csv file though.
Full code and error message: https://pastebin.com/tCsTZPqj
