So I tried to connect it via pylon-camera-server, but I couldn't receive any images from camera-server.
Finally, I concluded there was no compatibility between them.
So we need to prepare a compatible camera-server software with Basler a2A5328-4gmPRO by ourselves if it will be really used.
From the view point of effort for software development, it might be better to reconsider the camera model selection.
-----
KAGRA's GigE system consists from Basler acA640-120gm and it's based on SDK/GenlCam v1.x. And also, pylon-camera-server supports only cameras based on v1.x. On the other hand, Basler a2A5328-4gmPRO is based on SDK/GenlCam v2.x. The camera properties and the definition of members in the camera class are different between v1.x and v2.x. So pylon-camera-server cannot access camera properties at the beginning of the server launching though it can access the camera device itself.
To launch camera-server, developing a new camera server software or writing wrapper classes to absorb version discrepancy for all required methods and attributes of all different classes are required. If a2A5328-4gmPRO or another v2.x cameras are only solution which satisfies the specification requirement, we will need to make the decision to allocate time to this software development/maintenance. Personally, I think it would be better to reconsider the model selection if there is another solution in v1.x camera series. More detailed consideration can be found in https://gwwiki.icrr.u-tokyo.ac.jp/JGWwiki/KAGRA/Subgroups/DGS/Projects/Cam/BaslerV2Camera.
Yesterday, I temporary installed the gigE camera which is planed to use in the new TCam system.
I tried using the a2A5328-4gmPRO camera while it was occupying k1cam1.
But high-resolution and/or high-bit-depth recording still failed.
So using dedicated camera server doesn't become a solution for this issue
And also, either an upgrade of the network capacity or an allocation of dedicated bandwidth seems to be necessary.
-----
Bottleneck investigation
To isolate a network capacity issue from a server capacity issue, I moved all acA640-120gm cameras to k1cam0 and k1cam2, then tested a2A5328-4gmPRO while k1cam1 exclusively occupied by it. But capturing high-resolution and/or high-bit-depth images was still failed. Increasing buffer size of NIC from 256kB to 4096kB (upper limit) by ethtool didn't change a situation. In this configuration, a25328-4gmPRO should be able to occupy 1Gbps band-width on the NIC of k1cam1. And also, this situation isn't probably improved by using 10GigE NIC for k1cam1 because NIC of a25328-4gmPRO is 1GbE.
These facts suggest that a current limitation is actual throughput of a network path which can be occupied by a2A5328-4gmPRO. (I haven't isolated just a bandwidth issue from buffer size issue of each network switch.) Current connection of the CAM network is shown in Fig.1. Though the core camera switch in the server room on which all traffic concentrates is 10GigE one, edge switches except at IOO and connections are 1GbE. (Because all cameras in the corner station were connected from IOO rack in the past, only the edge switch at IOO is 10GigE one.) acA640-120gm which is main cameras for KAGRA GigE system is used with 640x480 as resolution, 8bit depth (Mono8) and 25fps. So ~60Mbps per 1 camera is required and 1Gbps bandwidth is enough to stably use 12-13 cameras (corresponding to ~70% of full bandwidth) and managing 18 cameras with 2 camera servers and one 10GigE core switch is sufficient.
a2A5328-4gmPRO is designed as using almost full width of 1Gbps to send caputured images (It's natural behavior because if bandwidth is limited as slower than 1Gbps, a risk of a connection time-out increases for high-resolution cameras such as a2A5328-4gmPRO.) So sharing bandwidth of 1GbE with another devices is not proper configuration for a2A5328-4gmPRO. If network paths will be shared, the CAM network should be upgraded to 10GigE for at least the shared paths with a2A5328-4gmPRO. Another solution is connecting a2A5328-4gmPRO to the core switch in the server room directly. But it may be more tough work than preparing a dedicated TCam server physically near a2A5328-4gmPRO.
Simple camera server application for a2A5328-4gmPRO
To capture images easily for this investigation, I prepared a simple camera server application as /kagra/camera/test-a2A5328-4gmPRO/test_CameraServer.py. It runs on one of camera servers (currently k1cam1) and listens various requests from CDS-workstations via the client application as /kagra/camera/test-a2A5328-4gmPRO/test_CameraClient.py. Because this server application keeps a connection to camera devices (keeping camera.Open()) same as camlan- and pylon-camera-server, this server application must be stopped before another applications connect to same camera devices. This application is now managed by the systemd in the user slice. So it can be stopped by a following command on k1cam1.
> systemctl --user stop test_CameraServer.service
