Re: [Daqpp-forum] scans
Brought to you by:
lacasta
From: Carlos L. <Car...@if...> - 2007-03-26 21:41:03
|
Hi andrej, > - related to scan managers relation to data run manager: If the scan run > manager is defined as below, is it created only when Scan is pressed on > the VMEDAQ's front panel or is it the sole run manager and has to manage > normal data taking as well? > The scan run manager will only be created when scan is enabled in the =20 scan dialog. Otherwise, you will use whatever you have defined in the =20 config file for the data run manager (The default is always =20 DataRunManager) > - is Trigger() routine called at the begining of each event? Can it be > understood as a StartOfEvent() pair to the EndOfEvent() routine? Should > module->Trigger() call Start()? If not, is module->Start() called before > or after Triggger()? Yes, Trigger() is called at the beginning of each event. =20 Module->Start() is called at the beginning of a run, before calling =20 RunManager::Trigger(). You should not care about Start(). It will be =20 called somewhere else. The idea behind Trigger is that the RunManager =20 can simulate a trigger creation... Of course it can be used for any =20 other purpose... > > - does CheckEndOfRun() signal the DAQmanager to stop the run? Yes, when it returns true, the run will be stopped. > > - I would make scan manager a child of Rmanager. Does that make sense? Am > I correct in assuming that all data loging will be then handled by > Rmanager and I should not bother by that? Would then the LogData button on > VMEDAQ's front panel determine whether we log data or not? (ie. pressing > scan after log data would store events taken during the scan in data files > as given by preferences dialog?) I forgot to mention that in vmedaq, the RunManager objects should =20 derive from Rmanager, like the modules do from GenModule. Rmanager =20 will take care of most of the things (I hope) To reduce "problems" just clone the current ScanRunManager and remove =20 references to PulseRunManager... Cheers, Carlos > > There might be more questions. Thanks. > > -Andrej > > >> Hello Andrej, >> >> Yes, you can certainly use the vmedaq scans for that. However, as usual, >> it will require some work on your side. The idea is that you create a >> new runmanager and load it with the configuration file (via one of those >> plugins) to be the one in charge of the scans. Say you create a run >> manager that lives in the shared library libMyRunManager.so. Then in the >> config file, in the plugins section you write >> >> <plugins> >> <plugin> ...whatever you might already have.. </plugin> >> >> <!-- User defined run managers --> >> <run_managers> >> <scan> >> <lib>path_to_the_lib/libMyRunManager.so</lib> >> <hook>create_scan_run_manager</hook> >> </scan> >> </run_managers> >> >> </plugins> >> >> That means that in your library there should be a static "C" function >> called create_scan_run_manager (it can be any valid name for a function) >> that actually creates the run manager and returns a pointer to it. >> >> Now, user defined RunManagers are defined like user defined modules but >> are much easier, since you do not need to define GUIs, configurations >> nor anything like that. Take a look at the example in making_a_module. >> >> To create your RunManager, I would propose to take ScanRunManager in the >> daq folder and build from that. You will have to remove its >> "relationship" with PulseRunManager, since you do not need that, and any >> call to methods to that class. Yes... I know that should be a "generic" >> class, and I promise I'll try to make it in the next release. >> >> How the thing works... All the sugar is in ScanRunManager::Trigger. >> There it determines if we should start a new point in the scan or not >> and notifies to the modules. I guess that if you just need to move axes, >> the modules do not need to be notified, but who knows... This can be >> done in 2 ways, either change every N events or change every N seconds. >> Depending on the method, one uses an EventCtr instance or an EventTimer >> instance. This is done automatically, so I guess you only need to edit >> the files to remove the dependencies with PulseGenerator and, in >> Trigger, move your stuff whenever (*next_point)() is true. >> >> Hope that helps. >> >> Regards, >> >> Carlos >> >> On Mon, 2007-02-19 at 11:54 -0500, Andrej Studen wrote: >>> Hi Carlos, everyone! >>> >>> I have a question. In what way is it possible to tamper with the scan >>> modality of VMEDAQ? >>> >>> Let me illustrate. What I have here is a scintillator camera which needs >>> to be recallibrated from time to time. To do that, we use a XY table and >>> record N=3D3000 events at a set of different positions (PMT centers, >>> orthogonal grids, etc.). I am tempted to use VMEdaq to do that. But my >>> user supplied scan routine should call external functions (move the >>> motor, >>> parse and analyze the data, move to next position) at each position. I >>> think it fits nicely into a scan philosophy. So, my question is: can I >>> do >>> that and if I can, what guidelines should I follow. >>> >>> A happy monday to everyone >>> >>> Andrej >>> >>> >>> ------------------------------------------------------------------------= - >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to share >>> your >>> opinions on IT & business topics through brief surveys-and earn cash >>> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID= =3DDEVDEV >>> _______________________________________________ >>> Daqpp-forum mailing list >>> Daq...@li... >>> https://lists.sourceforge.net/lists/listinfo/daqpp-forum >> -- >> ___________________________________________________________________ >> Carlos Lacasta >> ^^^^^^^^^^^^^^^ >> Inst. de Fisica Corpuscular (IFIC) >> Edificio Institutos de Investigacion >> P.O. Box 22085 >> E-46071 VALENCIA >> Spain >> Tel.: +34 96 354 3490 >> Fax.: +34 96 354 3488 >> Car...@if... >> ___________________________________________________________________ >> >> > > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |