Posts by ncc1701

    Hi,


    I found out the solution.


    ExportConverter0 = ifequal "%u", "CONQ"; stop; between "01", "02";{ifnumgreater "%d[14,15]", "45"; defer;}; between "02", "03";{ifnumless "%d[14,15]", "15"; defer;}; forward to STORESCP;
    ExportModality0 = *
    ExportCalledAE0 = CONQ
    ExportCallingAE0 = STORESCU


    it seems that between means "greater or equal" and "less then" and "not greater or equal" and "less or equal".


    Stefan

    Hi,


    after intensive tests, I mean your proposition does not work in the way I need. I need much more control possibilties. I think it is easier to develop granulate "between" function in the way I describe in my postings before.


    Stefan

    Hi,
    now I understand


    between "9", "10"; {ifnumless "%d[N,M]", "30"; defer}; xxxx


    In the moment it seems, that it is not possible to exclude a time range from 01:45 am to 02:30 am. With your solution it is possible to exclude a time range from 2:00 am to 02:15 am and 01:45 to by comparing the minutes. Is there a possibilty to compare two values with an logical AND?


    Stefan

    Hi,
    I'm not sure, that I'm understang the syntax of


    between "9", "10"; {ifnumless "%d[N,M]", "30"; defer}; xxxx


    What does ifnumless do? How is it working. I Understand ifgreater or ifequal, but ifnumless??


    Stefan

    Marcel,
    if I configure Conquest in the following way:


    ForwardAssiciationLevel = STUDY
    ForwardAssociationCloseDelay = 5
    ForwardAssociationRefreshDelay = 3600
    ForwardAssociationRelease = 1
    ForwardCollectDelay = 600


    ExportConverters = 2


    ExportConverter0 = ifequal "%u", "CONQ"; stop; between "09:00", "10:00"; defer; forward study to STORESCP;
    ExportModality0 = *
    ExportCalledAE0 = CONQ
    ExportCallingAE0 = STORESCU


    As you see, I define a ForwardCollectDelay = 600. When starts this time? With the beginning of receiving images from STORESCU or after receiving the last image (of the same study), which comes frome STORESCU? If it starts with the beginning of receiving images from STORESCU you have to make sure to receive alle images of entire study before the ForwardCollectdelay ends. This is a problem, if have a slow data connection.


    Stefan

    Hi,


    I think it makes sense to granulate such intervals. One hour is a long time. In my case, I have a SDSL connection between two locations, which will be interruppted and restarted at night (exactly at 01:59 am). So, in my project I have two exclude this time (better a time range) for forwarding images to prevent Conquest errors. If I could exclude only hole hours, I have to configure a exclude range from "1" to "3". Two hours! A long time for small connection.


    or, is there another solution?


    Stefan

    Marcel,
    I've a question about the export rules:


    In the dicom.ini file I configure a export rule:


    ExportConverter0 = ifequal "%u", "CONQ"; stop; between "9", "9:30"; defer; forward to STORESCP;
    ExportModality0 = *
    ExportCalledAE0 = CONQ
    ExportCallingAE0 = STORESCU


    Is it possible to write


    between "9", "9:30"; defer;


    or is only possible to write


    between "9", "10"; defer; (in this case)



    I need e excluding time for forwarding images from 01:45 am to 02:15 am. Is it possible to configure?


    Stefan

    Marcel,


    I'm using Conquest to receive and forward images. First I send MG images with Offis 3.5.4 tool storescu.exe to conquest. it is using the max PDU size of 16372. Conquest receives the images and forwards it to the Offis tool 3.5.4 storescp.exe which is also running in a command tool box (like storescu.exe). I started these tools with the following parameters:


    storescu -v -d -aet CONQ -aec STORESCU 172.21.122.136 104 test1.dcm


    storescp -v -d +xi -pdu 16372 -aet STORESCP 104


    Content of acrnema.map
    CONQ 172.21.122.136 5678 un
    STORESCP 172.21.122.136 104 un
    STORESCU 172.21.122.136 10001 un



    Content of dicom.ini
    # This file contains configuration information for the DICOM server
    # Do not edit unless you know what you are doing


    [sscscp]
    MicroPACS = sscscp
    Edition = Personal


    # Network configuration: server name and TCP/IP port#
    MyACRNema = CONQ
    TCPPort = 5678


    # Reference to other files: known dicom servers; database layout; sops
    ACRNemaMap = acrnema.map
    kFactorFile = dicom.sql
    SOPClassList = dgatesop.lst


    # Host(ignored), name, username and password for ODBC data source
    SQLHost = localhost
    SQLServer = C:\Tmp\Conquest\Data\dbase\
    Username = conquest
    Password = conquest
    DoubleBackSlashToDB = 0


    # Configure database
    TruncateFieldNames = 10
    MaxFieldLength = 254
    MaxFileNameLength = 255
    FixPhilips = 0
    FixKodak = 0
    KeepAlive = 0
    LargeFileSizeKB = 1024
    ZipTime = 05:
    UIDPrefix = 1.2.826.0.1.3680043.2.135.733224.56407500
    EnableReadAheadThread = 1
    PatientQuerySortOrder =
    StudyQuerySortOrder =
    SeriesQuerySortOrder =
    ImageQuerySortOrder =
    IndexDBF = 1
    PackDBF = 0
    LongQueryDBF = 1000
    TCPIPTimeOut = 300
    FailHoldOff = 60
    RetryDelay = 100
    QueueSize = 128
    WorkListMode = 0
    DebugLevel = 4
    Prefetcher = 0
    LRUSort =
    AllowTruncate =
    DecompressNon16BitsJpeg = 1
    UseBuiltInDecompressor = 1
    FileNameSyntax = 4


    # Configuration of compression for incoming images and archival
    DroppedFileCompression = un
    IncomingCompression = un
    ArchiveCompression = as


    # Names of the database tables
    PatientTableName = DICOMPatients
    StudyTableName = DICOMStudies
    SeriesTableName = DICOMSeries
    ImageTableName = DICOMImages
    DMarkTableName = DICOMAccessUpdates
    RegisteredMOPDeviceTable = RegisteredMOPIDs
    UIDToMOPIDTable = UIDToMOPID
    UIDToCDRIDTable = UIDToCDRID


    # Banner and host for debug information
    PACSName = CONQ
    OperatorConsole = 127.0.0.1


    # Configuration of disk(s) to store images
    MAGDeviceThreshhold = 0
    MAGDevices = 1
    MAGDevice0 = C:\tmp\conquest\data\
    NightlyCleanThreshhold = 0


    #Exportconverter
    ForwardAssociationDelay = 5
    ForwardAssiciationLevel = STUDY


    ExportConverters = 1



    ExportConverter0 = forward to STORESCP; between "2", "23"; defer;
    ExportModality0 = *
    ExportCalledAE0 = CONQ
    ExportCallingAE0 = STORESCU



    After sending images from storescu to conquest and then to storescp, the storescp ends with the message association aborted instead of association released. If I'm using your test tool IQ_DICOMTest.exe the association of the storescp ends always with association released.


    Why?



    Stefan

    Marcel,


    I'm using Conquest to receive and forward images. First I send MG images with Offis 3.5.4 tool storescu.exe to conquest. it is using the max PDU size of 16372. Conquest receives the images and forwards it to the Offis tool 3.5.4 storescp.exe which is also running in a command tool box (like storescu.exe). I started these tools with the following parameters:


    storescu -v -d -aet CONQ -aec STORESCU 172.21.122.136 104 test1.dcm


    storescp -v -d +xi -pdu 16372 -aet STORESCP 104


    Content of acrnema.map
    CONQ 172.21.122.136 5678 un
    STORESCP 172.21.122.136 104 un
    STORESCU 172.21.122.136 10001 un



    Content of dicom.ini
    # This file contains configuration information for the DICOM server
    # Do not edit unless you know what you are doing


    [sscscp]
    MicroPACS = sscscp
    Edition = Personal


    # Network configuration: server name and TCP/IP port#
    MyACRNema = CONQ
    TCPPort = 5678


    # Reference to other files: known dicom servers; database layout; sops
    ACRNemaMap = acrnema.map
    kFactorFile = dicom.sql
    SOPClassList = dgatesop.lst


    # Host(ignored), name, username and password for ODBC data source
    SQLHost = localhost
    SQLServer = C:\Tmp\Conquest\Data\dbase\
    Username = conquest
    Password = conquest
    DoubleBackSlashToDB = 0


    # Configure database
    TruncateFieldNames = 10
    MaxFieldLength = 254
    MaxFileNameLength = 255
    FixPhilips = 0
    FixKodak = 0
    KeepAlive = 0
    LargeFileSizeKB = 1024
    ZipTime = 05:
    UIDPrefix = 1.2.826.0.1.3680043.2.135.733224.56407500
    EnableReadAheadThread = 1
    PatientQuerySortOrder =
    StudyQuerySortOrder =
    SeriesQuerySortOrder =
    ImageQuerySortOrder =
    IndexDBF = 1
    PackDBF = 0
    LongQueryDBF = 1000
    TCPIPTimeOut = 300
    FailHoldOff = 60
    RetryDelay = 100
    QueueSize = 128
    WorkListMode = 0
    DebugLevel = 4
    Prefetcher = 0
    LRUSort =
    AllowTruncate =
    DecompressNon16BitsJpeg = 1
    UseBuiltInDecompressor = 1
    FileNameSyntax = 4


    # Configuration of compression for incoming images and archival
    DroppedFileCompression = un
    IncomingCompression = un
    ArchiveCompression = as


    # Names of the database tables
    PatientTableName = DICOMPatients
    StudyTableName = DICOMStudies
    SeriesTableName = DICOMSeries
    ImageTableName = DICOMImages
    DMarkTableName = DICOMAccessUpdates
    RegisteredMOPDeviceTable = RegisteredMOPIDs
    UIDToMOPIDTable = UIDToMOPID
    UIDToCDRIDTable = UIDToCDRID


    # Banner and host for debug information
    PACSName = CONQ
    OperatorConsole = 127.0.0.1


    # Configuration of disk(s) to store images
    MAGDeviceThreshhold = 0
    MAGDevices = 1
    MAGDevice0 = C:\tmp\conquest\data\
    NightlyCleanThreshhold = 0


    #Exportconverter
    ForwardAssociationDelay = 5
    ForwardAssiciationLevel = STUDY


    ExportConverters = 1



    ExportConverter0 = forward to STORESCP; between "2", "23"; defer;
    ExportModality0 = *
    ExportCalledAE0 = CONQ
    ExportCallingAE0 = STORESCU



    I fond out that the Conquest export filters allways forwards the images with a 4k pdu size, regardless with which pdu size the storescp is started. Is it possible to configure Conquest export filters to use a greater pdu size?


    Stefan

    Marcel,


    it seems that I have another problem. I expect the the images are forwarded at first before they are deleted from disc, because the space limit is reached. Remember: I have configured two destinations for one source:


    ExportModality0 = *
    ExportCalledAE0 = DROUTER
    ExportCallingAE0 = MLCKWMWL
    ExportConverter0 = forward to FirststorageSCP
    ExportModality1 = *
    ExportCalledAE1 = DROUTER
    ExportCallingAE1 = MLCKWMWL
    ExportConverter1 = forward to SecondstorageSCP


    Now I expect that the exports are executed at first before the images are deleted by conquest. The log file shows me that the first export converter is executed very well. Then it could happen the images are deleted before the second export converter is executed.
    How do I handle that? I'm using conquest as a dicom router only. Is it a good idea to configure the export converter like


    ExportModality0 = *
    ExportCalledAE0 = DROUTER
    ExportCallingAE0 = MLCKWMWL
    ExportConverter0 = forward to FirststorageSCP; forward to SecondstorageSCP


    instead of


    ExportModality0 = *
    ExportCalledAE0 = DROUTER
    ExportCallingAE0 = MLCKWMWL
    ExportConverter0 = forward to FirststorageSCP
    ExportModality1 = *
    ExportCalledAE1 = DROUTER
    ExportCallingAE1 = MLCKWMWL
    ExportConverter1 = forward to SecondstorageSCP




    Stefan

    Marcel,


    conquest stores our images uncompressed (*.dcm) on the harddisk. I have no idea where the 46 seconds delay come from.


    I would like to test to a higher network timeout setting. Where will I found the Version 1.14b?


    Stefan

    Marcel,


    sorry, one image takes 20MB (file size) not 20GB!!


    Quote

    Having said that, it may be possible to keep the image compressed at all time. In version 1.4.14beta we have added compression UJ: "uncompressed or jpeg" that might do the job.


    what does it mean? Should I configure conquest to store images e. g. as jpeg lossless images?


    Version 1.4.14beta is a beta version and I think that the test cycle is not finished?


    Stefan

    Quote from marcelvanherk

    Hi,


    FAILED STORAGE is rarely seen: it probably means that the incoming DICOM message is corrupt. This has no relation to export converters, I believe. The ***Client Error: Unknown Command: 0001** message is a fault in the error handling. Command 0001 is C-STORE and is correct. Looking at the log it seems that the data to be stored is missing. There also seems to be a 46 seconds delay before this message appears. Could be related to some timeout in the network. Any clue why the stored image is special. Is it very big?


    Marcel



    Hi,


    the images are MG images. One takes uncompressed 20GB. Yes, the network connection between PACS and the sender is a 2Mbit/s VPN connection SDSL. Our equipment has errors transmitting images via 2MBit/s VPN connection. The reason for using conquest was, that conquest has implemented some error handling like MaximumExportRetries. Do I get better results, if I extend e. g. the timeout?


    greetings

    hi,
    I'm using conquest 1.4.13 with mySQL 5. I configured conquest to forward the images to several destinations. It seems to work fine, but sometimes I found an error message in the log files:




    All Dicom Nodes are registered in the acrnema.map. Now my questions:


    1. What does

    Quote

    14.05.2008 15:50:19 [DROUTER] Server Command := 0001
    14.05.2008 15:50:19 [DROUTER] Message ID := 0063


    mean?


    2. What ist going on when the message



    appears? Exactly


    Quote

    14.05.2008 15:53:08 [DROUTER] ***Client Error: Unknown Command: 0001**
    14.05.2008 15:53:08 [DROUTER] ***Connection Terminated


    The hd space is 50GB. Currently used 10GB => enough space, I mean.


    dicom.ini configuration: