Closed cmazzoli closed 6 years ago
That's possibly somehow related the the second bsui
started after the first one was stopped with Ctrl+Z. Just a guess...
@tacaswell, thoughts?
Not sure, but I would guess you have two separate instances of NanoBundle. RunEngine will cache results with a dictionary indexed by object (It could also just be the name string, I cannot recall right now, but I really think it was the actual object itself) My guess is if it recognizes a new object that's not the same, it will try to cache a new element in the dictionary, and in doing so will see colliding keys. I would look into that.
I am wondering if it is something deeper which might involve this disconnect logic here: https://github.com/NSLS-II-CSX/xf23id1_profiles/commit/756d53b7492c9a609651a5ef752cf68311c7c29f#diff-b8b6535fb5ab4adb58462bc8b158c90aR87
@tacaswell ?
You almost certainly have two instances of the nanop
in dets
, this is the expected and correct behavior.
This is not related to having more than one bsui
running at the same time as they are different processes so can not talk to each other. I am very doubtful that this is related ripping the signals off.
@cmazzoli the fix is to make sure you do not have more than one instance of nanop in dets
.
After discussion with @cmazzoli the problem is re-running this file: https://github.com/NSLS-II-CSX/xf23id1_profiles/blob/master/profile_collection/startup/02-nanops.py#L122
they won't re-run the file
Dear all, thanks for the help and the precious comments. Here we have a couple of questions and a procedure to develop, then. First of all, we edit files and re-run/edit them all the time (DAMA people coming on the beamline do the same..). This is done WITHOUT restarting BS as we are not always in the conditions of doing it.. Now, can somebody tell me why 02-nanop.py is apparently the only piece of code which is producing problems? Maybe it is related with: sd.baseline += [nanop] If so, we just "protected" it with Julien by adding:
# check if nanop already there and remove it
try:
sd.baseline.remove(nanop):
except NameError:
pass
Would this ok with everybody?
In general, as it was the case for us with nanopositioners being commissioned and showing problems, on beamlines we have a number of pieces of equipment which may be configured or not depending on the experiment, which might have to be removed on the fly because they produce problems, which have to be tweaked during the experiments because they show limits or problems or improvements and tuning are necessary... Are we saying that every time we perform these operations we need to restart BS?
On the same page, we have a problem with imported libraries and relative paths in config (.. profiles.. /startup ) files. What about the option of: importlib.reload ??
Yes, @cmazzoli, I think that's the place where you populate the list with the nanop
multiple times. We need to be careful with how we delete it, there are multiple options, and .remove()
removes just the first occurrence (this may be important if you already have multiple instances of nanop
there), and NameError
may not catch it -- you may need a ValueError
. Is the order of the motors important for sd.baseline
? Maybe you can search of its index in the list (idx = sd.baseline.index(nanop)
), and then replace just this element (sd.baseline[idx] = nanop
). Other thoughts?
I think it's always safer to restart bsui
rather that rerunning particular modules (done with %run -i <name>.py
). I am not sure if reloading imports helps in this case, %run
does it for you, but you already have the vars for lists, etc. defined in your namespace. You may want to clear these vars on loading of the module.