epics-modules / mca Goto Github PK

Testing workflow for issues and pull requests

Test issue 2

Dear,
How this IOC module should work?
I run the /mca/iocBoot/iocAmptek/st.cmd file nothing happend

[guest@localhost iocAmptek]$ ./st.cmd
[guest@localhost iocAmptek]$

I have compiled successfully, and successfully communicated with the X-123SDD hardware device, but I don't know how to run ioc.

Your sincerely
Kangwen

mcaApp/CanberraSrc/Makefile allows mcaCamberra, mcaAIM, and nmcDemo to be easily omitted from the build on Linux:

# Linux
# To build for Linux system uncomment the following lines.  This requires libnet or
# LLC sockets
ifeq ($(LINUX_NET_INSTALLED), YES)
LIBRARY_IOC_Linux += mcaCanberra
PROD_IOC_Linux    += mcaAIM
PROD_IOC_Linux    += nmcDemo
endif

But not on OS X (Darwin):

# Darwin
LIBRARY_IOC_Darwin          += mcaCanberra
PROD_IOC_Darwin             += mcaAIM
PROD_IOC_Darwin             += nmcDemo

I don't know if the correct approach is to add DARWIN_NET_INSTALLED to mca's configure/CONFIG_APP or to change LINUX_NET_INSTALLED to something more general that applies to both Linux and OS X.

I'm using the following:

Windows 7 (64-bit)
Visual Studio 2010 Professional & Visual Studio 2015 Community Edition
Make 4.1 (from the EPICS web site)
Strawberry perl 5.20.3001

The mca trunk (5f83a14) successfully builds against the released version of base-3.14.12.5 and fails to build against the released version of base-3.15.4 using both VS2010 and VS2015:

link -nologo  -LTCG -incremental:no -opt:ref -release               -out:mcaAIM.exe       mcaCanberra_registerRecordDeviceDriver.obj mcaCanberraMain.obj     ../
../../lib/win32-x86-static/mca.lib  ../../../lib/win32-x86-static/mcaCanberra.lib  D:/synApps-testing/VS10/3.15/synApps/support/calc/lib/win32-x86-static/calc.l
ib  D:/synApps-testing/VS10/3.15/synApps/support/autosave/lib/win32-x86-static/autosave.lib  D:/synApps-testing/VS10/3.15/synApps/support/sscan/lib/win32-x86-st
atic/sscan.lib  D:/synApps-testing/VS10/3.15/synApps/support/busy/lib/win32-x86-static/busy.lib  D:/synApps-testing/VS10/3.15/synApps/support/asyn/lib/win32-x86
-static/asyn.lib  D:/synApps-testing/VS10/3.15/synApps/support/seq-2-2-3/lib/win32-x86-static/seq.lib  D:/synApps-testing/VS10/3.15/synApps/support/seq-2-2-3/li
b/win32-x86-static/pv.lib  D:/synApps-testing/VS10/3.15/base-3.15.4/lib/win32-x86-static/dbRecStd.lib  D:/synApps-testing/VS10/3.15/base-3.15.4/lib/win32-x86-st
atic/dbCore.lib  D:/synApps-testing/VS10/3.15/base-3.15.4/lib/win32-x86-static/ca.lib  D:/synApps-testing/VS10/3.15/base-3.15.4/lib/win32-x86-static/Com.lib  ..
/../../lib/win32-x86-static/wpcap.lib  ../../../lib/win32-x86-static/Packet.lib ws2_32.lib ws2_32.lib advapi32.lib user32.lib kernel32.lib winmm.lib
sscan.lib(recDynLink.obj) : error LNK2001: unresolved external symbol _dbNameToAddr@8
mcaAIM.exe : fatal error LNK1120: 1 unresolved externals
D:/synApps-testing/VS10/3.15/base-3.15.4/configure/RULES_BUILD:198: recipe for target 'mcaAIM.exe' failed
make[4]: *** [mcaAIM.exe] Error 1120
make[4]: Leaving directory 'D:/synApps-testing/VS10/3.15/synApps/support/mca/mcaApp/CanberraSrc/O.win32-x86-static'
D:/synApps-testing/VS10/3.15/base-3.15.4/configure/RULES_ARCHS:61: recipe for target 'install.win32-x86-static' failed
make[3]: *** [install.win32-x86-static] Error 2
make[3]: Leaving directory 'D:/synApps-testing/VS10/3.15/synApps/support/mca/mcaApp/CanberraSrc'
D:/synApps-testing/VS10/3.15/base-3.15.4/configure/RULES_DIRS:88: recipe for target 'CanberraSrc.install' failed
make[2]: *** [CanberraSrc.install] Error 2
make[2]: Leaving directory 'D:/synApps-testing/VS10/3.15/synApps/support/mca/mcaApp'
D:/synApps-testing/VS10/3.15/base-3.15.4/configure/RULES_DIRS:88: recipe for target 'mcaApp.install' failed
make[1]: *** [mcaApp.install] Error 2
make[1]: Leaving directory 'D:/synApps-testing/VS10/3.15/synApps/support/mca'
D:/synApps-testing/VS10/3.15/base-3.15.4/configure/RULES_DIRS:88: recipe for target 'D:/synApps-testing/VS10/3.15/synApps/support/mca.install' failed
make: *** [D:/synApps-testing/VS10/3.15/synApps/support/mca.install] Error 2

