We noticed in the Conquest logs multiple repeating entries similar to:

UPACS THREAD 0: ENDED AT: Thu Oct 19 09:23:58 2006
UPACS THREAD 0: TOTAL RUNNING TIME: 0 SECONDS

We also discovered that by turning off one specific ultrasound machine, the log messages would go away, and things would speed up. Now we are trying to figure out why/how this one GE Voluson is causing issues with Conquest.

This problem seemed to occur out of the blue. Things were working fine for the longest time. Also, we have Volusons at other clinics, and do not have this problem. My colleague suggested using a packet sniffer called Wireshark, and that has unlocked some more clues about this problem.

Those THREAD 0 log entries in Conquest are a result of the Voluson sending TCP Window Request packets to Conquest. Research has told me that the TCPWR packet is essentially used by the receiving system to acknowledge a specific amount of data has been received, and to send the next chunk.

Monitoring a normally functioning system illustrates this very well. When a modality sends data to PACS, PACS will reply with a bunch of TCPWR packets. Also, when PACS sends images to a review station, that review station will likewise reply with TCPWR packets. So this tells me something is wrong with the Voluson, since it is sending PACS the TCPWR packet, repeatedly, without receiving any data to prompt such a packet.

GE has been made aware of the problem and of the issue with TCPWR packets. Hopefully they can solve the problem in short order, although I expect it will not a straightforward process to figure out this particular issue.

Bookmark to:
         

I enabled debug logging in Conquest (a VERY handy troubleshooting feature). However, nothing was showing up when the Philips would try to send the 3D image. Nothing. Which struck me as very odd, usually some sort of message comes up indicating Conquest started communication. That led me nowhere.

Back on the Philips, I started going through configuration screens. Inside the PACS server setup screens, I found some 3D related check boxes, that were not enabled. Enabling these did not fix the problem. I then looked for the DICOM file type/compression settings.

The setting was for RGB, Uncompressed ILE. ILE stands for Implicit Little Endian. I also noticed a blurb saying all 3D are sent as RGB, Uncompressed ELE (Explicit Little Endian).

I got thinking, perhaps Conquest was having issues with ELE. To test, I changed the regular setting to ELE, and took a picture. Sure enough, it just sat in the queue and did not get to Conquest PACS. So now I knew the problem, but how to fix it? A quick search on Google provided no help. Sadly, Conquest help is extremely hard to find online (that is why you are here!).

Next I searched the Conquest documentation. I quickly found that Explicit Little Endian is an option in the DGATESOP.LST file, and it is disabled by default. I opened the file, removed the # prefixing the ELE line, saved, and restarted Conquest. Sure enough, images started arriving. Thus far, there have been no negative consequences from enabling that function.

I am by no means a PACS guru, I know what I know based on what I need to know to do the job. I am sure some of you understand the definitions and differences between ELE and ILE. Feel free to share in the comments! However, like all my posts, I hope this helps one other person in some way.

Bookmark to: