PHILIPS RM transfer

Hi, I'm having many troubles with a PHILIPS RM. 2 instances of Conquest are set-up on the same server, one for a Siemens scanner (that has worked fine for many years), and one for a Philips scanner. Configuration is essentially the same, but the Philips CONQUEST is setup serverless and there is one exportconverter.

I get at least 3 recurring problem

1) sometimes the server crashes, especially with large Philips "enhanced" dicoms, with the following log:

20140329 09:58:35 Written file: R:\rawdata\philips\SPALLETTA\00086869\20140319\1.3.76.13.71888.2.20140319175855.564584.1\1.3.46.670589.11.34249.5.0.4396.2014031918405657408\000001_1.3.46.670589.11.34249.5.20.1.1.4396.2014031918405657408.dcm
20140329 09:58:55 ***VR:ReAlloc out of memory allocating 374492160 bytes

20140329 09:58:55 ***A fatal error occurred (out of memory) - closing server

2) sometimes the transfer apparently fails at the scanner console, but the data were actually transfered

3) have several "conncetion terminated" errors on the conquest log:

[FUSIONDCM2] 20140328 12:44:09
[FUSIONDCM2] 20140328 12:44:09 UPACS THREAD 16: STARTED AT: Fri Mar 28 12:44:04 2014
[FUSIONDCM2] 20140328 12:44:09 *** connection terminated
[FUSIONDCM2] 20140328 12:44:09 UPACS THREAD 16: ENDED AT: Fri Mar 28 12:44:09 2014
[FUSIONDCM2] 20140328 12:44:09 UPACS THREAD 16: TOTAL RUNNING TIME: 5 SECONDS
[FUSIONDCM2] 20140328 12:44:18
[FUSIONDCM2] 20140328 12:44:18 UPACS THREAD 17: STARTED AT: Fri Mar 28 12:44:13 2014
[FUSIONDCM2] 20140328 12:44:18 *** connection terminated
[FUSIONDCM2] 20140328 12:44:18 UPACS THREAD 17: ENDED AT: Fri Mar 28 12:44:18 2014
[FUSIONDCM2] 20140328 12:44:18 UPACS THREAD 17: TOTAL RUNNING TIME: 5 SECONDS
[FUSIONDCM2] 20140328 12:44:27
[FUSIONDCM2] 20140328 12:44:27 UPACS THREAD 18: STARTED AT: Fri Mar 28 12:44:22 2014
[FUSIONDCM2] 20140328 12:44:27 *** connection terminated
[FUSIONDCM2] 20140328 12:44:27 UPACS THREAD 18: ENDED AT: Fri Mar 28 12:44:27 2014
[FUSIONDCM2] 20140328 12:44:27 UPACS THREAD 18: TOTAL RUNNING TIME: 5 SECONDS
[FUSIONDCM2] 20140328 12:44:36
[FUSIONDCM2] 20140328 12:44:36 UPACS THREAD 19: STARTED AT: Fri Mar 28 12:44:31 2014
[FUSIONDCM2] 20140328 12:44:36 *** connection terminated
[FUSIONDCM2] 20140328 12:44:36 UPACS THREAD 19: ENDED AT: Fri Mar 28 12:44:36 2014
[FUSIONDCM2] 20140328 12:44:36 UPACS THREAD 19: TOTAL RUNNING TIME: 5 SECONDS
[FUSIONDCM2] 20140328 12:44:45
[FUSIONDCM2] 20140328 12:44:45 UPACS THREAD 20: STARTED AT: Fri Mar 28 12:44:40 2014
[FUSIONDCM2] 20140328 12:44:45 *** connection terminated
[FUSIONDCM2] 20140328 12:44:45 UPACS THREAD 20: ENDED AT: Fri Mar 28 12:44:45 2014
[FUSIONDCM2] 20140328 12:44:45 UPACS THREAD 20: TOTAL RUNNING TIME: 5 SECONDS
[FUSIONDCM2] 20140328 12:44:54
[FUSIONDCM2] 20140328 12:44:54 UPACS THREAD 21: STARTED AT: Fri Mar 28 12:44:49 2014
[FUSIONDCM2] 20140328 12:44:54 *** connection terminated
[FUSIONDCM2] 20140328 12:44:54 UPACS THREAD 21: ENDED AT: Fri Mar 28 12:44:54 2014
[FUSIONDCM2] 20140328 12:44:54 UPACS THREAD 21: TOTAL RUNNING TIME: 5 SECONDS

I suspect that point 2 & 3 are related. It seems that the scanner opens the channel, than starts building the ehannced dicom (a task cthet can be quite time-consuming, if several images are to be packed), and finally attempts the transfer.

Any hints? I alread increased TCPIPTimeOut to 900

tahnk you, Federico

Hi,

it's past a bit of time... Have you some new ideas about the my old problem.
I'll send you again the messages log of PacsTrouble.log and serverstatus.log:
20160909 15:29:42 Inconsistent StudyModal in DICOMStudies: PatientID = '00109677' StudyInsta = '1.3.76.13.71888.2.20160823153122.636850.1', Old='MR', New='PR\MR'
20160909 15:30:13 *** connection terminated
20160909 15:30:22 *** connection terminated
20160909 15:30:31 *** connection terminated
20160909 15:30:40 *** connection terminated

09/09/2016 15.30.13 [FUSIONDCM3] UPACS THREAD 8: STARTED AT: Fri Sep 09 15:30:09 2016 (Fabio nel fine PacsTrouble.log: 20160909 15:30:13 *** connection terminated)
09/09/2016 15.30.13 [FUSIONDCM3] *** connection terminated
09/09/2016 15.30.13 [FUSIONDCM3] UPACS THREAD 8: ENDED AT: Fri Sep 09 15:30:13 2016
09/09/2016 15.30.13 [FUSIONDCM3] UPACS THREAD 8: TOTAL RUNNING TIME: 4 SECONDS
09/09/2016 15.30.22 [FUSIONDCM3]

09/09/2016 15.30.22 [FUSIONDCM3] UPACS THREAD 9: STARTED AT: Fri Sep 09 15:30:18 2016 (Fabio nel fine PacsTrouble.log: 20160909 15:30:22 *** connection terminated)
09/09/2016 15.30.22 [FUSIONDCM3] *** connection terminated
09/09/2016 15.30.22 [FUSIONDCM3] UPACS THREAD 9: ENDED AT: Fri Sep 09 15:30:22 2016
09/09/2016 15.30.22 [FUSIONDCM3] UPACS THREAD 9: TOTAL RUNNING TIME: 4 SECONDS
09/09/2016 15.30.31 [FUSIONDCM3]

09/09/2016 15.30.31 [FUSIONDCM3] UPACS THREAD 10: STARTED AT: Fri Sep 09 15:30:27 2016 (Fabio nel fine PacsTrouble.log: 20160909 15:30:31 *** connection terminated)
09/09/2016 15.30.31 [FUSIONDCM3] *** connection terminated
09/09/2016 15.30.31 [FUSIONDCM3] UPACS THREAD 10: ENDED AT: Fri Sep 09 15:30:31 2016
09/09/2016 15.30.31 [FUSIONDCM3] UPACS THREAD 10: TOTAL RUNNING TIME: 4 SECONDS
09/09/2016 15.30.40 [FUSIONDCM3]

09/09/2016 15.30.40 [FUSIONDCM3] UPACS THREAD 11: STARTED AT: Fri Sep 09 15:30:36 2016 (Fabio nel fine PacsTrouble.log: 20160909 15:30:40 *** connection terminated)
09/09/2016 15.30.40 [FUSIONDCM3] *** connection terminated
09/09/2016 15.30.40 [FUSIONDCM3] UPACS THREAD 11: ENDED AT: Fri Sep 09 15:30:40 2016
09/09/2016 15.30.40 [FUSIONDCM3] UPACS THREAD 11: TOTAL RUNNING TIME: 4 SECONDS
09/09/2016 15.30.49 [FUSIONDCM3]

P.S. Setting the debug level at fourth level I lose the "*** connection terminated" message.

ENPQ

Hi Marcel

I have turned off the "Storage commitment" option on the Philips scanner.
From first tests seems to work fine. In the next days we'll do other tests.
I will keep you updated.

Fabio