Some errors when using dxp-R6-1 module on ketek SDD detector

[1458861693]

There is some errors when using dxp-R6-1 module on ketek SDD detector，the following is the information of my environment. operating system ： CentOS7 architecture ： X86_64 iocBoot Directory ： /home/xanes/softIOC/support/dxp-R6-1/iocBoot/iocMicroDXP When i start IOC，there are many errors as log.txt in attached files，i really want some help，Thanks. The attached files contain log.txt，st.cmd and START_IOC，log.txt is printed information by IOCShell. log.txt st.cmd.txt START_IOC.txt

[MarkRivers]

@1458861693 The IOC I used is just the current master branch on Github. When I compile and run that on my CentOS 7 system it works for me. The same code does not work when I compile and run it on CentOS 9 on a different computer. I think that both you and @xv8tjc4d are running the same code on CentOS 7 and it does not work. This suggests that the problem depends on something other than the Handel code. I had really expected the test program and IOC to fail for me when I tested CentOS 7 and Ubuntu 22 on the Dell 5820, and was I surprised when they worked.

The IOC introduces additional complexity because of EPICS. The first thing to get working is the XIA test program since it is simple and easy for XIA to reproduce.

[1458861693]

OK，thanks，now what can I do to solve this problem？

[MarkRivers]

@xia-stan told me this morning that the problem may be the USB version. I think he means the firmware version on the device, and they are looking into how we can update our devices.

[xv8tjc4d]

Thank you everyone for keeping this thread alive! It would be wonderful to have a solution, thank you @MarkRivers

[MarkRivers]

Note that there is a solution, which is simply to run the EPICS IOC on Windows rather than Linux. That works fine, and it is really not difficult to build the IOC for Windows.

[xv8tjc4d]

Mark, Can you please point me to instructions on what to do on Windows? Thank you!

[xv8tjc4d]

Just found it, thanks, https://epics-modules.github.io/dxp/dxpDoc.html#Installing_Windows

[MarkRivers]

This is a link to some instructions: https://docs.epics-controls.org/en/latest/getting-started/installation-windows.html

• I use Microsoft Visual Studio 2022 Community Edition, which is free.
• Strawberry Perl provides both Perl and GnuMake.
• I mount my Linux system from Windows, so I only have a single copy of EPICS base and the synApps modules (seq, asyn, mca, dxp, autosave, etc.) for all of my EPICS builds (Linux, Windows, and vxWorks). You can also install them locally on Windows of course.
• Once you get the tools installed building on Windows is just like Linux, you just use "make".

[1458861693]

I still want to this problem on CentOS7 can be solved, because my others IOC applications are all on CentOS7. I have build Epics Base on Windows10 successfully, but when I build re2c on windows10, it occurred errors. I haven't solve this error yet.

[1458861693]

@MarkRivers , I have build Epics Base and re2c on windows10 successfully, but I failed to build seq-2.2.9, this is the log file by attachment. I use MSYS2 to build this module. log_windows10_seq-2.2.9.txt I have added the include file folder to windows10 system environment variable, but it still occur this error, I'm confused. Could you give me some help, I still want to the problem on CentOS can be solved.

[MarkRivers]

I believe your Visual Studio installation is incomplete. You need to install the SDK. https://stackoverflow.com/questions/52325237/visual-studio-unable-to-find-assert-h

[1458861693]

I have installed all components about C/C++ SDK basically, but it also build failed. I installed MYSY2 to build seq-2.2.9 instead of visual studio, I will try again. Thanks.

[MarkRivers]

assert.h should be part of the C package. Please look for it on your msys2 installation.

[1458861693]

I can find assert.h in my msys2 installation folder, and I added all file folder path which contains assert.h to environment variable, but it still doesn't work(same error with above log file).

[MarkRivers]

I am confused. The error output you attached has these lines:

perl -CSD D:/softIOC/base-7.0.8/bin/windows-x64/mkmf.pl  -m pv.d -I. -I../O.Common -I. -I. -I.. -I../../../include/compiler/msvc -I../../../include/os/WIN32 -I../../../include -ID:/softIOC/base-7.0.8/include/compiler/msvc -ID:/softIOC/base-7.0.8/include/os/WIN32 -ID:/softIOC/base-7.0.8/include        pv.obj ../pv.c
cl          -DUSE_TYPED_RSET     -nologo -FC -D__STDC__=0 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE    -Ox -GL -Oy-   -W3        -MD -DEPICS_BUILD_DLL -DEPICS_CALL_DLL    -I. -I../O.Common -I. -I. -I.. -I../../../include/compiler/msvc -I../../../include/os/WIN32 -I../../../include -ID:/softIOC/base-7.0.8/include/compiler/msvc -ID:/softIOC/base-7.0.8/include/os/WIN32 -ID:/softIOC/base-7.0.8/include        -c ../pv.c
pv.c

Note that is it using -ID:/softIOC/base-7.0.8/include/compiler/msvc and the command to compile is cl, not gcc. That indicates to me that you are using the Visual Studio compiler, not the mingw-w64 GCC compiler?

[1458861693]

oh, I want to build this module by msys2，but the previous error which indicate the cl can't be find, so I added the cl.exe path to environment variable. Maybe My operation is wrong？ I have tried using visual studio, but it failed when build Epics Base, so I give up visual studio. I am so sorry, I'm not familiar with compile process and tools on Windows. Could you tell me how to appoint the compile tool to build the seq-2.2.9 and other Epics modules, Thanks very much.

[MarkRivers]

This is what I see when building pv.c on my system where it works:

cl               
-nologo -FC -D__STDC__=0 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE    
-Ox -GL -Oy-   -W3        -MD -DEPICS_BUILD_DLL -DEPICS_CALL_DLL    
-I. -I../O.Common -I. -I. -I.. 
-I../../../include/compiler/msvc 
-I../../../include/os/WIN32 
-I../../../include 
-IH:/epics-devel/base-7.0.7/include/compiler/msvc 
-IH:/epics-devel/base-7.0.7/include/os/WIN32 
-IH:/epics-devel/base-7.0.7/include           
-c ../pv.c
pv.c
link -nologo -subsystem:windows -dll -LTCG -incremental:no -opt:ref -release  -MACHINE:X64      
-out:pv.dll -implib:pv.lib    pv.obj        
H:/epics-devel/base-7.0.7/lib/windows-x64/ca.lib  
H:/epics-devel/base-7.0.7/lib/windows-x64/Com.lib
   Creating library pv.lib and object pv.exp

This is what you see:

cl          -DUSE_TYPED_RSET     
-nologo -FC -D__STDC__=0 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE    
-Ox -GL -Oy-   -W3        -MD -DEPICS_BUILD_DLL -DEPICS_CALL_DLL    
-I. -I../O.Common -I. -I. -I.. 
-I../../../include/compiler/msvc 
-I../../../include/os/WIN32 
-I../../../include 
-ID:/softIOC/base-7.0.8/include/compiler/msvc 
-ID:/softIOC/base-7.0.8/include/os/WIN32 
-ID:/softIOC/base-7.0.8/include        
-c ../pv.c
pv.c
D:\softIOC\synApps_6_1\support\seq-2-2-9\src\pv\pv.c(1): fatal error C1083: Cannot open include file: “assert.h”: No such file or directory

So our compile command are almost identical. Yours is failing because it cannot find assert.h which is part of Visual Studio. I can think of 2 possible reasons.

• You have not installed the Visual Studio SDK as I said in a previous message.
• You have not executed the vcvarsall.bat script from Visual Studio in this command shell. You must do that for Visual Studio to find everything it needs.

How have you defined EPICS_HOST_ARCH in this shell?

You are very close to having a successful build with Visual Studio. You have built base OK.

When you execute vcvarsall.bat it will define environment variables like this:

IFCPATH=C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\ifc\x64
INCLUDE=C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\include;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\ATLMFC\include;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\VS\include;C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\um;C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\shared;C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\winrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\cppwinrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um

[1458861693]

I set EPICS_HOST_ARCH by "set EPICS_HOST_ARCH=windows-x64" in windows command line tool like my committed log file, and I executed the vcvarsall.bat script before build seq-2.2.9. The error information is different from the above. Maybe you can find my error information from my log file. Thanks! log_windows10_seq-2.2.9.txt

[MarkRivers]

This is the error:

D:/softIOC/workspace/re2c/build/bin -s -b -o lexer.c ../snl.re
process_begin: CreateProcess(NULL, D:/softIOC/workspace/re2c/build/bin -s -b -o lexer.c ../snl.re, ...) failed.
make (e=5): 拒绝访问。
D:/softIOC/synApps_6_1/support/seq-2-2-9/bin/windows-x64/lemon.exe o=. -g ../snl.lem > snl.bnf.tmp
perl -CSD -MExtUtils::Command -e mv snl.bnf.tmp ../O.Common/snl.bnf
perl -CSD ../bnf2txt.pl ../snl.re ../O.Common/snl.bnf > ../O.Common/Syntax.txt
perl -CSD -e '' "Installing generated html ../../../html/./Syntax.txt"
make[3]: *** No rule to make target 'lexer.c', needed by 'lexer.obj'.  Stop.

The initial error is that re2c failed. re2c was supposed to create lexer.c, so the second error is that lexer.c cannot be found.

Perhaps your version of re2c is not working. In 2018 I found a message saying I was using this version: https://sourceforge.net/projects/re2c/files/old/re2c-0.13.5-bin.zip/download

[1458861693]

oh ye, I have build seq-2.2.9 module successfully, the reason is that I don't write "re2c" after this path "D:/softIOC/workspace/re2c/build/bin", the correct path is "D:/softIOC/workspace/re2c/build/bin/re2c". Thank you very much!! I will continue build other modules on my windows10 computer.

[1458861693]

@MarkRivers, I have build some modules of Synapps successfully, I am very excited. But I failed to build sscan module. Can you help me. The log file is committed by attachment. Thanks very much!! log_windows10_sscan-R2-11-3.txt

[MarkRivers]

That log output has error messages in Chinese, so I cannot read them:

D:\softIOC\synApps_6_1\support\sscan-R2-11-3\sscanApp\src\saveData_writeXDR.c(1839): error C2065: “READONLY”: 未声明的标识符
D:\softIOC\synApps_6_1\support\sscan-R2-11-3\sscanApp\src\saveData_writeXDR.c(1839): error C2146: 语法错误: 缺少“;”(在标识符“DBR_VAL”的前面)
D:\softIOC\synApps_6_1\support\sscan-R2-11-3\sscanApp\src\saveData_writeXDR.c(1839): error C2275: “DBR_VAL”: 应为表达式而不是类型
D:\softIOC\synApps_6_1\support\sscan-R2-11-3\sscanApp\src\saveData_writeXDR.c(1839): error C2065: “pval”: 未声明的标识符
D:\softIOC\synApps_6_1\support\sscan-R2-11-3\sscanApp\src\saveData_writeXDR.c(1848): error C2065: “pval”: 未声明的标识符

However, that looks like the error that was fixed in a recent commit to saveData_writeXDR.c: https://github.com/epics-modules/sscan/commit/4e3d564eaaabb14aa2a5fe5dd0141c2f2fcc382f

I suggest you pull the master branch of sscan.

[1458861693]

@MarkRivers Hi, there is a good message that I have build Dxp module and almost most of modules of SynApps successfully on my Windows10 computer. And the Dxp IOC works fine on windows10 computer. Thanks for your help very much. But there are still some errors that I want to solve. My dxp module version is "dxp-R6-0".

First, I failed to build xxx module, I have tried several different version of xxx module, for example, xxx-master, xxx-R6-3 etc. The log file named "log_windows10_xxx-master.txt", I have committed this file by attachment. But it doesn't seem to affect the dxp module's work. log_windows10_xxx-master.txt

Second, there is not a envPaths file in "D:/softIOC/synApps_6_1/support/dxp-R6-0/iocBoot/iocMicroDXP" after dxp module build successfully. So I have to add a envPaths file to this path manually otherwise the IOC can't be start. This is a little strange. But the IOC works fine after I added the envPaths file to this path.

Third, after the Dxp IOC starts, I can start acquiring by press the Start button or Erase/Start button, but when I press the Stop button, acquiring didn't stop. May be my configuration is wrong? My configuration is as follows. And the log file of IOC is also committed by attachment, which named "log_windows10_dxp_ioc_run.txt". log_windows10_dxp_ioc_run.txt

It should be noted that there is no X-ray because of the fault of cooling system.

Last, from the log file "log_windows10_dxp_ioc_run.txt", we can find a error. # Template to copy MCA ROIs to DXP SCAs dbLoadTemplate("roi_to_sca.substitutions") dbLoadTemplate: error opening sub file roi_to_sca.substitutions But there is no "roi_to_sca.substitutions" file in MCA module, may my MCA module version is not right?

Thanks for your help very much, looking forward to your reply. Good luck!

[MarkRivers]

First, I failed to build xxx module,

make[3]: Entering directory 'D:/softIOC/synApps_6_1/support/xxx-master/xxxApp/src/O.windows-x64'
dbdExpand.pl: Can't find file 'simDetectorSupport.dbd'
while reading 'simDetectorSupport.dbd' to create '../O.Common/iocxxxWin64.dbd.d'
Your Makefile may need this dependency rule:
iocxxxWin64.dbd$(DEP): $(COMMON_DIR)/simDetectorSupport.dbd
dbdExpand.pl: Can't find file 'devAcsMotor.dbd'
while reading 'devAcsMotor.dbd' to create '../O.Common/iocxxxWin64.dbd.d'
Your Makefile may need this dependency rule:
iocxxxWin64.dbd$(DEP): $(COMMON_DIR)/devAcsMotor.dbd

Those errors are because you have not built some of the modules xxx uses. simDetector is part of the areaDetector module. devAcsMotor and most of the other errors are for missing modules in the motor package. xxx is designed to be used with or without those. You can comment out those modules from the RELEASE file and to remove the errors. But xxx is just intended to be an example of how to build an IOC that uses many different modules, you don't need it.

Second, there is not a envPaths file in "D:/softIOC/synApps_6_1/support/dxp-R6-0/iocBoot/iocMicroDXP" after dxp module build successfully.

That is because you need to edit the Makefile in that iocMicroDXP directory. Change ARCH to windows-x64 and then do "make clean", "make". That will build envPaths for you.

Third, after the Dxp IOC starts, I can start acquiring by press the Start button or Erase/Start button, but when I press the Stop button, acquiring didn't stop.

I think you need to decrease the poll time. .001 is too fast, the poller is probably using 100% of CPU. Change it to 0.01 and see if that fixes it.

But there is no "roi_to_sca.substitutions" file in MCA module, may my MCA module version is not right?

That is an oversight. You can copy the version from iocSaturn. You will need to edit the file and change the prefix from dxpSaturn: to microDXP:, and you may need to change the number of SCAs. I forget how many the microDXP allows.

[1458861693]

@MarkRivers , I have build Epics Base and all modules of SynApps successfully. Thanks for your help very much! If dxp module can work fine on CentOS, please notice me. Thanks again.

[MarkRivers]

XIA provided a new version of the hqsg-microdxp program that provides additional information on the device. I ran this on my CentOS 9 system today and it produced the attached output.
hqsg-microdxp_new_good.txt

I ran it on the same CentOS9 machine that was repeatedly failing in my previous messages. Strangely it does not fail at all now, I ran it more than 20 times. Both the test program and the real EPICS IOC work fine. I did install the CentOS updates today when it booted, but I sort of doubt that is why it is now working.

@1458861693 and @xv8tjc4d if you download the master branch, rebuild and run the hqsg-microdxp application it will provide XIA with information that may allow them to update your systems to work with Linux.

[1458861693]

@MarkRivers , thanks for your reply, I will download the master branch and rebuild the dxp module on CentOS7. Waiting for my message.

[1458861693]

@MarkRivers , I have rebuild the dxp-master branch and run the hqsg-microdxp application on CentOS7 system, but it still occurs error. Please give me some help to solve this problem, thanks very much. The "START_IOC", "handel.log" file are committed as attachment files. The "START_IOC" has been committed as "START_IOC.txt". handel.log START_IOC.txt

When I run the START_IOC, the output information on terminal are as follows.

[xanes@localhost iocMicroDXP]$ ./START_IOC Configuring the Handel log file. Loading the .ini file. Error encountered! Status = 320

And it didn't notice me to update my system, Is my operation error？

[1458861693]

@MarkRivers , Hi, what should I do to solve this problem on Microdxp? May be I should test the dxp module on CentOS Stream 9? Please give me some help. Thanks very very much!

[xia-stan]

@1458861693 : The error status you posted corresponds to XIA_NO_DETCHANS. Can you post a copy of your ini file and the handel log file produced from that run, please?

[MarkRivers]

I just tested again on the Dell Precision 5860 with CentOS 9 Stream. At least 95% of the time the new version of the hqsg-microdxp test program works fine, like this:

[epics@countach-c9 iocMicroDXP]$ ../../bin/linux-x86_64/hqsg-microdxp KETEK_DPP2_usb2.ini Configuring the Handel log file. Loading the .ini file. **** Begin System Report **** hardware: variant: 13 revision: H8 batch: week: 30 year: 17 sn: '20577' usb: version: 2.0.0.18 pic: version: 32.4.11 dsp: version: 0.5.54 clock_speed_mhz: 40 coderev: 0.5.54 afe: clock_enable: 1 gain: mode: 3 value: 0.000000 nyquist_filter: 2 power_supply: 0 adc_speed_grade: 1 fpga: speed: 4 fippi: count: 1 version: 5.3.9 variant: 0 fippi_0: decimation: 0 variant: 9 decimation: 0 fippi_1: decimation: 36 variant: 1 decimation: 0 fippi_2: decimation: 4 variant: 0 decimation: 0 **** End System Report *** peaking time 0 = 0.100000 peaking time 1 = 0.150000 peaking time 2 = 0.200000 peaking time 3 = 0.250000 peaking time 4 = 0.300000 peaking time 5 = 0.400000 peaking time 6 = 0.500000 peaking time 7 = 0.600000 peaking time 8 = 0.800000 peaking time 9 = 1.000000 peaking time 10 = 1.200000 peaking time 11 = 1.600000 peaking time 12 = 2.000000 peaking time 13 = 2.400000 peaking time 14 = 3.200000 peaking time 15 = 4.000000 peaking time 16 = 4.800000 peaking time 17 = 6.400000 peaking time 18 = 8.000000 peaking time 19 = 9.600000 peaking time 20 = 12.800000 peaking time 21 = 16.000000 peaking time 22 = 19.200000 peaking time 23 = 24.000000 peaking time 0 = 0.100000 peaking time 1 = 0.150000 peaking time 2 = 0.200000 peaking time 3 = 0.250000 peaking time 4 = 0.300000 peaking time 5 = 0.400000 peaking time 6 = 0.500000 peaking time 7 = 0.600000 peaking time 8 = 0.800000 peaking time 9 = 1.000000 peaking time 10 = 1.200000 peaking time 11 = 1.600000 peaking time 12 = 2.000000 peaking time 13 = 2.400000 peaking time 14 = 3.200000 peaking time 15 = 4.000000 peaking time 16 = 4.800000 peaking time 17 = 6.400000 peaking time 18 = 8.000000 peaking time 19 = 9.600000 peaking time 20 = 12.800000 peaking time 21 = 16.000000 peaking time 22 = 19.200000 peaking time 23 = 24.000000 Started run. Sleeping... Got run data libusb: warning [libusb_exit] device 2.4 still referenced libusb: warning [libusb_exit] device 2.3 still referenced libusb: warning [libusb_exit] device 2.2 still referenced libusb: warning [libusb_exit] device 2.1 still referenced libusb: warning [libusb_exit] device 1.4 still referenced libusb: warning [libusb_exit] device 1.7 still referenced libusb: warning [libusb_exit] device 1.6 still referenced libusb: warning [libusb_exit] device 1.5 still referenced libusb: warning [libusb_exit] device 1.3 still referenced libusb: warning [libusb_exit] device 1.9 still referenced libusb: warning [libusb_exit] device 1.2 still referenced libusb: warning [libusb_exit] device 1.1 still referenced

However, perhaps 5% of the time I get error 4144:

[epics@countach-c9 iocMicroDXP]$ ../../bin/linux-x86_64/hqsg-microdxp KETEK_DPP2_usb2.ini Configuring the Handel log file. Loading the .ini file. Error encountered! Status = 4144

One time I got error 4002:

[epics@countach-c9 iocMicroDXP]$ ../../bin/linux-x86_64/hqsg-microdxp KETEK_DPP2_usb2.ini Configuring the Handel log file. Loading the .ini file. Error encountered! Status = 4002

After the 4002 error I continuously get error 4001 until I power-cycle the MicroDXP. Disconnecting and reconnecting the USB cable is not sufficient to reset the error.

[epics@countach-c9 iocMicroDXP]$ ../../bin/linux-x86_64/hqsg-microdxp KETEK_DPP2_usb2.ini Configuring the Handel log file. Loading the .ini file. Error encountered! Status = 4001

[1458861693]

@xia-stan @MarkRivers , Thanks for your reply. I will test again later and commit Handel.log file and the ini file at this issue.

[1458861693]

@xia-stan @MarkRivers , I have executed the follow command on terminal and the output are as follows.

[xanes@localhost iocMicroDXP]$ ../../bin/linux-x86_64/hqsg-microdxp KETEK_DPP2_usb2.ini Configuring the Handel log file. Loading the .ini file. Error encountered! Status = 355

The handel.log file and KETEK_DPP2_usb2.ini has been committed as attachment. handel.log KETEK_DPP2_usb2.ini.txt Looking forward to your reply! Thanks.

[xia-stan]

@1458861693 : According to the log file your version of handle was compiled to only support the Saturn device (Interface: EPP + Board: Saturn). The build compiled the microDXP code, but no interface to use for communication. I suspect there may be other build errors since I see the STJ device code being compiled without PLX support. We only offer STJ support on Windows. The microDXP requires the USB2 or Serial communication protocol to be enabled. See the log file from one of my local tests:

If you're using the handle repository to compile the code, then this failure mode is easy to encounter. I'm working on fixing the handel SCons scripts to prevent this type of error. If you're using another build system, then I will be unable to assist further.

[MarkRivers]

@1458861693 handelSrc/Makefile contains these lines:

USR_CFLAGS_Linux += -DEXCLUDE_XMAP -DEXCLUDE_PLX -DLINUX -fcommon
# For debugging USB problems
#USR_CFLAGS       += -DXERXES_TRACE_IO

ifneq ($(LINUX_USB_INSTALLED), YES)
USR_CFLAGS_Linux    += -DEXCLUDE_USB -DEXCLUDE_USB2 -DEXCLUDE_XMAP -DEXCLUDE_PLX -DEXCLUDE_MERCURY

So if LINUX_USB_INSTALLED is not YES then it will exclude USB2, That is probably what happened to you if you downloaded a new version of dxp. The distributed version of configure/CONFIG_SITE contains these lines;

# Uncomment this line if you have libusb-0.1 installed on your Linux system
#LINUX_USB_INSTALLED=YES

You need to uncomment that line to tell the build system you have the usb libraries installed. Do that and rebuild dxp.

[1458861693]

@xia-stan , I just use dxp module in epics-module repository on GitHub. And handle source code may be included in it. @MarkRivers , I have uncommented "#LINUX_USB_INSTALLED=YES" this line in configure/CONFIG_SITE as your suggestions and rebuild dxp module. And I tested it again on my CentOS7 computer just now. Unfortunately, it failed again. And the error is same as above that xia-stan said. I have committed it named Handel.log.txt. handel.log.txt

But when I tested dxp-R5-0 module on CentOS Stream8 virtual machine in VMWare, It works OK! And I have tested several times, it was OK all times. Of course, I have also uncommented this line "#LINUX_USB_INSTALLED=YES". The IOC start message named IOC_Started_Message.txt was also committed as attachment. IOC_Start_Message.txt

Looking forward to your reply to solve this problem. And I will test dxp-master branch on my CentOS Stream8 physical machine several days later.

[MarkRivers]

And I tested it again on my CentOS7 computer just now. Unfortunately, it failed again. And the error is same as above that xia-stan said.

@1458861693 please attach the complete output when you rebuild the dxp module. It is building fine for me on CentOS 7. I think something is still wrong with your configuration.

This is an example of the output when I build udxp.c in handelSrc. Note that it does not include the flags -DEXCLUDE_USB or -DEXCLUDE_USB2.

/usr/bin/gcc  -D_GNU_SOURCE -D_DEFAULT_SOURCE          -D_X86_64_ -DUNIX  -Dlinux      -O3 -g   -Wall -Werror-implicit-function-declaration    -DEXCLUDE_XUP -DEXCLUDE_SERIAL -DEXCLUDE_VEGA -DEXCLUDE_UDXPS -DXIA_STATIC_BUILD -DEXCLUDE_XMAP -DEXCLUDE_PLX -DLINUX -fcommon  -mtune=generic     -m64  -fPIC -I. -I../O.Common -I. -I. -I.. -I../../../include/compiler/gcc -I../../../include/os/Linux -I../../../include      -I/corvette/home/epics/devel/seq-2-2-5/include  -I/corvette/home/epics/devel/mca-7-9/include/os/Linux -I/corvette/home/epics/devel/mca-7-9/include   -I/corvette/home/epics/devel/dxp-6-0/include      -I/corvette/home/epics/devel/asyn-4-43/include  -I/corvette/home/epics/devel/areaDetector-3-13/ADSupport/include/os/Linux -I/corvette/home/epics/devel/areaDetector-3-13/ADSupport/include   -I/corvette/home/epics/devel/areaDetector-3-13/ADCore/include  -I/corvette/home/epics/devel/autosave-5-10-2/include/os/Linux -I/corvette/home/epics/devel/autosave-5-10-2/include   -I/corvette/home/epics/devel/busy-1-7-3/include   -I/corvette/home/epics/devel/calc-3-7-4/include   -I/corvette/home/epics/devel/sscan-2-11-5/include  -I/corvette/home/epics/devel/devIocStats-3-1-16/include/os/Linux -I/corvette/home/epics/devel/devIocStats-3-1-16/include -I/corvette/usr/local/epics-devel/base-7.0.8/include/compiler/gcc -I/corvette/usr/local/epics-devel/base-7.0.8/include/os/Linux -I/corvette/usr/local/epics-devel/base-7.0.8/include        -MM -MF udxp.d  ../udxp.c

This is the output when it links hqsg-microdxp in the src/ directory. Note near the end of the line it is linking with -lusb.

