Transient Scan ID: 17 Time: 2019-10-23 18:00:49
Persistent Unique Scan ID: '00106dc8-d666-4cad-a07b-5c239fd2e564'
New stream: 'baseline'
New stream: 'primary'
/tmp/test_new_stuff/bin/python: relocation error: /tmp/test_new_stuff/lib/python3.7/site-packages/PyQt5/Qt/plugins/platforms/../../lib/libQt5DBus.so.5: symbol dbus_message_get_allow_interactive_authorization, version LIBDBUS_1_3 not defined in file libdbus-1.so.3 with link time reference
(/tmp/test_new_stuff) [xf23id1@xf23id-ws2 ~]$
ipython3 in order to get python version 3.....
Hello, I tried to install bluesky for trial use. But it seems that databroker cannot be installed with python3.8. Is python3.8 not supported for bluesky yet?
----->
(bluesky-tutorial) username@host[1007]$conda install -c lightsource2-tag bluesky ophyd databroker ipython matplotlib
Fetching package metadata ...............
Solving package specifications: .
UnsatisfiableError: The following specifications were found to be in conflict:
- databroker
- python 3.8*
Use "conda info <package>" to see the dependencies for each package.
I read bluesky tutorial on https://nsls-ii.github.io/bluesky/tutorial.html
and then I would like to try the case to use bluesky
with our control system at SPring-8(unfortunately not EPICS).
In this case, I may need to customize ophd in https://nsls-ii.github.io/ophyd/
I would appreciate if I can reffer some simple examples for
read/set with ophyd without EPICS.
As I was playing around I also noticed there's a required order to messages (eg. 'create' must be sent before 'save'). I'd like to learn more about these protocols if possible
Msg is used to do dispatch inside the RunEngine and it is possible to register additional commands
Hello! It seems that when I attempt to install bluesky and associated packages using conda, the installation fails because of package conflicts. Using pip works fine, but I'd prefer not to use pip together with conda if possible. Any suggestions on how to get this working for conda? Output posted below:
$ conda install -c lightsource2-tag bluesky ophyd databroker
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: /
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abort.
failed
UnsatisfiableError: The following specifications were found to be incompatible with each other:
Package networkx conflicts for:
ophyd -> networkx
Package msgpack-numpy conflicts for:
databroker -> msgpack-numpy
bluesky -> msgpack-numpy
Package boltons conflicts for:
databroker -> boltons
Package ipython conflicts for:
bluesky -> ipython
Package six conflicts for:
databroker -> six
Package databroker conflicts for:
bluesky -> databroker
Package numpy conflicts for:
databroker -> numpy
bluesky -> numpy
ophyd -> numpy
Package suitcase-msgpack conflicts for:
databroker -> suitcase-msgpack
Package glueviz conflicts for:
databroker -> glueviz
Package pyyaml conflicts for:
databroker -> pyyaml
Package msgpack-python conflicts for:
databroker -> msgpack-python
bluesky -> msgpack-python
Package super_state_machine conflicts for:
bluesky -> super_state_machine
Package lmfit conflicts for:
bluesky -> lmfit
Package ophyd conflicts for:
bluesky -> ophyd
Package event-model conflicts for:
databroker -> event-model[version='>=1.11.1']
bluesky -> event-model[version='>=1.10.0']
Package pandas conflicts for:
databroker -> pandas
Package suitcase-mongo conflicts for:
databroker -> suitcase-mongo
Package doct conflicts for:
bluesky -> doct
databroker -> doct
Package intake conflicts for:
databroker -> intake[version='>=0.5.2']
Package pyepics conflicts for:
ophyd -> pyepics
Package ujson conflicts for:
databroker -> ujson
Package attrs conflicts for:
databroker -> attrs[version='>=16.3.0']
Package jsonschema conflicts for:
databroker -> jsonschema
Package toolz conflicts for:
databroker -> toolz
bluesky -> toolz
Package pims conflicts for:
databroker -> pims
Package cycler conflicts for:
bluesky -> cycler
Package xarray conflicts for:
databroker -> xarray
Package vs2015_runtime conflicts for:
python=3.7 -> vs2015_runtime[version='>=14.16.27012,<15.0a0']
Package tqdm conflicts for:
bluesky -> tqdm
Package matplotlib conflicts for:
bluesky -> matplotlib
Package sqlite conflicts for:
python=3.7 -> sqlite[version='>=3.25.3,<4.0a0|>=3.26.0,<4.0a0|>=3.27.2,<4.0a0|>=3.28.0,<4.0a0|>=3.29.0,<4.0a0|>=3.30.1,<4.0a0']
Package pip conflicts for:
python=3.7 -> pip
Package pytz conflicts for:
databroker -> pytz
Package tornado conflicts for:
databroker -> tornado
Package humanize conflicts for:
databroker -> humanize
Package tifffile conflicts for:
databroker -> tifffile
Package historydict conflicts for:
bluesky -> historydict
Package dask conflicts for:
databroker -> dask
Package jinja2 conflicts for:
databroker -> jinja2
Package zict conflicts for:
bluesky -> zict
Package pymongo conflicts for:
databroker -> pymongo
Package tzlocal conflicts for:
databroker -> tzlocal
Package cytoolz conflicts for:
databroker -> cytoolz
Package h5py conflicts for:
databroker -> h5py
Package pyzmq conflicts for:
bluesky -> pyzmq
Package zarr conflicts for:
databroker -> zarr
Package requests conflicts for:
databroker -> requests
Package mongoquery conflicts for:
databroker -> mongoquery
Package openssl conflicts for:
python=3.7 -> openssl[version='>=1.1.1a,<1.1.2a|>=1.1.1b,<1.1.2a|>=1.1.1c,<1.1.2a|>=1.1.1d,<1.1.2a']
Package vc conflicts for:
python=3.7 -> vc[version='14.*|>=14.1,<15.0a0']
nsls2forge. I believe old lightsource2-tag channel is essentially deprecated at this point, though it is difficult to know how to communicate that to users. (I don't think we want to delete it.) Did some documentation lead you to lightsourc2-tag? Is so please let me know where, and I will update it.
lightsource2-tag is deprecated and originally was aiming to the linux-64 arch, and a few packages for OSX were added manually there. The old system was too poor to manage and scale as it was the "multiple packages per repo" approach, and we didn't have a way to build packages for Windows. With nsls2forge we completely changed the packaging approach, and now reuse the conda-forge approach of "feedstocks", allowing us to build one package per repo, and, where possible, we use the "noarch" packages, allowing to install a package on any platform and Python version (with some exceptions). Also, if a package is platform-dependent, we build it for all 3 platforms when possible (Linux, OSX, Windows). So, to install the software on Windows, you would need to use nsls2forge as @danielballan suggested, or create a blank conda environment, and install everything from PyPI using pip. Please let us know if you have any questions or problems with the installation
'stage1:x', 'stage1:y', 'stage2:x', 'stage2:y'
from ohpyd import Device, Component as Cpt, EpicsMotor
class MyStage(Device):
x = Cpt(EpicsMotor, ':x")
y = Cpt(EpicsMotor, ':y')
stage1 = MyStage('stage1', name='stage1')
stage2 = MyStage('stage2', name='stage2')stage1.read() (or pass it into the dets list of a plan) to read the stage as a whole or stage1.x to access just the x motor on that stage
In the example you provided, you never had to provide a device address or anything - so how does bluesky (or ophyd or epics) know which physical device is which?
time.sleep() because most people use from time import sleep in the name space or they could sleep = bps.sleep or some other crazy thing is changed to sleep.