search

epics-modules / mrfioc2

EPICS driver for Micro Research Finland event timing system devices
http://epics-modules.github.io/mrfioc2/
Other
8 stars 30 forks source link

missing Pause/Abort functionality #51

Open krmpotic opened 3 years ago

krmpotic commented 3 years ago

evg-usage.lyx mentions Pause(bo) and Abort(bo) records, which are not implemented.

I added a PR https://github.com/epics-modules/mrfioc2/pull/50. Using Disable-Cmd as a template. Quick test shows that it works OK.

mdavidsaver commented 3 years ago

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?

krmpotic commented 3 years ago

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?

krmpotic commented 3 years ago

@mdavidsaver can you please elaborate regarding your concerns about race conditions? I want to allow users to abort long-running 10sec+ sequences on EVM.

mdavidsaver commented 3 years ago

I want to be able to stop long sequences (e.g. 30 sec+)

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.

I saw that missing end of sequence notifications ... are they something to be relied upon anyway?

As it stand now, yes.