Unfortunately this kind of thing almost always requires debugging logs from both sides, or even a network packet sniffer. Keep bugging the PACS guy I guess.
In the meantime sometimes it’s easier to use dcmtk directly for debugging. Here are some notes about how to use the dcmtk command line utilities directly to do a a CFIND and you can also use the movescu command to initiate a CMOVE transfer. Internally Slicer uses the storescp command so you can look in the task manager to see the command line arguments when you have the listener running.
It should be visible on the one you get with Control-Alt-Delete I have (Process Explorer installed as my task manager so can’t check easily how to see the command line parameters in the default one but I’m pretty sure it’s possible). Really all you will see is the port number that it is using, which is the one you set in the dialog, and the temp directory where images will be stored. So maybe not all that important, but just more background info for debugging.
If you are using the CGET option the code will emit progress as it goes through the steps and you can see which step fails. It’s what you would see in the progress dialog in the GUI version of CGET.
Had a few days of wrestling with our hospital internal PACS concerning the above-mentioned problems.
Interestingly I made some progress (without the PACS guy):
Then I needed to set the environment variable DCMDICTPATH to the full path of “dicom.dict” file in the installation, which contains a full list of DICOM tag and value types.
From cmd line and after many failed scripts I was able to get correct C-FIND queries from the GEPACS by (all sensible information changed)
Received about 2.8 GB of valid data and was able to import and load that to Slicer.
So principally it works, just not from python, this is just the beginning