Posts by kmarkfield

Thanks for the reply, Marcel.

I actually think I've discovered the problem. I did notice it was a low-level socket call, so I figured it was a server issue. Before getting too deep in to it, I noticed that one device was sending studies as 1 association per image. This device was also on the LAN and running 4 threads simultaneously, so it was creating thousands of threads in no time at all. Once we changed the sending device to send 1 association per study, the error has not returned.

For others that may receive this problem, there is also some guidance from Microsoft. They suggest editing the registry to increase the maximum user port (5000 by default) and possibly the Thread Wait Timeout value.

Hi Marcel,

Can you elaborate on the fix for "out of memory"? I am seeing this error during Q/R. What does dgate do when it detects that an out of memory error will occur? Thanks!

I'm using v1.4.14 and after hours of running, dgate will crash with the error message "***Error in Accept() function call." There doesn't seem to be a pattern (number of associations, number of hours running, etc.) to this.

I didn't see any errors in the Windows Event Viewer or any real details in the log output. Any ideas or recommendations? Thanks in advance!

I've managed to figure out *why* the C-MOVE is failing!

I was playing with the debug level and finally got the following output:

Issue Query on Columns: DICOMImages.TransferSy, DICOMImages.SOPClassUI, DICOMImages.SOPInstanc, DICOMStudies.StudyInsta,DICOMImages.ObjectFile,DICOMImages.DeviceName
Values: DICOMImages.TransferSy = '1.2.840.10008.1.2.1' and DICOMStudies.StudyInsta = '1.2.276.0.7230010.3.1.2.0.3367526178.2440.1168283213.2' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst
Tables: DICOMImages, DICOMSeries, DICOMStudies
Records = 0
C-Move (StudyRoot)

Obviously, you can see that the query is including TransferSyntax. The reason is that I added that DICOM tag to my dicom.sql file to write the transfer syntax of each image.

The problem is that it's not matching the TransferSyntax value. Here's what I'm guessing I can do:

1. Remove the TransferSyntax field from DICOMImages. This would obviously be the quick and dirty (and easiest) solution.
2. Change the proposed Transfer Syntax in my C-MOVE request. This would work assuming that every image had the same Transfer Syntax (which may or may not be true). I'd also have to parse out the Transfer Syntax value from the C-FIND request, but again, that would really be showing a Study level Transfer Syntax.
3. Figure out a way (this is where Marcel comes in! ) to exclude certain keys from the QueryOnImage command or a way to 'OR' similar keys.

I've definitely done this to myself by adding the Transfer Syntax field to my DICOMImages table. Any ideas would be greatly appreciated, otherwise i'll be stuck with the Quick and Dirty solution.

Keith

Hi Marcel,

Here's the output with DebugLevel at 3 (i also went up to 5 and saw no difference).

UPACS THREAD 3: STARTED AT: Thu Mar 22 15:24:14 2007
A-ASSOCIATE-RQ Packet Dump
Calling Application Title : "KEITH "
Called Application Title : "ENCOMPASS "
Application Context : "1.2.840.10008.3.1.1.1"
Number of Proposed Presentation Contexts: 2
Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1"
Presentation Context 1 "1.2.840.10008.5.1.4.1.2.2.2"
Server Command := 0021
C-Move Destination: "KEITH "
0000,0002 28 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.2.2.2"
0000,0100 2 US CommandField 33
0000,0110 2 US MessageID 1
0000,0600 6 AE MoveDestination "KEITH "
0000,0700 2 US Priority 0
0000,0800 2 US DataSetType 1
0002,0010 19 UI TransferSyntaxUID "1.2.840.10008.1.2.1"
(QualifyOn) (mapped) IP:192.168.97.5, PORT:108
MyStudyRootRetrieveGeneric :: SearchOn
0002,0010 19 UI TransferSyntaxUID "1.2.840.10008.1.2.1"
0008,0020 8 DA StudyDate "20060808"
0008,0030 10 TM StudyTime "120519.000"
0008,0050 4 SH AccessionNumber "4067"
0008,0052 6 CS QueryRetrieveLevel "STUDY "
0008,0090 0 PN ReferringPhysicianNa (empty)
0008,1030 16 LO StudyDescription "C-SPINE, AP/OBL."
0010,0010 10 PN PatientName "Smith_Greg"
0010,0020 10 LO PatientID "t100001542"
0010,0030 8 DA PatientBirthDate "19700101"
0010,0040 2 CS PatientSex "F "
0020,000d 54 UI StudyInstanceUID "1.2.276.0.7230010.3.1.2.0.3367526178.2440.1168283213.2"
0020,0010 16 SH StudyID "SID_11682832130 "
Query On Image

The output stops after "Query On Image" is written. I then get the following from the OFFIS DCMTK 3.5.4 movescu.exe file.

Request Parameters:
Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.5.4
Our Implementation Version Name: OFFIS_DCMTK_354
Their Implementation Class UID:
Their Implementation Version Name:
Application Context Name: 1.2.840.10008.3.1.1.1
Calling Application Name: KEITH
Called Application Name: ENCOMPASS
Responding Application Name: resp AP Title
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 0
Presentation Contexts:
Context ID: 1 (Proposed)
Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Proposed Transfer Syntax(es):
=LittleEndianExplicit
=BigEndianExplicit
=LittleEndianImplicit
Context ID: 3 (Proposed)
Abstract Syntax: =MOVEStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Proposed Transfer Syntax(es):
=LittleEndianExplicit
=BigEndianExplicit
=LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
Requesting Association
Constructing Associate RQ PDU
PDU Type: Associate Accept, PDU Length: 221 + 6 bytes PDU header
02 00 00 00 00 dd 00 01 00 00 45 4e 43 4f 4d 50
41 53 53 20 20 20 20 20 20 20 4b 45 49 54 48 20
20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 10 00 00 15 31 2e
32 2e 38 34 30 2e 31 30 30 30 38 2e 33 2e 31 2e
31 2e 31 21 00 00 1b 01 00 00 00 40 00 00 13 31
2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32
2e 31 21 00 00 1b 03 00 00 00 40 00 00 13 31 2e
32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32 2e
31 50 00 00 3e 51 00 00 04 00 00 40 00 52 00 00
22 31 2e 32 2e 38 32 36 2e 30 2e 31 2e 33 36 38
30 30 34 33 2e 32 2e 31 33 35 2e 31 30 36 36 2e
31 30 31 55 00 00 0c 31 2e 34 2e 31 32 2f 57 49
4e 33 32
Association Parameters Negotiated:
Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.5.4
Our Implementation Version Name: OFFIS_DCMTK_354
Their Implementation Class UID: 1.2.826.0.1.3680043.2.135.1066.101
Their Implementation Version Name: 1.4.12/WIN32
Application Context Name: 1.2.840.10008.3.1.1.1
Calling Application Name: KEITH
Called Application Name: ENCOMPASS
Responding Application Name: ENCOMPASS
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 16384
Presentation Contexts:
Context ID: 1 (Accepted)
Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Accepted Transfer Syntax: =LittleEndianExplicit
Context ID: 3 (Accepted)
Abstract Syntax: =MOVEStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Accepted Transfer Syntax: =LittleEndianExplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
Association Accepted (Max Send PDV: 16372)
================================
Sending query file: K:\rsp1.2.276.0.7230010.3.1.2.0.3367526178.2440.1168283213.2.dcm
Move SCU RQ: MsgID 1
Request:

# Dicom-Data-Set
# Used TransferSyntax: LittleEndianExplicit
(0008,0020) UN 32\30\30\36\30\38\30\38 # 8, 1 StudyDate
(0008,0030) UN 31\32\30\35\31\39\2e\30\30\30 # 10, 1 StudyTime
(0008,0050) UN 34\30\36\37 # 4, 1 AccessionNumber
(0008,0052) CS [STUDY] # 6, 1 QueryRetrieveLevel
(0008,0090) UN (no value available) # 0, 1 ReferringPhysiciansName
(0008,1030) UN 43\2d\53\50\49\4e\45\2c\20\41\50\2f\4f\42\4c\2e # 16, 1 StudyDescription
(0010,0010) UN 53\6d\69\74\68\5f\47\72\65\67 # 10, 1 PatientsName
(0010,0020) UN 74\31\30\30\30\30\31\35\34\32 # 10, 1 PatientID
(0010,0030) UN 31\39\37\30\30\31\30\31 # 8, 1 PatientsBirthDate
(0010,0040) UN 46\20 # 2, 1 PatientsSex
(0020,000d) UN 31\2e\32\2e\32\37\36\2e\30\2e\37\32\33\30\30\31\30\2e\33\2e\31\2e\32\2e\30\2e\33\33\36\37\35\32\36\31\37\38\2e\32\34\34\30\2e\31\31\36\38\32\38\33\32\31\33\2e\32 # 54, 1 StudyInstanceUID
(0020,0010) UN 53\49\44\5f\31\31\36\38\32\38\33\32\31\33\30\20 # 16, 1 StudyID
DIMSE Command To Send:

# Dicom-Data-Set
# Used TransferSyntax: UnknownTransferSyntax
(0000,0000) UL 0 # 4, 1 CommandGroupLength
(0000,0002) UI =MOVEStudyRootQueryRetrieveInformationModel # 28, 1 AffectedSOPClassUID
(0000,0100) US 33 # 2, 1 CommandField
(0000,0110) US 1 # 2, 1 MessageID
(0000,0600) AE [KEITH] # 6, 1 MoveDestination
(0000,0700) US 0 # 2, 1 Priority
(0000,0800) US 1 # 2, 1 DataSetType
DIMSE sendDcmDataset: sending 102 bytes
DIMSE sendDcmDataset: sending 284 bytes
DIMSE receiveCommand
DIMSE receiveCommand: 1 pdv's (128 bytes), presID=3
DIMSE Command Received:

# Dicom-Data-Set
# Used TransferSyntax: LittleEndianImplicit
(0000,0002) UI =MOVEStudyRootQueryRetrieveInformationModel # 28, 1 AffectedSOPClassUID
(0000,0100) US 32801 # 2, 1 CommandField
(0000,0120) US 1 # 2, 1 MessageIDBeingRespondedTo
(0000,0800) US 257 # 2, 1 DataSetType
(0000,0900) US 49156 # 2, 1 Status
(0000,1020) US 0 # 2, 1 NumberOfRemainingSuboperations
(0000,1021) US 0 # 2, 1 NumberOfCompletedSuboperations
(0000,1022) US 0 # 2, 1 NumberOfFailedSuboperations
(0000,1023) US 0 # 2, 1 NumberOfWarningSuboperations
C-Move RSP: MsgID: 1 [Status=Failed: UnableToProcess]

The status I'm getting is C004. I do see that the study exists and has 1 series in DicomSeries and 4 images in DicomImages. Any thoughts? I hope the logs are helpful. If not, let me know. Thanks!

Keith

Thanks for the reply, Marcel.

Could you elaborate on the C004 error a bit? What exactly does "search error" mean?

I have seen this error after successfully getting data back from a C-FIND. Then, when requesting a C-MOVE, the C004 response gets returned. Below are some test scenarios which I've seen.

Test 1. Read station was configured for Study Root Study Level Q/R. The
study level query was successful, returning a single Study Instance UID.
Upon issuing C_MOVE_RQ, we receive a status C004 in C_MOVE_RSP
and note no action on our SCP process.

Test 2. Read station was configured for Study Root Series Level Q/R.
The study level query was successful, returning a single Study Instance
UID. Followup Series Level queries were performed returning 2 Series
Instance UID's. Upon issuing C_MOVE_RQ for series instances, we receive
a status C004 in C_MOVE_RSP and note no action on our SCP
process.

Thanks,
Keith

I am seeing CMOVE Response messages with C001, C002, C003, and C004. What are these response codes specifying? Thanks.

Keith

Yes, I did, and that does seem to work. Thank you for that.

I would, however, like to turn it off/on on the fly so that I'm only outputting debug data when troubleshooting and the basic logging other times.

No worries, I can wait for the new version.

So, I'm guessing there's no "how to", list of application used, or helper guide on recompiling the source?

Thanks,
Keith

You could also do all of the database modifications for the patient, studies, series, images yourself and use the dcmodify.exe (or compile into your code) utility from the Offis DICOM Toolkit.

http://support.dcmtk.org/docs/dcmodify.html

Hi Marcel,

Thanks for the reply. It's a self written GUI in .NET which listens on a named pipe to the output from dgate.exe's OperatorConsole.

I haven't ever tried to recompile the source for dgate. I don't suppose you have a how-to on the forum somewhere that you could point me to? I'm developing on a Windows XP machine.

I see exactly where the check for the PATHSEPCHAR would go in the code for <log_on> and <debuglog_on> but don't have much knowledge of using makefiles and whatnot. Any help you could pass along would be great. Otherwise, i guess i'm stuck until a new release comes out.

Thanks again,
Keith

OK, I did a bit of guessing and found out how to get it working. I do have a follow up though.

To get it working, i simply ran "dgate.exe --debug_logon:debug.txt" from the command prompt to get it to write to a text file. This applied the change to my actively running service.

My question is: Can I get the debug data to be passed to the OperatorConsole object? I'm currently using named pipes for the output. Putting in the same named pipe value as I have for OperatorConsole seems to still pass data but loses all of the original output I was getting.

I noticed in dgate.cpp (line 8476) that the two options are OnUDP() (if you pass a number between 0 and 9 for the first char) and On(). Am I out of luck since the OnMsgPipe() function isn't in that conditional statement?

Is it possible to use the DebugLevel feature by turning debug on when running dgate.exe as a Windows service? If so, is it done via service stra-up parameters, the dicom.ini file, etc?

Thanks,
Keith