The problem experienced yesterday in the ISC_LOCK guardian was caused by an errant instantiation of an ezca object in the main importable part of the bs_m2_switch.py module.  This extra ezca instance created a separate EPICS interface that interfered with the one provided by guardian.  Avoid doing this, since, as was shown, it causes problems.

It's understandable why one would think this is necessary, though, because of the somewhat obscure way that guardian provides the ezca interface to the usercode.  Guardian puts a special ezca instance into the main "built-in" namespace which makes it universaly available to all usercode.  When writing usercode modules, though, it's unclear how to emulate this for the purposes of testing, or to make a module usable in other contexts.

I've added the following code to the bottom of the bs_m2_switch.py module.  This makes the module directly executable from the command line, outside of the context of guardian.  The "__name__ == '__main__'" conditional defines code that will only be executed when the code is directly executed, rather than imported by something else.  It then instantiates an ezca object into the "__builtin__" namespace in a way that mimics what guardian does.  The primary function defined in the module (m2_switch()) is then callable in the same way it would be in guardian:

if __name__ == '__main__':
    import __builtin__
    from ezca import Ezca
    __builtin__.ezca = Ezca()
    m2_switch()

This should be considered as a prototype for all other similar modules that people want to be executable outside of guardian.

In general, though, I would encourage programers to make states dedicated to the execution of this kind of logic, which can then executed on their own via e.g.:

  guardian ISC_LOCK BS_M2_SWITCH