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

RFC: Add EVR Prescaler Pulse-Generator Trigger functionality #38

Closed krmpotic closed 3 years ago

krmpotic commented 3 years ago

"Starting from firmware version 0200 pulse generators can also be triggered from rising edges of ... EVR internal prescalers"

This commit adds PulsTrig-(Sel/RB) mbb(i/o)Direct records, which provide each EVR Prescaler with the ability to trigger any combination of EVR Pulse Generators.

E.g. setting {EVR-PS:0}PulsTrig-Sel.B3 = 1 {EVR-PS:0}PulsTrig-Sel.B8 = 1 {EVR-PS:2}PulsTrig-Sel.B0 = 1 {EVR-PS:2}PulsTrig-Sel.B3 = 1 will cause each rising edge of Prescaler 0 to trigger Pulse Generators 3 & 8, and each rising edge of Prescaler 2 to trigger Pulse Generators 0 & 3.

krmpotic commented 3 years ago

I realized mbboDirect allows for only 16 fields, which isn't enough if the user wants to use the prescaler to trigger pulsers 16 and above, this include gates (pulsers 28-31).

krmpotic commented 3 years ago

I switched to using long(out/in) records, which also provide access to pulser-gates (bits 28,29,30,31).

The usage is similar: {EVR-PS:0}PulsTrig-Sel = 0x11 will cause each rising edge of Prescaler 0 to trigger Pulse Generators 0 & 4.

mdavidsaver commented 3 years ago

As written, this new control seems not so user friendly. (I have some familiarity with how MRF thinks, otherwise I would have no idea how to make use of this feature)

Is there a known use case for triggering a pulser from multiple prescalars? Otherwise, I think an enumeration would be easier to understand.

Also, I've tried to associate such controls with the "destination" (pulser) rather than the "source" (prescalar). Maybe just how I think. When I want to understand why pulserX is triggering, I look from controls with pulserX in the name.

krmpotic commented 3 years ago

Is there a known use case for triggering a pulser from multiple prescalars? Otherwise, I think an enumeration would be easier to understand.

Yes. I need it to generate different kind of signals representing electron bunches before and after the kicker. I use two prescalers, one representing kicked, the other non-kicked bunches. The pulser that will represent both kicked and non-kicked bunches needs to be triggered by both prescalers.

Also, I've tried to associate such controls with the "destination" (pulser) rather than the "source" (prescalar). Maybe just how I think. When I want to understand why pulserX is triggering, I look from controls with pulserX in the name.

I agree. See new implementation at https://github.com/epics-modules/mrfioc2/pull/53. I'll close this one.