As part of our control system we have a mix of control hardware (e.g. shutters, custom AOM drivers) and this leads to some inconsistency in whether TTL high or low corresponds to light reaching the experiment.

As a simple fix to this we have modified the artiq source so TTLOut and TTLInOut now assign a new property invert_output=False in the __init__ and updated the output function to

def set_o(self, o):
    	if self.invert_output:
            rtio_output(self.target_o, 0 if o else 1)
        else:
            rtio_output(self.target_o, 1 if o else 0)

TTL channels can then be initialised and set to invert using self.ttl0.invert_output=True and this allows us to operate such that e.g. self.ttl0.on() and self.ttl0.off() give the same behaviour for all shutters / AOM RF switches on the experiment. It would likely be easy to allow this to be hardcoded into the device_db if preferred.

Is this a feature other people would find useful, and if so should we submit a PR? Alternatively, have we over engineered this and a simple solution already exists within artiq without changing the source?

I don't think a software solution like this would be generally accepted. This has some performance overhead and the TTLs have to be fast. Gateware maybe.

  • jdp replied to this.

    sb10q Thanks Sebastian for the quick response.

    This is likely showing my ignorance but does the compiler not evaluate the logic outside the realtime flow and submit the RTIO update at the same timestamp as without the changes to the code thus not impacting the TTL speed, or is the point this is now adding overhead to the compiler process?

        It would in many cases, but the cases where it would not are probably not worth it.

        jdp

        FYI, just to clarify: though it's not 'the compiler' that does this, yes, the code when run will submit the RTIO updates at the scheduled time, regardless of the changes to the code. It's not compiler overhead that's a potential issue, it's the CPU processing overhead, and scheduled time isn't affected, but events that scheduled fine before may cause RTIO underflows if they take longer to calculate. That's the sense where having this in software would affect TTL speed / response time.