-
Notifications
You must be signed in to change notification settings - Fork 30
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
missing Pause/Abort functionality #51
Comments
pause/abort existed prior to 2.2.0 (circa 2017). I dropped the feature when reworking the sequencer code to support the sequencers in newer EVRs. Accounting for the various possible race conditions is complicated, and the alternative is (at best) missing end of sequence notifications. I wasn't aware of any usage. Can you elaborate? |
I want to be able to stop long sequences (e.g. 30 sec+) without waiting for them to finish. I need sequences to gate prescaler->pulser signals, and I want to be precise when doing it. So I can't use software events. In other words, I have a sequence that controls EVR gates, if something goes wrong or per user request I want to halt the sequence and bring the gates down "immediately". I saw that missing end of sequence notifications might be a problem for some use-cases (mine included!). But are they something to be relied upon anyway? For example if the sequences become very short (~10µs) & thus high-frequency, the CPU can't handle all the IRQs, missing some. In these cases disabling these IRQs is necessary, but this is another issue. Can you give me an example of a race condition here? |
@mdavidsaver can you please elaborate regarding your concerns about race conditions? I want to allow users to abort long-running 10sec+ sequences on EVM. |
I see. I guess I'm lucking to have avoided this situation so far. One way I've done this is by splitting a long sequence into pieces, and using the 2 sequencers as a double buffer. One piece is loading while the previous one is running. Buffer handling is driven by the start/end of sequence interrupts. A missing notification will stall this process. So I can't tolerate missed notifications during "normal" operation. This approach also has the benefit of allowing a controlled "abort" at the boundary between pieces. fyi. the double buffer strategy I describe is to my knowledge still in use at FRIB to control pulse repetition rate through a ~10 minute long ramp up process, which may be interrupted into a controlled ramp down. As I think about it though, an explicit hard abort isn't "normal". If you are going to allow this, then your application must already be prepared to deal with the unpredictable state which follows.
As it stand now, yes. |
Support for GitLab CI/CD (closes epics-modules#51)
evg-usage.lyx mentions Pause(bo) and Abort(bo) records, which are not implemented.
I added a PR #50. Using Disable-Cmd as a template.
Quick test shows that it works OK.
The text was updated successfully, but these errors were encountered: