syntax question for cli (linux) command

I have found that for any command that takes more than 1 argument the string after the colon needs to be in quotes.

./dgate --grabimagesfromserver:"radcoord,20070319"

The AETITLE may also be case sensitive, but I have not checked this.

Does radcoord know conquest?

Marcel

If I grab missing images by one Conquest (v1.4.14) from another Conquest it works perfectly:
dgate --grabimagesfromserver:AETITLE,YYYYMMDD

However, when I want to compare and grab unarchived pictures and studies from GE CT and MRI AW workstations, then --grab... doesn't work, just writes that "grab is finished" but there may some pictures and studies missing.
Then I try to grab directly from CT or MRI console workstations when dgate gives an error:
*** Grab - failed to connect for C-FIND

Using K-PACS I can remotely query GE CT and MRI workstations and consoles and move missing studies to Conquest. Interesting to point that CT and MRI consoles workstations don't even know K-PACS AEt.
Only restriction querying CT console by K-PACS is that you shouldn't apply 'CT' modality filter, otherwise K-PACS makes query and shows study list.

Hi,

are you sure the CT and MRI are not configured to know Kpacs? It is very seldom that such systems respond to queries from systems that are not reqistered. The conquest behavior is what you expect: cannot connect as long as CT and MRI do not know conquest's AS title - and certainly cannot move (they would not know where (IP and port) to send the data to).

Marcel

Hello Marcel,

I'm definetely sure that CT and MRI know Conquest's AEt definitions and don't know KPACS's ones.
Our CT and MRI are configured to automatically send all studies (by study) to Conquest but due to some circumstances not all of studies or series reach the Conquest.

My problem is that Conquest cannot grab missing pictures from GE CT and MRI automatically.
That is why I use KPACS to query and grab missing studies from CT and MRI manually.

In KPACS I haved defined CT, MRI and Conquest AEts.
With such setup KPACS cannot open any CT or MRI study, but using KPACS I can:
1. query CT and MRI to see studies list and then
2. initiate C-move from CT to Conquest

In this case in Conquests logs there are only references to C-Move associations directly between CT and Conquest, no any reference to KPACS.

Regards

Hi,

GrabImagesFromServer initiates a StudyRootQuery at that point (and later a StudyRootRetrieve). It is very strange that that does not work. Can you do a StudyRootQuery and Move from the conquest GUI to the CT or MRI? That should be identical.

Marcel

No, I cannot do StudyRootQuery neither StudyQuery (with or without study date defined) to GE CT or MRI:

*** DICOM query error (patient ID = ) : Unable to connect
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Total of -1 item(s) found

The same query to another Conquest return a study list.
But K-PACS (v 1.0.1-v1.6) can do StudyQuery (or StudyRootQuery) to CT and MRI, so what could be the difference?

urry

Hi,

at least we have located the problem. I guess it must be the CT and MRI config. You probably don't have permission to query them.

Marcel

Hello Marcel,
GE CT and MRT DICOM setup is quite primitive, no firewall or IP bloking, etc.

Using KPACS (which is not configured in CT and MRI DICOM setup) I can query CT and MRI from any arbitrary PC within hospital network, but Conquest (which is configured) cannot.

However, from KPACS I can move studies from CT and MRI only to DICOM nodes which are configured in CT and MRI DICOM setup.

Regards,
urry

Hi,

can you try different query types in the dropdown list of the conquest GUI?

Marcel

Yes, I've tried all query levels:

STUDY level query makes Conquest UI stuck and application doesn't response.
Then the only way to continue - to close UI and open it again.

All other query levels except for STUDY return:
*** DICOM query error (patient ID = ) : Unable to connect
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Total of -1 item(s) found

Hi,

this seems like a low level problem. I suggest using a network sniffer (test.exe in dicomlib1414 could be used as well) to compare byte by byte the data sent by kpacs and conquest.

How to use test.exe from dicomlib1414.zip: This command line forwards PORT (on localhost) to host:port (e.g., use host:port of the CT), and logs all dicom traffic (use loglevel=3 or 4).

test -fe PORT host port loglevel

When you configure k-pacs and conquest to query localhost:PORT, you can sniff what is going on.

Alternatively, you can configure conquest exactly the same as k-pacs and see what happens then. Is k-pacs running on the same machine as conquest? That would exclude firewall issues etc.

Marcel

Hi,
I've configured Conquest v1414 on the same PC as kpacs and result is the same. So, that can't be firewall issues.

Comparing StudyRootQuery made by Conquest (AEt=CONQUESTSRV_1) and Kpacs to another Conquest (AEt=CONQUESTSRV_0) I've found the following differences:
note below that CONQUEST is making StudyRootQuery containing of only four DICOM tags, but in KPACS query there are significally more tags. Maybe this matters?

1.StudyRootQuery from Conquest_1 to Conquest_0:

UPACS THREAD 13156: STARTED AT: Wed Mar 25 23:07:23 2009
A-ASSOCIATE-RQ Packet Dump
Calling Application Title : "CONQUESTSRV_1 "
Called Application Title : "CONQUESTSRV_0 "
Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
Number of Proposed Presentation Contexts: 4
Presentation Context 0 "1.2.840.10008.5.1.4.1.2.1.1" 1
Presentation Context 1 "1.2.840.10008.5.1.4.1.2.2.1" 1
Presentation Context 2 "1.2.840.10008.5.1.4.1.2.3.1" 1
Presentation Context 3 "1.2.840.10008.5.1.4.31" 1
Server Command := 0020
Message ID := 0003
0000,0002 28 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.2.2.1"
0000,0100 2 US CommandField 32
0000,0110 2 US MessageID 3
0000,0700 2 US Priority 0
0000,0800 2 US DataSetType 258
(StudyRootQuery) search level: STUDY
0008,0020 8 DA StudyDate "20090324"
0008,0052 6 CS QueryRetrieveLevel "STUDY "
0010,0010 0 PN PatientName (empty)
0010,0020 0 LO PatientID (empty)
Query On Study
Issue Query on Columns: DICOMStudies.StudyDate, DICOMStudies.PatientNam, DICOMStudies.PatientID
Values: DICOMStudies.StudyDate = '20090324'
Tables: DICOMStudies
Sorting (DICOMStudies.PatientNam) DoSort := 1
Query Distinct Tables: DICOMStudies
Columns : DICOMStudies.StudyDate, DICOMStudies.PatientNam, DICOMStudies.PatientID
Where : DICOMStudies.StudyDate = '20090324'
Order : DICOMStudies.PatientNam
Records = 0
C-Find (StudyRoot) located 0 records
UPACS THREAD 13156: ENDED AT: Wed Mar 25 23:07:23 2009
UPACS THREAD 13156: TOTAL RUNNING TIME: 0 SECONDS

2.StudyRootQuery from KPACS to Conquest_0:

UPACS THREAD 13154: STARTED AT: Wed Mar 25 22:24:24 2009
A-ASSOCIATE-RQ Packet Dump
Calling Application Title : "KPACS "
Called Application Title : "CONQUESTSRV_0 "
Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
Number of Proposed Presentation Contexts: 1
Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1
Server Command := 0020
Message ID := 0003
0000,0002 28 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.2.2.1"
0000,0100 2 US CommandField 32
0000,0110 2 US MessageID 3
0000,0700 2 US Priority 0
0000,0800 2 US DataSetType 258
(StudyRootQuery) search level: STUDY
0008,0020 18 DA StudyDate "20090324-20090324"
0008,0030 0 TM StudyTime (empty)
0008,0050 0 SH AccessionNumber (empty)
0008,0052 6 CS QueryRetrieveLevel "STUDY"
0008,0061 0 UN (empty)
0008,0080 0 LO InstitutionName (empty)
0008,0090 0 PN ReferringPhysicianNa (empty)
0008,1030 0 LO StudyDescription (empty)
0010,0010 0 PN PatientName (empty)
0010,0020 0 LO PatientID (empty)
0010,0030 0 DA PatientBirthDate (empty)
0010,0040 0 CS PatientSex (empty)
0010,1010 0 AS PatientAge (empty)
0020,000d 0 UI StudyInstanceUID (empty)
0020,0010 0 SH StudyID (empty)
Query On Study
Failed on VR Search: 0008 0080
(testing phase) - ignored
Issue Query on Columns: DICOMStudies.StudyDate, DICOMStudies.StudyTime, DICOMStudies.AccessionN, DICOMStudies.StudyModal, DICOMStudies.ReferPhysi, DICOMStudies.StudyDescr, DICOMStudies.PatientNam, DICOMStudies.PatientID, DICOMStudies.PatientBir, DICOMStudies.PatientSex, DICOMStudies.PatientsAg, DICOMStudies.StudyInsta, DICOMStudies.StudyID
Values: DICOMStudies.StudyDate >= '20090324' and DICOMStudies.StudyDate <= '20090324'
Tables: DICOMStudies
Sorting (DICOMStudies.PatientNam) DoSort := 1
Query Distinct Tables: DICOMStudies
Columns : DICOMStudies.StudyDate, DICOMStudies.StudyTime, DICOMStudies.AccessionN, DICOMStudies.StudyModal, DICOMStudies.ReferPhysi, DICOMStudies.StudyDescr, DICOMStudies.PatientNam, DICOMStudies.PatientID, DICOMStudies.PatientBir, DICOMStudies.PatientSex, DICOMStudies.PatientsAg, DICOMStudies.StudyInsta, DICOMStudies.StudyID
Where : DICOMStudies.StudyDate >= '20090324' and DICOMStudies.StudyDate <= '20090324'
Order : DICOMStudies.PatientNam
Records = 0
C-Find (StudyRoot) located 0 records
UPACS THREAD 13154: ENDED AT: Wed Mar 25 22:24:25 2009
UPACS THREAD 13154: TOTAL RUNNING TIME: 1 SECONDS

Hi,

They look very much the same. The #tags should not matter. You can query whatever fields you like.

I notice one difference in this line:

0008,0052 6 CS QueryRetrieveLevel "STUDY"

kpacs has this string without a space and conquest with a space (the latter I believe is correct to make the string even length).

Marcel