Posts by marcelvanherk

    Hi,


    the error was related to trying to send with a different compression as the image had, and the DCMTK client has no way to change the compression on the fly and hang up as result.


    To debug, you can try to use a windows machine as forwarder using a forwarder application that logs all transactions. Test.exe from DICOMLIB.ZIP can do that:


    Code
    test -fe PORT host port loglevel forward PORT to host:port
    note: loglevel 0(default)=log nothing,
    1=log request commands
    2=+log request data and response command
    3=+log all except image data
    4=+log all including image data


    Marcel

    Hi,


    conquest echoes the sequence structure that siemens requests, irrespective of the database (which is always 'flat'). Your problem may be that you need VR's twice or need to send VR's that Siemens does not request. Can you send a dump of what siemens requests and what conquest responds?


    Edit: the only bug in 1.4.14 relates to the WorkListReturnsISO_IR_100 flag.


    Marcel

    Hi,


    the last two message logs differ from the first one you gave (error saving to SQL is missing). It almost looks as if the sending server is making connection but not sending any data. According to the source code, there should have been a log of the associated data. All messages below "***Client Error: command 0001 failed **", are due to a bug in the error reporting (fixed in 1.4.15).


    I have seen a similar error once when sending data with the DCMTK, where it hangs up due to an internal error before actually transmitting the data. Who is sending this stuff?


    And what is {####1LyyA]PLLDL_} in your first post?


    Marcel

    Hi,


    during a virtual query, the image list is first stored in the database with device ID, e.g, MAG0.1. Afterwards the data is collected from VirtualServer1 to MAG0 and then transmitted. So if the collect from VirtualServer1 fails, device ID's like MAG0.1 stay in the database. So that part of the operation seems to go well. It then scans the list and builds one or more c-move requests. Did you try displaying a debug log on the Q/R server? ANy other differences between the laptop system and the q/r server (both 32 bits?).


    You may also try to downgrade the q/r server (temporarily) to 1.4.14 (just replace the dgate.exe) to see if the problem was a recently introduced bug.


    Good luck,


    Marcel

    Hi,


    a router is not very well coming due to lack of time. This idea was to run the server databaseless and use scripts to process the data. If you need a simple router you can have a look at test.exe in the dgate release zip. It forwards to another IP or port and has been used to drive a printer in another network.


    Marcel

    Hi,


    So your server uses port 7777, and your viewers port 104. There is no reason not to use port 104 for a local viewer, as the server ONLY uses port 7777, while thew viewers only use port 104.


    ACRNEMA.MAP

    Code
    CONQUESTSRV1 127.0.0.1 7777 as
    LOCALVIEWER 127.0.0.1 104 un
    REMOTEVIEWER xxx.xxx.xxx.xxx 104 un


    Marcel

    Hi,


    Quote

    1. From what i understood from the documentation i can add any number of new fields inside the dicom.sql file. Can I also remove fields which are not needed ( of course these which are not used as keys in linking the various tables together ) ?


    Sure you can, but some server capabilities expect some fields to be present. Always regenerate the database after editing dicom.sql. But there is no big need to remove fields, expect when you are really short on storage.


    Quote

    2. Is it possible to add fields to the database which are private tags inside the incoming dicom files , if I also add these private dicom tags to the dgate.dic ?


    That is certainly possible. I do believe it would work for text fields even if dgate.dic is not adjusted. Any dicom tag can be read by Import and ExportConverters.


    Quote

    3. Not strictly conquest but : is it possible to determine when a complete study for a given patient has been received and trigger some action when this is the case ?


    Try: Importconverter0 = process series after NN by ......
    Where .... can generate any command line (not containing a ';' )


    Quote

    What I am trying to do is as follows : I receive mammography images from just one acquisition station. On receiving the last image for a series I would like to add this new series to a "to process" list. Than I would like to call an external CAD executable to process the "to process" list. Finaly, when results are available from the CAD system I would like to store them in the database as structured report files and also send these sr to another workstation for viewing.


    The question is : is it possible to accomplish this workflow using the conquest server ? What do you think would be the best way to do something like this ( sql stored procedures or conquest filters or maybe write another service/daemon that accesses the conquest database and monitors for new unprocessed series ) ?


    Hi, the command above was made for such a task. If you can genrate the SR yourself, a "dgate --addimagefile:" would load it into the server.


    Marcel

    Hi,


    just try it out please and look around on the forum. If you want to help post a step by step guide of what you do. I will help if you get stuck. I assume you are familiar with linux?


    Marcel

    Hi,


    The green background sounds like a bug in the (old) kpacs viewer. You should be able to page through the images with the mouse or wheel, but support for multi-frame US is not very good, as it assumes that a series is 3D, not a frame.


    1) Try a new version of k-pacs, for local viewing.


    2) The conquest web viewer will show the images, where you can page through the frames. But this is still very basic.


    Marcel