Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check if ttl channel overridden from experiment code #626

Open
r-srinivas opened this issue Nov 23, 2016 · 4 comments
Open

Check if ttl channel overridden from experiment code #626

r-srinivas opened this issue Nov 23, 2016 · 4 comments

Comments

@r-srinivas
Copy link

Is there anyway of checking if a ttl channel has been overridden from experimental code? Sometimes it's easy to forget that one has overridden some channel to debug when running an experiment. It would be nice if there was some way of checking that and flagging it/raising an exception if a relevant ttl channel has been overridden.

@jordens
Copy link
Member

jordens commented Nov 23, 2016

I strongly advise against implementing that functionality in the way you describe it. It would violate the clear separation of functionality. Since stuff can become overridden at any time you would never be able to reliably detect that situation.

What about these alternatives:

  1. Use the artiq API to script moninj. Should even work fine from experiments.
  2. Figure out why/whether the moninj GUI does tell you clearly enough what's overridden.

@r-srinivas
Copy link
Author

To be more explicit, I guess if we can just check it at the start of the experiment at prepare that would be more than enough. Does scripting moninj already work?

The issue I had with the gui is that even with just 40 channels as we have now we can't see all of them at once so it's easy to miss channels that have been overridden.

@jordens
Copy link
Member

jordens commented Nov 28, 2016

But for that issue it would seem you want something entirely different: a more compact moninj UI.

Sorry, something went wrong.

@r-srinivas
Copy link
Author

Making the gui more compact doesn't seem scalable especially if we upgrade the our backplane on the HPC side to have more ttl channels. I think the solution should be independent of the gui. If there's some way to check if a specific ttl channel were overridden that would help. It's not a high priority but it helps you avoid silly errors.

The mistake I ran into was that we were debugging ttl transport at some point and I had overridden the pdq_trigger high just to check if all the slaves were still responding. I forgot that was overridden when I tried transport and lost the ion as now the transport was of course not being triggered. It would have been nice if the experiment had some way of throwing an exception before the transport experiment started.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants