Closed philipstarkey closed 5 years ago
philipstarkey
commented
6 years ago Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).
Makes sense.
We should probably come up with a low cost FPGA solution for wait monitors to avoid the underlying issue with using the NI card as a wait monitor, but that's a discussion for another day I think!
philipstarkey
commented
6 years ago Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).
Hmm, a thought I've just had (I was reviewing the code for this anyway because I'm finishing off that thesis section) is that maybe we should keep the requirement of the WaitMonitor in labscript, but make everything beyond the 3rd argument optional. This keeps the output that goes high/low during a wait, which is often used to arm the hardware device doing the retriggering. The lack of specifying devices/channels for arguments 4/5/6/7 in the labscript WaitMonitor would mean no wait monitor is used in BLACS.
philipstarkey
commented
6 years ago Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Actually the wait monitor just produces a pulse when the wait is over. I believe arming things has to be done manually with an extra line, unless I'm misunderstanding something.
Not a bad thought otherwise, you could certainly have the output without the counter input.
philipstarkey
commented
6 years ago Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).
Oh I see. My mistake. The WAIT instruction gets added prior to the trigger time, not in the middle of the pulse.....I better update my thesis because my explanation of this is wrong!
philipstarkey
commented
5 years ago Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Resolved by PR #49
philipstarkey
commented
5 years ago Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Original report (archived issue) by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Wait monitors are confusing, take up ports and have some bugs and limitations associated with them.
If people do not want to have waits automatically time-out, and if they are not using analog inputs that require wait duration information in order to be processed, then they shouldn't need to have a wait monitor in order to run a shot.
Bugs in NI DAQmx counter acquisition at UMD have caused issues that we have worked around by making the wait monitor pulses 100ms long (the counter on the NI DAQmx device in question has a very small buffer and so misses edges if they are too close together and are not read out by the software before more edges come). This has worked well enough, but now at NIST an experiment needs multiple waits closer together than 100ms. They aren't using timeouts or NI DAQmx analog inputs, so the wait monitor is nothing but a source of bugs for them.
So I'll likely make wait monitors optional, with errors being raised if you try to do analog input or specify a timeout to wait() without a wait monitor.