Better control of shutters

[philipstarkey]

Original report (archived issue) by Shaun Johnstone (Bitbucket: shjohnst, GitHub: shjohnst).

---

At the moment labscript is quite simple when it comes to shutters. The open() and close() commands offset the triggers by the appropriate delays (see also issue #2).

In reality, shutters are more complicated, they take a finite time to open and close, and may have other timing requirements.

For example, our SRS shutters will stay open for a fixed minimum time if the close trigger is too soon after the open trigger, and similar for minimum close times.

Phil and I propose the introduction of new commands to allow the user to be sure that the shutter does what they want:

open_by(t)
close_by(t)
open_from(t)
close_from(t)

The _by commands would take the open/close delays and the shutter rise/fall time to ensure that the trigger is sent such that the shutter is completely open/closed at the time requested.

The _from commands would use the delays to trigger the shutter to start opening/closing at the requested time.

Further, the triggering should be aware of minimum opened/closed state times, and not trigger faster than these such that the timing of the trigger commands matches the timing of the physical state of the shutter. This helps debugging experimental problems in runviewer. The safest option for dealing with user requests to open/close this would be to raise an error. This should be implemented generally enough to account for the fact that the min open and min close times are not always equal.

The "delay" parameters that will be supplied for each shutter will now be

(open_delay,
open_time,
min_opened_time,
close_delay,
close_time,
min_closed_time)

Open and close delays should be the time from the trigger until the shutter is half way between the fully open and fully closed states (as is currently assumed). This will allow backwards compatibility with open and close commands.

The _by and _from commands will then add or subtract half the open/close time as needed. The user can choose how strict they want to be with their open/close times depending on what level of leakage is acceptable (e.g. time taken from 10% open to 90% open vs 1% to 99%)

The min_opened/closed_time should be the maximum time allowed between triggers such that the shutter state remains the same as a short/delta pulse would produce.

These parameters are stored as attributes of the shutters. This is useful, for example the user could request a shutter to open for the minimum possible time by calling

shutter.open(t)
shutter.close(t+shutter.min_opened_time)

[philipstarkey]

Original comment by Shaun Johnstone (Bitbucket: shjohnst, GitHub: shjohnst).

---

• set assignee_account_id to "557058:cbf1bc43-1dc2-477b-9e25-1a8f40fd7ee3"
• set assignee to "cbillington (Bitbucket: cbillington, GitHub: chrisjbillington)"

[philipstarkey]

Original comment by Shaun Johnstone (Bitbucket: shjohnst, GitHub: shjohnst).

---

Actually, that last example is wrong, due to shutter delays. Perhaps the close_from (or possible another new command, e.g. close_after(t) ) command should make the shutter start closing at the earliest possible time after the time specified? This then leads to a higher likelihood of commands getting tangled and overwriting each other, but as long as there are warnings when this happens it should be ok. This then allows the user to program in short shutter times without having to worry about the restrictions.

[philipstarkey]

Original comment by Shaun Johnstone (Bitbucket: shjohnst, GitHub: shjohnst).

---

Another suggestion would be to replace the tuple of delay times with a dictionary, such that they are essentially keyword arguments, making it easier if you don't want to set all the new times

[philipstarkey]

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

---

• changed kind from "proposal" to "enhancement"

Good idea and implementation will be fine - this should fit in with 2.0 development, so ETA later this year with the other porting/refactoring.