Posts by radtraveller


    I never really got into converters before but maybe this bit of logic can help you??


    Awaiting Marcel's return....


    So in this case...


    12345678_SJS
    1234567_SJS
    123456_SJS


    Importconvert0 = ifequal "%V0010,0020[8]","_"; set 0010,0020 to "%V0010,0020[0,7]"; newuids;
    (if 9th character is "_" truncate id to 0-7 or 8 digits long, create new uids, need to say, do nothing if spot 9 is not "_")


    ImportCoverter1 = ifequal "%V0010,0020[7]", "_"; set 0010,0020 to "%V0010,0020[0,6]" ; newuids;
    (if 8th character is "_" truncate id to 0-6 or 7 digits long, create new uids, need to say, do nothing if spot 8 is not "_")


    ImportCoverter2 = ifequal "%V0010,0020[6]", "_"; set 0010,0020 to "%V0010,0020[0,5]" ; newuids;
    (if 7th character is "_" truncate id to 0-5 or 6 digits long, create new uids, need to say, do nothing if spot 7 is not "_")


    I think you need to create newuids if you are going to change the MRN. shrug. I am sure Marcel or somebody will correct me.


    Edit: I do not remember if nop is implied in any if* statement when the condition is not met??

    Quote from churnd

    OK actually the above script didn't work at all. I'm attaching one I've developed further, and it still doesn't work:

    Bash
    #!/bin/sh## Startup script for Conquest## chkconfig: 345 85 15 - start or stop process definition within the boot process# description: Conquest DICOM Server# processname: conquest# pidfile: /var/run/conquest.pid# Source function library. This creates the operating environment for the process to be started. /etc/rc.d/init.d/functionsCONQ_DIR=/usr/local/conquestcase "$1" in start) echo -n "Starting Conquest DICOM server: " cd $CONQ_DIR && daemon --user mruser ./dgate -v - Starts only one process of a given name. echo touch /var/lock/subsys/conquest ;; stop) echo -n "Shutting down Conquest DICOM server: " killproc conquest echo rm -f /var/lock/subsys/conquest rm -f /var/run/conquest.pid - Only if process generates this file ;; status) status conquest ;; restart) $0 stop $0 start ;; reload) echo -n "Reloading process-name: " killproc conquest -HUP echo ;; *) echo "Usage: $0 {start|stop|restart|reload|status}" exit 1esacexit 0


    What I'm getting is

    Code
    # ./conquest start
    Starting Conquest DICOM server: -bash: ./dgate: No such file or directory
    [FAILED]


    Can someone please tell me why this redhat init.d script isn't working? Or perhaps provide one that will?


    Little rusty with RH..


    Can you start dgate manually from the terminal?


    IIRC, there is a configuration file somewhere to declare env path.
    Otherwise, maybe put


    cd /usr/local/conquest/


    before trying to ./dgate


    looks like you are not getting to the correct directory to start dgate.

    Sigh...


    More SOPlist roblems..


    So I set the Commercial Pacs to autoroute studies to Conquest. Manually sending studies works fine.



    [RADIOLOGY] UPACS THREAD 6: STARTED AT: Wed Jun 02 10:22:47 2010
    [RADIOLOGY] Calling Application Title : "####### "
    [RADIOLOGY] Called Application Title : "RADIOLOGY "
    [RADIOLOGY] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
    [RADIOLOGY] Presentation Context 0 "1.2.840.10008.3.1.2.3.1" 0
    [RADIOLOGY] Transfer Syntax 0 "1.2.840.10008.1.2" 1
    [RADIOLOGY] *** Association rejected: you may need to add the listed presentation context as sop to dgatesop.lst
    [RADIOLOGY] UPACS THREAD 6: ENDED AT: Wed Jun 02 10:22:47 2010
    [RADIOLOGY] UPACS THREAD 6: TOTAL RUNNING TIME: 0 SECONDS


    Added the "DetachedStudyManagement 1.2.840.10008.3.1.2.3.1 sop" to dgatesop.lst
    kill and restart server


    When study is autorouted I get the following:


    [RADIOLOGY] UPACS THREAD 15: STARTED AT: Wed Jun 02 10:18:47 2010
    [RADIOLOGY] Calling Application Title : "###### "
    [RADIOLOGY] Called Application Title : "RADIOLOGY "
    [RADIOLOGY] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
    [RADIOLOGY] Presentation Context 0 "1.2.840.10008.3.1.2.3.1" 1
    [RADIOLOGY] No image number
    [RADIOLOGY] No Series number
    [RADIOLOGY] No image number
    [RADIOLOGY] No Series number
    [RADIOLOGY] ***Refused to enter inconsistent link StudyInsta into DICOMSeries: PatientID = '00000000' SeriesInst = 'undefined' AND SeriesPat = '00000000', Old='1.2.840.113888.1.2.3.906811.1275194202', Refused='1.2.840.113619.2.30.1.1762369785.1754.1273594173.607'
    [RADIOLOGY] ***Refused to enter inconsistent link StudyInsta into DICOMSeries: PatientID = '00000000' SeriesInst = 'undefined' AND SeriesPat = '00000000', Old='1.2.840.113888.1.2.3.906811.1275194202', Refused='1.2.840.113619.2.30.1.1762369785.1754.1273594173.670'
    [RADIOLOGY] ***Error saving to SQL: NO_NAME_00000000\empty_empty\empty\1.2.840.113619.2.30.1.1762369785.1754.1273594173.818.read.dcm
    [RADIOLOGY] UPACS THREAD 14: ENDED AT: Wed Jun 02 10:18:47 2010
    [RADIOLOGY] UPACS THREAD 14: TOTAL RUNNING TIME: 0 SECONDS
    [RADIOLOGY] ***Error saving to SQL: NO_NAME_00000000\empty_empty\empty\1.2.840.113619.2.30.1.1762369785.1754.1273594173.609.read.dcm
    [RADIOLOGY] UPACS THREAD 15: ENDED AT: Wed Jun 02 10:18:47 2010
    [RADIOLOGY] UPACS THREAD 15: TOTAL RUNNING TIME: 0 SECONDS
    [RADIOLOGY] Written file: C:\conquest\data\NO_NAME_00000000\empty_empty\empty\1.2.392.200036.9107.500.303.1508.20100529.214814.101508.read.dcm
    [RADIOLOGY] UPACS THREAD 13: ENDED AT: Wed Jun 02 10:18:47 2010
    [RADIOLOGY] UPACS THREAD 13: TOTAL RUNNING TIME: 0 SECONDS


    For some reason when study gets autorouted, it isn't sending some required info (or conquest isn't "seeing" it correctly?) ;-P
    It seems as if a common thread is emerging with any "detached" study management sop lines.

    Hi all,


    I am now back in a facility where I can use Conquest again.


    I am slowly remembering everything, but I have hit a wall with an issue and I am hoping someone has encountered this and can help.


    I am using Conquest as a near-line storage device to a commercial PACS. I have everything set up how I think I want it, but when I try to send studies from the Commercial Pacs to Conquest with reports, I get the following error:


    [RADIOLOGY] UPACS THREAD 2: STARTED AT: Tue Jun 01 17:01:35 2010
    [RADIOLOGY] Calling Application Title : "####### "
    [RADIOLOGY] Called Application Title : "RADIOLOGY "
    [RADIOLOGY] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
    [RADIOLOGY] Presentation Context 0 "1.2.840.10008.3.1.2.5.1" 0
    [RADIOLOGY] Transfer Syntax 0 "1.2.840.10008.1.2" 1
    [RADIOLOGY] *** Association rejected: you may need to add the listed presentation context as sop to dgatesop.lst
    [RADIOLOGY] UPACS THREAD 2: ENDED AT: Tue Jun 01 17:01:35 2010
    [RADIOLOGY] UPACS THREAD 2: TOTAL RUNNING TIME: 0 SECONDS


    Studies (Images AND the scanned in Requests, history and consents) come in normally, but I keep erroring on the reports.
    So I add the presentation context to dgatesop.lst as (partial) :


    #None none RemoteAE
    #None none LocalAE
    #DICOM 1.2.840.10008.3.1.1.1 application
    DetachedResultsManagement 1.2.840.10008.3.1.2.5.1 sop
    Verification 1.2.840.10008.1.1 sop
    StoredPrintStorage 1.2.840.10008.5.1.1.27 sop
    HardcopyGrayscaleImageStorage 1.2.840.10008.5.1.1.29 sop
    HardcopyColorImageStorage 1.2.840.10008.5.1.1.30 sop


    (hmm.. formatting not being kept in this post, but I am keeping same formatting as is present by default)


    Kill and restart server:


    Error Message:


    [RADIOLOGY] UPACS THREAD 1: STARTED AT: Tue Jun 01 17:19:35 2010
    [RADIOLOGY] A-ASSOCIATE-RQ Packet Dump
    [RADIOLOGY] Calling Application Title : "####### "
    [RADIOLOGY] Called Application Title : "RADIOLOGY "
    [RADIOLOGY] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
    [RADIOLOGY] Number of Proposed Presentation Contexts: 1
    [RADIOLOGY] Presentation Context 0 "1.2.840.10008.3.1.2.5.1" 1
    [RADIOLOGY] Server Command := 0100
    [RADIOLOGY] Message ID := 0001
    [RADIOLOGY] 0000,0002 24 UI AffectedSOPClassUID "1.2.840.10008.3.1.2.5.1"
    [RADIOLOGY] 0000,0100 2 US CommandField 256
    [RADIOLOGY] 0000,0110 2 US MessageID 1
    [RADIOLOGY] 0000,0800 2 US DataSetType 256
    [RADIOLOGY] 0000,1000 0 UI AffectedSOPInstanceU (empty)
    [RADIOLOGY] 0000,1002 2 US EventTypeID 17
    [RADIOLOGY] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
    [RADIOLOGY] ***Client Error: command 0100 failed **
    [RADIOLOGY] ***Connection Terminated
    [RADIOLOGY] 0000,0002 24 UI AffectedSOPClassUID "1.2.840.10008.3.1.2.5.1"
    [RADIOLOGY] 0000,0100 2 US CommandField 256
    [RADIOLOGY] 0000,0110 2 US MessageID 1
    [RADIOLOGY] 0000,0800 2 US DataSetType 256
    [RADIOLOGY] 0000,1000 0 UI AffectedSOPInstanceU (empty)
    [RADIOLOGY] 0000,1002 2 US EventTypeID 17
    [RADIOLOGY] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
    [RADIOLOGY] Connected by address: 0100007f
    [RADIOLOGY] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
    [RADIOLOGY] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
    [RADIOLOGY] 0000,0100 2 US CommandField 48
    [RADIOLOGY] 0000,0110 2 US MessageID 7
    [RADIOLOGY] 0000,0800 2 US DataSetType 257
    [RADIOLOGY] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
    [RADIOLOGY] 9999,0400 6 UN "silent"


    I am thinking I did not get the sop correct (searched on google for the presentation context and found the "Detached Results Management") or I did not get it set up correctly.


    Any help would be appreciated.


    Thanks,


    Matt

    "I've had a look through both the manual and the forum, but not found an answer to my problem - apologies if I've missed it and it has been answered already...


    Since we upgraded to 64 slice CTs, we are eating up disk space on PACS at a great rate.


    What I want to do is forward all of the incoming studies to another Conquest server with a large (12TB) array and forward only the thick slice MPRs and other recons, plus the scout, to PACS"



    No. This is not a conquest solution. You need to set the destination to autosend in your scanner protocols on the series level for the destination.


    Siemens allows 3 destinations per series. I can't remember off the top of my head how many GE allows.


    ie autosend thick, mpr, recons and scouts to pacs then send the thins and scouts to Conq_12TB. (no sense storing what you can easily recreate with already stored thin slice data.)


    Or continue to use the existing conquest to buffer to PACS, sending only the PACS specific series there to autoforward and autosending your thins to the 12TB server.


    Or if f your PACS is one of those that charge by the byte, then maybe increase the storage of the current Conquest to be near term (up to one year) and reduce the PACS storage to a 3 month limit

    Get a usb drive. I use 500gb Seagates.


    Put the conquest PACS software in its own directory.


    Set up using the DBASE engine.


    Add your scanner to the DICOM Providers list.


    Add Kpacs to the DICOM Providers list.


    Add the Conquest info to the Scanner's DICOM list.


    After configuration is tested and working, save the conquest directory to the local hard drive under something like "Archive Software."


    Run Conquest from the usb drive.


    Alternatively, creat a shortcut on the desktop.


    I have a shortcut, plus I have conquest autostarting with windows.


    When the drive is near full, plug in new drive and copy the files from "Archive Software" to the new drive.


    Two things:


    One:


    This lets each individual usb drive be an independent, full archive that doesn't rely on any other software to be able to run. (well except a functioning(!?) windows computer.


    Two:

    This setup does require that conqust have time to index the database whenever you restart the computer. 300gb takes about 4-5 minutes.


    So you have the conquest archive software on the USB drive and can swap them in and out as needed. (though you will need to stop the server whenever you change drives and then let it index when you plug in the other).


    Then you have K-pacs to query the database and verify that the days scans are archived and to look up old exams (though you could look up old exams and transfer them using the conquest interface).


    I always check the database to ensure the complete studie is on the archive before deleting them from the scanner.

    Also...



    I don't know how long you have had your machine, but over time the DB can become corrupted, even if you religously use system cleanup and shutdown after deleting old studies. Ask your service rep about removing and rebuilding the DB. ALLDBRemove is the function name I believe.

    I have problems sometimes also.


    I have a 64 Slice Sensation and when transfering (archiving) large datasets (>5k images), I infrequently run into cleint termination with no further details. Once that happens though, any further attempts and ALL image transfer fails until I delete all pending jobs and restart them individually. If I split up the archival into groups of less than 5k images, I never have problems.


    Shrug

    Sorry that was for 'my' setup.



    I believe that increasing the amount of memory to Dgate and to mysql plus letting them have higher priority is what put me over the top in being able to drop large datasets into conquest.


    Replace your two Cpus with dual (or quad core) variants if available? :-)

    http://www.image-systems.biz/phpBB2/viewtopic.php?t=577


    Longhorn Beta 3, Mysql 5.1, Conquest 1.4.13.


    Setup is 2 dual core Xeon 5060, 6 GB Ram, 3 TB Raid 50, Dual gb NICs.


    Set windows to give background services higher priority. Pagefile is set at 4gb min and 16gb max.


    Use Mysql.dll from Conquest Download site. (DLL with 5.1 didn't work for me)


    Up and running, set prefs in dicom.ini.


    Start Conquest. Do not install as a service.


    Set affinity on Dgate to any non 0 cpu. Conquest to another non 0 and mysql to a different non 0 cpu.


    Raise priority of those three to real-time.


    Drag and drop 860 GB from external USB drive with no errors.


    Memory usage went to 5 gb and stayed there, pagefile usage went between 800mb and 1.6 gb.


    Still took almost 90 hours though. Left wondering if I missed a "tweak" somewhere.

    right click on main viewer and choose autocontrast. If you can see the image, then your getting compressed images. For some reason, I can never see thumbnails from compressed studies, yet autocontrasting lets me see the study in the main vierwer window.

    I think your problem could be solved by specifying 'forward to" (without the quotes) for each destination and keeping a space between the ; and 'forward'.


    Also, just in case, make sure the export destinations know conquest correctly.


    Just out of curiosity, why would you forwardassociationlevel on image?
    Matt



    (of course I could be totally wrong)

    First,


    Thanks Marcel et al for this great app.


    I am up and running well on Longhorn.


    I have an isssue though that maybe you or the community can help with.


    I have Conquest as a main with Mysql and also a backup server with DBASE.


    The main runs from local HD and the backup from a 1TB ext WD USB drive. The Main forwards to backup as J2.


    There are approx 300 studies less on the backup server than the main.


    I have tried "find local missing" from backup against main, but I am continuously getting "dicom association lost" and exit.


    I have increased tcp timeout values on both to 900. I will try a longer timeout, but I was wondering if anyone has any other hints or tricks.


    The database is a little over 1.2 terabytes on main with 10166 studies.


    Thanks,


    Matt

    Quote from marcelvanherk

    Apparently there is a memory leak somewhere. I'll have a look. Could you maybe see which process was using all that memory?


    Marcel


    Not until I have to rebuild the database again? Urgh...


    My thought was that the problem was in MySql and running Conquest as a service? Too much, too fast for the MySQL. (or my settings in my.ini)


    If I remember correctly, every time a copy job errored out, I had a error with Mysql.

    Longhorn Beta 3, Mysql 5.1, Conquest 1.4.13.


    Setup is 2 dual core Xeon 5060, 6 GB Ram, 3 TB Raid 50, Dual gb NICs.


    Set windows to give background services higher priority. Pagefile is set at 4gb min and 16gb max.


    Use Mysql.dll from Conquest Download site. (DLL with 5.1 didn't work for me)


    Up and running, set prefs in dicom.ini.


    Start Conquest. Do not install as a service.


    Set affinity on Dgate to any non 0 cpu. Conquest to another non 0 and mysql to a different non 0 cpu.


    Raise priority of those three to real-time.


    Drag and drop 860 GB from external USB drive with no errors.


    Memory usage went to 5 gb and stayed there, pagefile usage went between 800mb and 1.6 gb.


    Still took almost 90 hours though. Left wondering if I missed a "tweak" somewhere.

    Have had that issue also... Too much data being moved and MySql chokes and shuts down. ie mysql service has to be restarted. I have tried increasing caches and timeouts to no avail.


    Got a new test box finally. Going to try ..Win2003R2/MSSQL2005 and longhorn beta3 Web with MSSQL2005.


    Any tales of experiences would be welcomed.