Hall A Analyzer

h1.  How to add a VME Module to Podd

R. Michaels, Mar 23, 2015

A VME module is a device that sits in a VME crate and reads data. This document explains how to add a new VME module to the decoder for the Podd analyzer.

Note: I don't expect anyone to invent a new Fastbus module, so I'm only explaining VME. This is part of the "OO Decoder Upgrade" circa 2014.

Follow these steps. Details are shown below.

* Write a module class that inherits from VmeModule. An example would be SkeletonModule. You could copy that and make changes.

* Warning: your class must not be abstract ! If it is, the module will not be instantiated. (this means that methods=0 in base class must be defined).

* Add the "DoRegister" lines to your new module class. Note, each module has a unique identifying number, the "model number". E.g. 3801 for a Struck model 3801 scaler.

* Add the class to the namespace Decoder in Decoder.h

* Add it to the Makefile

* Add it to the haDecode_LinkDef.h file

* Add the appropriate lines to the crate map file db_cratemap.dat 

Note that you can also "make your module a plugin":https://github.com/JeffersonLab/analyzer/blob/master/hana_decode/README_NEWMODULE.md. Using a plugin in Podd is an ideal way to develop and test your new module. (Thanks to Steve Wood for that.)

Here are a few technical details.

The "DoRegister" lines look like this, e.g. in @Fadc250Module.C@

<pre>

 Module::TypeIter_t Fadc250Module::fgThisType =

    DoRegister( ModuleType( "Decoder::Fadc250Module" , 250 ));

</pre>

The last number (250) is the "model number" and must be unique for

that class.  It essentially signals what class to use.

The model number must also appear in the @db_cratemap.dat@ file.

Actually, this was always the case.

The line in haDecode_LinkDef.h looks like this:

<pre>

#pragma link C++ class Decoder::Fadc250Module+; 

</pre> 

Important: If you fail to add the above line to @haDecode_LinkDef.h@ the code

will compile and run, but the class is not instantiated (and an error

message is shown) which means basically no module.  It could take awhile

to figure that out if you miss the error messages.

The OO Decoder is very reliant on the @db_cratemap.dat@ file, so effort

must be put into making that correct.  If a module is not in the cratemap

it will be ignored !  Put in all modules that were ever used during the 

experiment.  If a module is in the cratemap but not defined, a warning 

is issued.  For example, there is no such thing as a model 5678 VME module.  

For Fastbus (unlike VME !), the modules are discoverable from the data, 

and if they are not in the cratemap a warning is issued.  Fix it.  

One advantage of the new OO Decoder scheme is that you can "Get"

a module.  This is useful for modules with complex behaviour.

See @tstfadc_main.C@, @tstf1tdc_main.C@, or @tstskel_main.C@

for examples

<pre>

fadc = evdata->GetModule(9,5); // crate 9, slot 5

if (fadc->GetMode()==1) {// do one thing, e.g.

    h1->Fill(fadc->GetData(1,11,0));

} 

if (fadc->GetMode()==2)

    cout<<"do something else"; 

</pre>