/usr/bin/g++ -o hqsg-microdxp -Wl,-Bstatic -L/home/epics/devel/dxp-6-0/lib/linux-x86_64 -L/corvette/home/epics/devel/areaDetector-3-13/ADCore/lib/linux-x86_64 -L/corvette/home/epics/devel/areaDetector-3-13/ADSupport/lib/linux-x86_64 -L/corvette/home/epics/devel/asyn-4-43/lib/linux-x86_64 -L/corvette/home/epics/devel/autosave-5-10-2/lib/linux-x86_64 -L/corvette/home/epics/devel/busy-1-7-3/lib/linux-x86_64 -L/corvette/home/epics/devel/calc-3-7-4/lib/linux-x86_64 -L/corvette/home/epics/devel/devIocStats-3-1-16/lib/linux-x86_64 -L/corvette/home/epics/devel/seq-2-2-5/lib/linux-x86_64 -L/corvette/home/epics/devel/sscan-2-11-5/lib/linux-x86_64 -L/corvette/usr/local/epics-devel/base-7.0.8/lib/linux-x86_64 -Wl,-rpath,/home/epics/devel/dxp-6-0/lib/linux-x86_64 -Wl,-rpath,/corvette/home/epics/devel/areaDetector-3-13/ADCore/lib/linux-x86_64 -Wl,-rpath,/corvette/home/epics/devel/areaDetector-3-13/ADSupport/lib/linux-x86_64 -Wl,-rpath,/corvette/home/epics/devel/asyn-4-43/lib/linux-x86_64 -Wl,-rpath,/corvette/home/epics/devel/autosave-5-10-2/lib/linux-x86_64 -Wl,-rpath,/corvette/home/epics/devel/busy-1-7-3/lib/linux-x86_64 -Wl,-rpath,/corvette/home/epics/devel/calc-3-7-4/lib/linux-x86_64 -Wl,-rpath,/corvette/home/epics/devel/devIocStats-3-1-16/lib/linux-x86_64 -Wl,-rpath,/corvette/home/epics/devel/seq-2-2-5/lib/linux-x86_64 -Wl,-rpath,/corvette/home/epics/devel/sscan-2-11-5/lib/linux-x86_64 -Wl,-rpath,/corvette/usr/local/epics-devel/base-7.0.8/lib/linux-x86_64          -rdynamic -m64         hqsg-microdxp-8ff2aa54.o    -lhandel -lNDPlugin -lADBase -lqsrv -lntndArrayConverter -lnt -lpvDatabase -lpvAccessIOC -lpvAccessCA -lpvAccess -lpvData -lnetCDF -lMagick++ -lcoders -lMagick -ljbig -ljp2 -lbzlib -lpng -lwebp -llcms -lttf -lwmf -lfilters -lnanohttp_stream -ltiff -lxml2 -lNeXus -lhdf5 -lhdf5_hl -lbitshuffle -lblosc -lszip -lzlib -ljpeg -lasyn -lautosave -lbusy -lcalc -ldevIocStats -lsscan -lseq -lpv -ldbRecStd -ldbCore -lca -lCom -Wl,-Bdynamic -lusb -lboost_system -lX11 -lXext -lpthread   -lreadline -lm -lrt -ldl -lgcc

[1458861693]

@MarkRivers This is the rebuild output information of dxp-module. [Uploading build_output.txt…]()

[MarkRivers]

@1458861693 that link is not working for me. It just takes me back to this page itself, not to the build output.

[MarkRivers]

One possible problem is that LINUX_USB_INSTALLED could be defined not only in support/dxp/configure/CONFIG_SITE but also in support/configure/CONFIG_SITE, i.e. in the top-level configure directory. If it is defined in the top-level support that will override what you have in dxp. Make sure it is defined correctly in support/configure/CONFIG_SITE.

[xia-stan]

@MarkRivers : It looks like your flags are a little off from what I expect based on the output using SCons. Here's what I get when only building microDXP + USB2 support.

Compile command from SCons for udxp.c

gcc -o scons-out/dbg-x64/obj/src/udxp.o -c -pipe -fPIC -Wall -fcommon -O0 -g -g -O0 -DOS_LINUX=OS_LINUX -DEXCLUDE_USB -DEXCLUDE_SERIAL -DEXCLUDE_EPP -DEXCLUDE_PLX -Iinc src/udxp.c

Compile command from SCons for udxp_psl.c

gcc -o scons-out/dbg-x64/obj/src/udxp_psl.o -c -pipe -fPIC -Wall -fcommon -O0 -g -g -O0 -DOS_LINUX=OS_LINUX -D_DEBUG -DEXCLUDE_USB -DEXCLUDE_SERIAL -DEXCLUDE_EPP -DEXCLUDE_PLX -DEXCLUDE_SATURN -DEXCLUDE_XMAP -DEXCLUDE_STJ -DEXCLUDE_MERCURY -DEXCLUDE_UDXPS -DEXCLUDE_XUP -Iinc src/udxp_psl.c

Is it possible to pre-compile the handel library using our build system and then link it into EPICS? That might shed some light on what's happening. For reference here's the compilation output for a debug build on a Debian 10 machine. support-1532_usb2-udxp_debian10.log

[1458861693]

@MarkRivers , This is the rebuild output information of dxp module. I have committed it again. build_output.txt Is there any errors? Thanks very much.

[xia-stan]

@1458861693: Do you mind adding VERBOSE=1 to your make command? That should provide all the gory details of what make's doing. The full command would be

VERBOSE=1 make CFLAGS="-std=c99"

You may also need to execute a make clean so that the compilation actually kicks off.

I see references to xMAP devices in the build_output, which are only supported in Windows. Maybe some flags aren't getting set properly?

[MarkRivers]

@1458861693 your output does not include the build of handelSrc. At the top level of dxp you need to type:

make clean
make

Please attach the complete output of that.

[MarkRivers]

Is it possible to pre-compile the handel library using our build system and then link it into EPICS?

That would be difficult because it requires installing additional tools, or providing pre-built libraries for many versions of Linux and Windows.

I have been using the EPICS build system (gnumake) for more than 20 years to build the Handel library with no issues. I am quite sure that @1458861693 simply has a configuration problem telling the system to include USB support.

[1458861693]

@1458861693: Do you mind adding VERBOSE=1 to your make command? That should provide all the gory details of what make's doing. The full command would be

VERBOSE=1 make CFLAGS="-std=c99"

You may also need to execute a make clean so that the compilation actually kicks off.

I see references to xMAP devices in the build_output, which are only supported in Windows. Maybe some flags aren't getting set properly?

@MarkRivers ,@xia-stan ,This is the new rebuild output information. But it failed to build. build_output_2.txt And I can't find "xia_xup.h" in dxp directory.

[xia-stan]

I didn't mean to imply that compiling against a pre-build handle library was a long term solution. It's a temporary solution to independently check proper build flag inclusion. The XW library and associated XUP support is only available on Windows systems. This confirms @MarkRivers's suspicion that there's a configuration problem.

[1458861693]

One possible problem is that LINUX_USB_INSTALLED could be defined not only in support/dxp/configure/CONFIG_SITE but also in support/configure/CONFIG_SITE, i.e. in the top-level configure directory. If it is defined in the top-level support that will override what you have in dxp. Make sure it is defined correctly in support/configure/CONFIG_SITE.

@MarkRivers , I also have uncommented "LINUX_USB_INSTALLED = YES" this line and "export LINUX_USB_INSTALLED" this line in support/configure/CONFIG_SITE.

[MarkRivers]

@1458861693 something is seriously wrong with your build of handelSrc. In your build output file this is the first part of the compile command for the first file, md_linux.c, up to the -I../O.Common.

/usr/bin/gcc  -D_GNU_SOURCE -D_DEFAULT_SOURCE           -D_X86_64_  -DUNIX  -Dlinux    -std=c99 -I. -I../O.Common 

This is what I see when compiling that file:

/usr/bin/gcc  -D_GNU_SOURCE -D_DEFAULT_SOURCE          -D_X86_64_ -DUNIX  -Dlinux      -O3 -g   -Wall -Werror-implicit-function-declaration    -DEXCLUDE_XUP -DEXCLUDE_SERIAL -DEXCLUDE_VEGA -DEXCLUDE_UDXPS -DXIA_STATIC_BUILD -DEXCLUDE_XMAP -DEXCLUDE_PLX -DLINUX -fcommon  -mtune=generic     -m64  -fPIC -I. -I../O.Common 

Note that your command is missing all of the -DEXCLUDE options. This does not make any sense, because handelSrc/Makefile contains these 2 lines:

USR_CFLAGS       += -DEXCLUDE_XUP -DEXCLUDE_SERIAL -DEXCLUDE_VEGA -DEXCLUDE_UDXPS
USR_CFLAGS_Linux += -DEXCLUDE_XMAP -DEXCLUDE_PLX -DLINUX -fcommon

So when you compile on Linux all of those flags should be set on the gcc line. They are for me, but they are not for you.

Have you modified handelSrc/Makefile?

Is your dxp directory a git clone from Github? If so, then please send the output of this command at the top-level of dxp

git status

This is what I see:

(base) [epics@corvette dxp]$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   configure/CONFIG_SITE
        modified:   configure/RELEASE

So the only files modified from the Github distribution are configure/CONFIG_SITE and configure/RELEASE.

Also, when you build you are using this line: VERBOSE=1 make CFLAGS="-std=c99"

I don't think that is the correct way to set the VERBOSE flag, but that is not important it should not be needed.

Why are you passing the CFLAGS="-std-c99". That is not necessary. Actually that is probably why it is overriding all of the USR_CFLAGS in the Makefile. Please build with the simple command "make".

[MarkRivers]

@1458861693 I suspect if you build without the CFLAGS argument it will work OK.