Closed stuwilkins closed 6 years ago
@stuwilkins I am a little confused. Why are the files in ../startup
no longer numbered? Are we going to hope alphabetical order is enough to always keep things running in the correct order?
I also cannot find the tardis setup. Did you leave that out on purpose or can I simply not find it? I've looked in ../ophyd/devices.py and /startup/endstation.py.
@ambarb
Thanks! I was thinking that we will define in __init__.py
from .detectors import *
from .accelerator import *
so that we have better control over the imports. This way, our profile would be:
from nsls2tools.csx1.startup import *
Only!
I didn't add the tardis yet as it was all commented out.
Nice idea to import it.
Are you looking at 98-tardis-mu.py? This is the one we use and these things are in sd.baseline
so they have to be defined.
Thanks, just added. I was confused by 98 and 99 ... anyway it is in now.
@danielballan @tacaswell @stuartcampbell
Is this what you were thinking when we discussed this with @ambarb a while ago in the conference room?
@ambarb if you are in, lets try and get this done Tuesday AM and see if it works, if it does then this is a model for SIX......
Sounds good. I was able to get fix some of our custom plans so that the header information is populated. Just need to fix the plot scaling. I will need some help from DAMA with that because I don't know how to pass that variable to bec
. @stuartcampbell can someone help me with this tomorrow?
Someone should be able to helpout... @danielballan @licode is one of you available ?
I really like how this is looking. I'm wondering whether the subpackages bluesky
, ophyd
, and analysis
, are the organization we want to go with long term. I can imagine some cases where things might not fit neatly into just one. Would it be better to move all those modules in the top level (csx
) package? No strong feelings here -- just brainstorming.
I think it does make sense to have a startup
subpackage so that we can from nsls2utils.csx1.startup import *
.
Thanks @danielballan
I was thinking that perhaps the distinction should be devices and plans rather than the actual package names? What do you think.
I like the idea of separating the locations of these things
I almost made that exact suggestion myself. Let's go with that.
Get Outlook for iOShttps://aka.ms/o0ukef
On Wed, Sep 27, 2017 at 6:02 PM -0400, "Stuart Wilkins" notifications@github.com<mailto:notifications@github.com> wrote:
Thanks @danielballanhttps://github.com/danielballan
I was thinking that perhaps the distinction should be devices and plans rather than the actual package names? What do you think.
I like the idea of separating the locations of these things
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/NSLS-II/nsls-ii-tools/pull/8#issuecomment-332668621, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACLIrndJ4IO_euWQ7eTW_dPu6j4G2XD2ks5smsXwgaJpZM4Pi99d.
@stuartcampbell @danielballan
This is now a fairly stable config for CSX. I think it is ready for review comment. Could someone take a look. I am keen for this not to be some monster PR as well!
Haha, too late! But sometimes monster PRs are necessary -- the goal now should be to merge this promptly. I'll take a look.
Add a logic test to the fccd configuration attrs to determine if the actuator for dark images is in or out.
This content will be moved into csxtools and/or back to the IPython profile.
@stuwilkins Do you think a *tools repo for your program would be useful, or is it better to put things either in csxtools, sixtools, or scikit-beam?
This has moved back to the CSX program for now.
Attn @ambarb @wen-hu @cmazzoli
This is the initial cut from the profile directory into this structure. I would like to review all that is in here and see what can be replaced / refactored and what is obsolete.