/usr/bin/g++ -D_GNU_SOURCE -D_DEFAULT_SOURCE -D_X86_64_ -DUNIX -Dlinux -O3 -Wall -mtune=generic -m64 -fPIC -I. -I../O.Common -I. -I. -I.. -I../../../include/compiler/gcc -I../../../include/os/Linux -I../../../include -I/home/guest/EPICS/synApps/support/calc-R3-7-1/include -I/home/guest/EPICS/synApps/support/sscan-R2-11-1/include -I/home/guest/EPICS/synApps/support/busy-R1-7/include -I/home/guest/EPICS/synApps/support/scaler/include -I/home/guest/EPICS/synApps/support/seq-2-2-5/include -I/home/guest/EPICS/synApps/support/autosave-R5-9/include/os/Linux -I/home/guest/EPICS/synApps/support/autosave-R5-9/include -I/home/guest/EPICS/synApps/support/asyn-R4-33/include -I/home/guest/EPICS/synApps/support/mca-R7-7/include/os/Linux -I/home/guest/EPICS/synApps/support/mca-R7-7/include -I/home/guest/EPICS/epics-base/include/compiler/gcc -I/home/guest/EPICS/epics-base/include/os/Linux -I/home/guest/EPICS/epics-base/include -I/usr/include/libusb-1.0 -c ../drvAmptek.cpp
../drvAmptek.cpp: In member function ‘void drvAmptek::setParamsAlarm(int, int)’:
../drvAmptek.cpp:241:38: error: ‘getNumParams’ was not declared in this scope
getNumParams(addr, &numParams);
^
make[3]: *** [drvAmptek.o] Error 1
make[3]: Leaving directory /home/guest/EPICS/mca-master/mcaApp/AmptekSrc/O.linux-x86_64' make[2]: *** [install.linux-x86_64] Error 2 make[2]: Leaving directory /home/guest/EPICS/mca-master/mcaApp/AmptekSrc'
make[1]: *** [AmptekSrc.install] Error 2
make[1]: Leaving directory `/home/guest/EPICS/mca-master/mcaApp'
make: *** [mcaApp.install] Error 2
(base) [guest@localhost mca-master]$

$(P)PresetReal is defined twice in SIS38XX.template. Once on line 60:

record(ao,"$(P)PresetReal") {
  field(PINI, "YES")
  field(DTYP, "asynFloat64")
  field(OUT,  "@asyn($(PORT),0)MCA_PRESET_REAL")
  field(VAL,  "0.0")
  field(PREC, "2")
}

And a second time on line 122:

record(ao,"$(P)PresetReal") {
  field(PINI, "YES")
  field(DTYP, "asynFloat64")
  field(OUT,  "@asyn($(PORT),0)MCA_PRESET_REAL")
  field(VAL,  "0")
  field(PREC, "3")
}

This doesn't cause any problems when the database is loaded; the second definition overrides the first. It could, however, cause minor confusion in the future. The only reason I noticed it is because I have a script that generates PV aliases and it generated a duplicate alias that did result in an error.

make[3]: Entering directory /home/guest/EPICS/mca-master/mcaApp/CanberraSrc/O.linux-x86_64' make[3]: Nothing to be done for install'.
make[3]: Leaving directory /home/guest/EPICS/mca-master/mcaApp/CanberraSrc/O.linux-x86_64' make[2]: Leaving directory /home/guest/EPICS/mca-master/mcaApp/CanberraSrc'
make -C ./SISSrc install
make[2]: Entering directory /home/guest/EPICS/mca-master/mcaApp/SISSrc' make -C O.linux-x86_64 -f ../Makefile TOP=../../.. \ T_A=linux-x86_64 install make[3]: Entering directory /home/guest/EPICS/mca-master/mcaApp/SISSrc/O.linux-x86_64'
Expanding dbd file ../SIS38XXTestInclude.dbd
perl -CSD /home/guest/EPICS/epics-base/bin/linux-x86_64/dbdExpand.pl -I. -I.. -I../O.Common -I../../../dbd -I/home/guest/EPICS/synApps/support/calc-R3-7-1/dbd -I/home/guest/EPICS/synApps/support/sscan-R2-11-1/dbd -I/home/guest/EPICS/synApps/support/busy-R1-7/dbd -I/home/guest/EPICS/synApps/support/seq-2-2-5/dbd -I/home/guest/EPICS/synApps/support/autosave-R5-9/dbd -I/home/guest/EPICS/synApps/support/asyn-R4-33/dbd -I/home/guest/EPICS/synApps/support/mca-R7-7/dbd -I/home/guest/EPICS/epics-base/dbd -o SIS38XXTest.dbd ../SIS38XXTestInclude.dbd
dbdExpand.pl: Can't find file 'scalerSupport.dbd'
while reading '../SIS38XXTestInclude.dbd' to create 'SIS38XXTest.dbd'
dbdExpand.pl: Exiting due to errors
make[3]: *** [../O.Common/SIS38XXTest.dbd] Error 2
make[3]: Leaving directory /home/guest/EPICS/mca-master/mcaApp/SISSrc/O.linux-x86_64' make[2]: *** [install.linux-x86_64] Error 2 make[2]: Leaving directory /home/guest/EPICS/mca-master/mcaApp/SISSrc'
make[1]: *** [SISSrc.install] Error 2
make[1]: Leaving directory `/home/guest/EPICS/mca-master/mcaApp'
make: *** [mcaApp.install] Error 2
(base) [guest@localhost mca-master]$

Currenty the IOC does

According to the DP5 Programmers guide B1, page 71, for DP5G the bytes 30 and 31 are N/A.
As they are now taken into the $(P)$(R)HighVoltage, without detector type checking being done, the reported HV value to the user seems off.
For example, setting HV to + 616 V gives an impression that HV is barely ~100 V (status value). At the same I believe that the detector actually does use + 616 V, and not ~100 V, due to HVSE=?; command value on readback. I would need to somehow measure the HV to be 100 % sure.
Also, vendor windows tool, DppMCA, does show correct value in its UI, but that is probably because it is ignoring the status packet bytes 30-31 for DP5G detector.

A solution would be to use the value as returned by the HVSE=?; command. It was observed that this HVSE=?; always returned the value user set with HVSE=nnn; previously.

I tried to use the synApps mca module R7-9 to control some Amptek
PX5 SDD readout electronics over USB (Amptek docs say the ethernet is 10-baseT... haven't had time to test transfer rates to see if this is still true). I couldn't get the driver to connect, then traced the problem to the function "drvAmptek::connectDevice()" failing on a "hostToIPAddr()" call that fails because a valid IP address was not given (actually is left blank for USB devices).

I got around it by checking if "addressInfo_" is empty, and that got the app working so that I could to some test data acquisition.

But it now occurs to me that the entire chunk of code prior to checking "directMode_" should be in the "if( interfaceType == DppInterfaceEthernet)" block. I haven't tested this yet, but it seems more appropriate.

Because the Amptek USB code only connects to a "default" unit, an IOC that has multiple detectors connected by USB can only connect to one.

A proposed solution is to add "connect" functions similar to the "connect default" functions that accept serial number arguments.

I've been making similar modifications to the original SDK and have demonstrated to myself this can work. I am about to try the same to the mca module.

I have two Amptek GammaRad5 (DP5G) devices to work with.
I'm using latest mca code base, from this repo.

After leaving both devices connected and controlled by two separate IOCs, I can see that IOC shell shows many errors, for both devices. They both seem to be functioning nevertheless, collecting the spectra still.
Devices are connected to the local LAN as well as the controlling PC (same subnet), running Linux OS.
I have not tried using direct connection (one device point-to-point or two of them over an isolated network hub/switch), nor the USB connection yet.

I'm wondering what is the severity of these errors and if they need to be looked into.

rad1-log.txt
rad2-log.txt