actual Shuttertimes in runviewer

[philipstarkey]

Original report (archived issue) by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

As already discussed in #5 I aim to add the real shutter open/close times to runviewer.

I think this is best done by keeping the plot the same and adding a Infinite line (green: open, red:close) to the plot at the appropriate time.

To achieve this I would like to add to connection_table_properties in labscript in the following way:

#!python

class Shutter(DigitalOut):
    description = 'shutter'

    @set_passed_properties(
        property_names = {"connection_table_properties": ["open_state"]}
        )
    def __init__(self,name,parent_device,connection,delay=(0,0),open_state=1,
                 **kwargs):

In runviewer I would add to Shot.load_devices:

#!python

        shutters = [name for name, clazz in get_children(self.connection_table, device).items() if clazz == "Shutter"]
        self.add_shutter_times(shutters)

and:

#!python

    def add_shutter_times(self, names):
        for name in names:
            x_values, y_values = self._traces[name]
            change_values = []
            values = zip(x_values, y_values)
            for i in range(1, len(values)):
                if values[i][1] != values[i - 1][1]:
                    change_values.append(values[i])
            # Todo Handle Inverted Schutters?
            self._shutter_times[name] = {x_value + (self.calibrations[name][1] if y_value == 1 else self.calibrations[name][0]): y_value for x_value, y_value in change_values}

The display of InfiniteLines in the plots is then easy. Thoughts?

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

I'm somewhat perturbed by the fact that this is a special case for Shutter, however I've been thinking about this over the weekend and I can't see an easy way to make it generalised.

So I think I'll say I'm happy with the approximate implementation, but please leave comments in the runviewer code that say this is a temporary solution (and that the implementation is not expected to stay static, so don't rely on this as an API) until we generically support custom runviewer behaviour for all subclasses of Output.

In the long term, I think we may need to register subclasses of Output with a decorator, along with a similar implementation for output type subclasses for use in BLACS and runviewer like we currently do with hardware devices. @chrisjbillington may want to comment on that suggestion (perhaps I should break it out into a new issue)

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

Well it is something that just effects shutters in the moment as they are the only outputs that support delays. And they are also the only device (that I can think of) where the signal and actual behavior differ at the moment. After all thats the whole point behind this issue.

Will definitely do some commenting on the code stating that it's temporary.

I think a new issue would be great for this as it keeps things separated.

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

• changed state from "new" to "resolved"

resolved by pull request #11