Hi Tim,
Multiple Polling equipment are possible, but you may have to balance the polling
time based on the expected trigger rate for each equipment due to the
acquisition/processing time of each equipment.
But instead of using the event buffer destination for the dataset selection, you
could use the trigger mask and the event ID modified at the user code level from
a single equipment.
Using the macros such as TRIGGER_MASK(pevent), EVENT_ID(pevent) you can modify
on the fly their assignment. All go through the SYSTEM buffer as usual.
You use the data logger capability of multiple channels to steer the data in
different files.
Each logger channel requires a definition of the type of event that you want to
record. EventID, TriggerMask can in this case be used to select a particular
type of event.
I used this option and if I recall correctly, the trigger mask is the one you
want to base your selection upon. This gives you up to 16 channels (bitwise).
the eventID should remain -1, but it is a valid information from the FEs.
Cheers, PAA
>
>
> We have a MIDAS frontend that provides both the readout of raw events
> and the processing of raw events into several distinct derived datasets.
> For one type of derived dataset there is a derived event for
> each raw event. For other types of derived datasets there's a
> derived event for every N raw events. We'd like to have the different
> derived event types sent to different buffers / shared memory segments
> and stored in different midas files.
>
> I was thinking of defining a separate equipment for each type of
> derived data. Each equipment would have a different buffer name so
> the data would go to different buffers and thereafter to different
> midas files. I was also thinking of defining each equipment as
> a "polled event" but with a unique "source ID". I believe the user
> poll_event() function is passed the "source ID" of the equipment
> type and therefore could return success/fail based on whether or
> not the particular derived event with that source ID is available
> for readout. Each equipment for each derived dataset would have
> a unique readout routine to create and fill the midas databanks
> for that derived event type.
>
> The above scheme is similar to the midas documentation example
> of a frontend with a trigger equipment and a scaler equipment
> However, the scaler / trigger example uses two different event
> types - EQ_POLLED for trigger and EQ_PERIODIC for scaler. I'd like
> to use several EQ_POLLED equipments that are distinguished by
> their source ID's
>
> Is this a sensible scheme for make different data streams of
> different derived event types from a single frontend? Has anyone
> tried something similar? |