Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to load custom labware with opentrons_execute #9256

Closed
mattwelch opened this issue Jan 14, 2022 · 4 comments · Fixed by #13074
Closed

Unable to load custom labware with opentrons_execute #9256

mattwelch opened this issue Jan 14, 2022 · 4 comments · Fixed by #13074
Labels
api Affects the `api` project bug robot-svcs Falls under the purview of the Robot Services squad (formerly CPX, Core Platform Experience).

Comments

@mattwelch
Copy link

A user notes that he is unable to load custom labware with opentrons_execute in ssh.

Original report:

A user was "try and run a protocol from the command line using a custom labware file, and was using a simple protocol to test out the functionality (see attached protocol and custom labware file). The command used to execute the protocol and use the custom labware file: opentrons_execute /data/user_storage/Customlabwareexecution.py -L /data/user_storage (the location of abgene_96_wellplate_330ul.json). Running this command throws an Unable to find a labware definition for "abgene_96_wellplate_330ul", etc. error. Interestingly, when running opentrons_simulate /data/user_storage/Customlabwareexecution.py -L /data/user_storage, it simulates with no issues. We have looked over the formatting of the json, tried a number of different custom labware directories, etc., but no luck with opentrons_execute."

This is similar to #7134, except this one shows execute not working and simulate working, where as 7134 shows simulate not working

@mattwelch mattwelch added bug robot-svcs Falls under the purview of the Robot Services squad (formerly CPX, Core Platform Experience). labels Jan 14, 2022
@bryanliujiang
Copy link

I was able to circumvent this issue by manually making the folder labware in /var/lib/jupyter/notebooks/ and dumping all my custom labware definitions there. From there I could run opentrons_execute PROTOCOL without the -L option.

I found this by browsing around labware path definitions here while investigating the opentrons_execute source itself. I also briefly scanned to see why the custom labware error doesn't come up when running opentrons_simulate, but its source for calling the path looks identical. Some deeper issue might exist that's causing this problem.

@kcorreia
Copy link

kcorreia commented Aug 3, 2022

I wasn't able to get this to work because I don't use jupyter. I prefer to just use a terminal window.

  • transfer files to /data/user_storage/labware/ on OT2
  • load with the function below by specifying the file_path and location on the deck
def load_custom_labware(file_path,location):
	with open(file_path) as labware_file:
		labware_def = json.load(labware_file)
	return protocol.load_labware_from_definition(labware_def, location)

@bryanliujiang
Copy link

I also don't use jupyter and prefer the terminal window, but thought it was strange that custom labware could only be recognized on my particular OT-2 if I had placed the definitions in a jupyter directory that I never directly access. The upside with this way though is that one wouldn't have to load/maintain the additional load_custom_labware() in their protocols, but whatever works!

@kcorreia
Copy link

kcorreia commented Oct 5, 2022

Sounds like a better idea. What is the directory you use?

./run/jupyter
./run/systemd/units/invocation:jupyter-notebook.service
./var/lib/jupyter
./usr/share/jupyter
./usr/lib/python3.7/site-packages/jupyter.pyc
./usr/lib/python3.7/site-packages/jupyter_core-4.4.0-py3.7.egg-info
./usr/lib/python3.7/site-packages/jupyter_core
./usr/lib/python3.7/site-packages/jupyter_client-5.2.4-py3.7.egg-info
./usr/lib/python3.7/site-packages/nbconvert/tests/files/jupyter_nbconvert_config.pyc
./usr/lib/python3.7/site-packages/jupyter_client
./usr/lib/python3.7/site-packages/nbformat/tests/test4jupyter_metadata.ipynb
./usr/bin/jupyter-notebook
./usr/bin/jupyter-kernelspec
./usr/bin/jupyter-nbextension
./usr/bin/jupyter-migrate
./usr/bin/jupyter
./usr/bin/jupyter-nbconvert
./usr/bin/jupyter-run
./usr/bin/jupyter-trust
./usr/bin/jupyter-serverextension
./usr/bin/jupyter-bundlerextension
./usr/bin/jupyter-kernel
./etc/jupyter
./etc/jupyter/jupyter_notebook_config.py
./etc/systemd/system/jupyter-notebook.service.d
./etc/systemd/system/opentrons.target.wants/jupyter-notebook.service
./etc/systemd/system/jupyter-notebook.service
./sys/fs/cgroup/devices/system.slice/jupyter-notebook.service
./sys/fs/cgroup/systemd/system.slice/jupyter-notebook.service
./sys/fs/cgroup/unified/system.slice/jupyter-notebook.service

@SyntaxColoring SyntaxColoring added the api Affects the `api` project label Jul 10, 2023
SyntaxColoring added a commit that referenced this issue Jul 11, 2023

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
…data (#13074)

* Fix a bug where the `--custom-labware-path` (`-L`), `--custom-data-path` (`-D`), and `--custom-data-file`) (`-d`) arguments to `opentrons_execute` had no effect. This closes #9256.
* In the `--help` text, clarify how `--custom-labware-path` (`-L)` affects the default behavior of searching the current working directory.
* Refactor: Remove some unnecessary `getattr()` calls to read attributes that should always be present.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Affects the `api` project bug robot-svcs Falls under the purview of the Robot Services squad (formerly CPX, Core Platform Experience).
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants