| CALL_EXTERNAL problems (re: DICOM) [message #18327] |
Wed, 22 December 1999 00:00  |
Richard Tyc
Messages: 69
Registered: June 1999
|
Member |
|
|
This may interest anyone who is using IDL with DICOM SCP servers.
I am trying to use CALL_EXTERNAL to initate a DICOM query and retrieve a
list of patients and/or studies from a PACS archive acting as a Query SCP.
I am using the CTN test code (Ansi C) from Mallinkrodt Institute of
Radiology (MIR).
Essentially, I have modified the query_client application (which was a motif
application) and turned it into a shared library. This involved removing
all of the X windows stuff and turning the callbacks from widgets into C
finctions I can call from IDL. I was successfully querying a dicom server
running on the same machine as IDL and getting patient lists, etc.
When I took the machine down to our MRI lab, I cannot get patient lists from
IDL although the original query_client works. The main difference is now
the CTN test code is querying across the net to the MRI system. The way a
dicom query works is that first an association is made (which works!) and
then for each response from the server a callback function is called which
extracts the query data (all taking place over TCP/IP). Now all this takes
place in the linked in librarie(s) which IDL calls. To make this work in
IDL , I simply ensured all of the libraries linked in were shared libs.
Note, the library created with the IDL function calls links with many other
utilites providing the DICOM services.
Does anyone see any problem with this ? It seems to provide no query
responses at all from the server. In order for this to happen, the C code
must fundamentally be accepting sockets and waiting on socket reads to
acquire data all during one IDL CALL_EXTERNAL. When the system was working
on a standalone machine, it seems to indicate that success is dependent on
no delays in the socket stuff. When I moved the app to network wide queries
with inherent delays, I simply get no query data returned from the DICOM
server. Do I have to do anything special in the other C libs not directly
called by IDL but are linked in.
I am running IDL 5.2.1 on SGI 6.5 compiling with -n32 binaries.
Thanks
Rich
|
|
|
|
| Re: CALL_EXTERNAL problems (re: DICOM) [message #18400 is a reply to message #18327] |
Mon, 27 December 1999 00:00  |
Karri Kaksonen
Messages: 27
Registered: October 1999
|
Junior Member |
|
|
Richard,
I did almost the same thing but the other way around.
In my setup I used Callable IDL from my C-code and used
a commercial Dicom toolkit instead of Mallindkrodt.
I don't know if you find any help from this but the things
I have found to be necessary for my toolkit are:
set_port( pTran, "104" );
set_protocol( pTran, "tcpip" );
set_source( pTran, "NORDSTAR_MR_SCP" );
status = listen( pTran, &listen_fd);
In addition to this the PACS is usually set up to accept
connections from certain physical wires only. Which means
that you cannot just move your machine to another place in
the house and plug it in the net. At least in one hospital
they tied the legal machines to an IP-address and a physical
twisted-pair port.
I could not find anything wrong in your description of how
to do this. If it had been a Windows-machine I could easily
have added all kind of silly "special" gimmicks like opening
the socket with the "rb" flags. Tricks with TCP/IP byteorder
being different, cache-bugs in the NT etc.
--
Regards,
Karri Kaksonen
Picker Nordstar
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
