delaere / vehemence Goto Github PK

Allows decimal VMAX.
This implies changes in some registers.

New methods for channel/group priority.

This is all implemented but was never tested.

The implementation of V812, V1190, scaler and TTCvi is limited and needs more tests with hardware.

The main feature of the Version 3.00 of the SY527 software is the possibility of using non-homogeneous boards, i.e. boards containing different channel types. For example, the A933K board contains 2 channel types: 1 primary channel and 24 distributed channels.

The operation via H. S. CAENET changes slightly: in particular, the response to Code %3, %N is different than what described for non-homogeneous boards.

-> modification of the discoverBoards() method

• create several copies of a given board, and store the subindex in the last bytes.
• add the channel list to the board class (bit mask?)
• properly assign channels to the (sub)board object in the constructor
• adapt the getBoard method to hide the (index, type) encoding

I have linker errors using the latest version of CAENVMELib: undefined reference to CAENVME_DecodeError. The linking works fine if I comment this function in CommonDef.h. Running nm -gDC lib/x64/libCAENVME.so.3.3.0 does not show CAENVME_DecodeError, so it really looks like that function definition is missing from that build... although the declaration is present in include/CAENVMElib.h.

I've opened a ticket with CAEN support, but I was wondering which version has been used in the past that compiled correctly...?

various flavors of read/write requite a void* to a int. This doesn't work in python. The solution might be to use uint64_t instead for simple methods.

Need a way also for block transfers.

More examples should be added, especially in python.

Some of the methods that are exposed cannot be used because of missing translations. One example is the ChannelGroup::find methods, returning (or using) iterators. There are few similar examples, or methods that work not in a friendly way.

The units for V and I are inconsistent.
For example, Vmon & Imon must be divided by 10^dec.

The convention is otherwise to let the "set" quantities explicitly as they are sent to the hardware, so the user must be aware of the powers of 10 to use.

Since caen introduces the notion of groups of channels, we need typically a group class

• initialized from the config on caenet with pointers to the channels
• with methods to configure the group and read channel status in a group (must update the channel cache afterwards)
• with methods to add a channel (either by index or by pointer)
• with methods to remove a channel

Also, few additional caenet methods of general interest.

Probably the simplest thing to do is to just call functions from a
central module definition. e.g.

//file 1
BOOST_PYTHON_MODULE(poc)
{
wrapFoo();
wrapBar();
wrapBaz();
}

//file 2
void wrapFoo() {
class_<...>(...);
}

//file 3
void wrapBar() {
class_<...>(...);
}

//file 4
void wrapBaz() {
class_<...>(...);
}

3 new caenet codes:
0x07: read hardware status. Requires a new status word for SY527 and related code.
0x08: self-test and restart (always)
0x09: self-test and restart (if success)
after these two, wait few seconds and perform a 0x07.
This requires one new method for SY527.

similar but simpler than SY527.
Code ported from the original code but never tested. Should work.

J'ai compilé vehemence sur la machine µTCA mais j'ai eu un peu de mal et il y aura peut-etre des choses à fixer dans CMAKE.

Evidemment les versions de cmake, boost et gcc sur centos sont trop vieilles mais on a pu installer des versions plus récentes avec les devtoolssets.

Malheureusement cmake ne détecte pas les nouvelles versions et malgré les requirements:

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

Il ne signale pas de problèmes avant la compilation. J'ai donc ajouté les variable a la main:

# use proper boost version
set(BOOST_INCLUDEDIR "/usr/include/boost169")
set(BOOST_LIBRARYDIR "/usr/lib64/boost169")

# use proper c++ compiler
set(CMAKE_CXX_COMPILER "/opt/rh/devtoolset-8/root/usr/bin/g++")
set(CMAKE_CXX_FLAGS "-std=c++17")

Et il commence bien la compilation normalement, mais il plante au link avec:

[ 84%] Building CXX object examples/CMakeFiles/exampleFull.dir/exampleFull.cpp.o
Linking CXX executable exampleFull
/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/ld: CMakeFiles/exampleFull.dir/exampleFull.cpp.o: undefined reference to symbol 'pthread_rwlock_wrlock@@GLIBC_2.2.5'
//lib64/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [examples/exampleFull] Error 1

​J'ai donc du ajouter (google est mon ami):

set(CMAKE_CXX_FLAGS "-std=c++17 -pthread")

Voilà, après tout cela c'est compilé, mais il faudra juste comprendre pourquoi cmake ne signale pas le manque de C++17 et pourquoi j'ai du ajouter -pthread aux flags. Pour boost, on sait que findboost n'est pas une flèche et je ne suis pas étonné d'avoir du ajouter les variables à la main 😄

The caenet bridge write method uses a std::vector as input.

Either change that to something more python-friendly, or add a wrapper.
As it is now, there is no way to use the method in python.

VmeUsbBridge::systemReset() is not mapped.

caenet codes 0x60 and 0x61; read checksums...