Posts by kakarr0t

  • Detailed Logging for Errors

    Marcel, I'm wondering what is the best way to NULL all private tags, via the ImportConverter, such as ones beginning in (0009, xxxx)? is there a simple way to do this so that it applies to all private tags? Thanks! --Tim

  • Detailed Logging for Errors

    I believe that did the trick! Out of curiosity, (1) why did we need to put this in its own section? and (2) if we wanted to tailor/truncate other DICOM fields to have a certain amount of characters, could we just add them to this same section?


    Thanks! --Tim

  • Detailed Logging for Errors

    Thanks for your input Marcel. I tried the following and it doesn't seem to work.



    ImportConverters = 5
    ...import converters
    ImportConverter4 = Data.ReasonForStudy = string.sub(Data.ReasonForStudy, 1, 64)



    I get this error
    "Fri Jul 31 11:34:32 2015 *** Importconverter4.0 error: Data.ReasonForStudy = string.sub"



    Thanks for your help. --Tim

  • Detailed Logging for Errors

    There are no network issues. Generally when we get errors, it's because there's something wrong with incoming dicom, and our archive rejects things that aren't formatted properly. For instance a field has too many characters or unsupported asian characters, etc.


    So now I have two questions. (1) what would the syntax be for enabling debug logging automatically around every retry, and (2) how would you word the syntax to create an export converter that automatically truncates the dicom (0032,1030) down to 64 characters? or is there a better way?


    I noticed in the windowsmanual that there is an option for TruncateFieldNames = 10... however I don't think that would apply to dicom (0032,1030), nor would AllowTruncate = ... Am I correct that these two are irrelevant in this case?

  • Detailed Logging for Errors

    Hey Marcel,


    The holding occurs frequently and most of the time things will process /send to archive. However, occasionally, some images will permanently queue/fail and then all of the other images back up in the queue and will not forward to the archive until we delete the guilty images. It's tough to fix the root cause when we don't have enough logging, nor is it simple to write a script to automatically clean these troublesome images up if we don't know why they're permanently queuing/failing.


    Is there a way to enable logging that will at least give us a reason for queuing/failing? Thanks. --Tim

  • Detailed Logging for Errors

    **Running Ver 1417b**


    Is there any way to configure more detailed logging in dicom.ini so I know why an image has been put in "Queue: holding" and why it has "Forward failed"?


    Mon Jul 20 16:26:47 2015 *** Queue: holding processing of file ./data/3755998/1.2.840.114384.52123467.20150720.162151.2_0001_000001_14374312071e04.v2
    Mon Jul 20 16:26:48 2015 *** ExportConverter0.0: Forward failed to send DICOM image to PACS_ARCHIVE


  • Archive Query / C-Find

    Great!


    I'm attempting to do one more thing and have been unable to find any clear-cut method or examples in the user manual.


    From the modality, I would like to send a worklist query to Conquest and have Conquest query our worklist server and return the results back to the modality. I'm sure I'll need to add our worklist server in acrnema.map, however I'm not certain of the syntax I should use in our dicom.ini. What would you suggest to get modality worklist queries working? Thanks!


    --Tim

  • Archive Query / C-Find

    Is there any way to do a C-Find to query our archive via conquest?


    Our current use of conquest allows us to send images from modality to conquest, which conquest forwards to our archive. We would like to have the modality send a C-Find conquest, which would forward the C-Find to archive, then return the results back to the initial modality who requested the query. I hope I'm making sense. Thanks!


    --Tim

  • My Conquest Setup :: Dicom Routing/Failover/Load Balance

    I have a problem I'm not sure how to resolve. Thanks for your help in advance!


    I switched to using the database option, because for a reason I don't understand, Conquest would drop images and they'd forever be lost with no clue why. With the database, at least Conquest attempts to resend images that never transferred to our PACS server.


    So my problem is that several images aren't storing to our PACS server and Conquest is saving them on our hard disk making our hard disk run out of space.


    (a) First off, how do I delete studies? When I attempt to delete them, I get this error. I need to be able to delete images so we don't run out of disk space. I'm open to any suggestions.


    Fri May 9 17:20:36 2014 Server command sent using DGATE -- option
    Fri May 9 17:20:36 2014 ***[DeleteImageFile] 1.2.392.200036.9116.2.5.1.37.2427348772.1399422929.550923 -FAILED: Error on Load


    The command I'm using is /conquest/dgate --deleteimagefile:SOPID


    (b) Next, the error I'm getting for the images Conquest has decided not to send and is holding on to are below. Is there any way to get Conquest to ignore these types of errors and send them to our PACS destination regardless? Any other suggestions?


    Thu May 8 00:37:16 2014 Inconsistent SeriesTime in DICOMSeries: PatientID = '29153XXX' SeriesInst = '1.2.840.113619.2.5.24251717.1399508756.601.5' AND SeriesPat = '2915350', Old='003211', New='003212'
    Thu May 8 03:51:18 2014 Inconsistent StudyDescr in DICOMStudies: PatientID = '1560XXX' StudyInsta = '1.2.840.113696.305193.500.1018047.20140508010225', Old='CT ABD/PEL W IV CON', New='PAPERWORK'
    Thu May 8 03:51:18 2014 Inconsistent ReferPhysi in DICOMStudies: PatientID = '1560XXX' StudyInsta = '1.2.840.113696.305193.500.1018047.20140508010225', Old='DOCTOR^UNASSIGNED^^^', New='HAUKOOS^JASON^^^'
    Thu May 8 07:12:51 2014 Inconsistent PatientNam in DICOMPatients: PatientID = '36222XXX' PatientID = '36222XXX', Old='MCGEE^GARRICK^^^', New='MCGEE^GARRICK'


    --------------------------------------------
    Here's my latest dicom.ini config.
    --------------------------------------------


  • My Conquest Setup :: Dicom Routing/Failover/Load Balance

    Marcel, I think we figured it out. I've updated our ExportConverter to the following ::


    ExportConverters = 1
    ExportConverter0 = forward to PACS_ARCHIVE org %u; nop %u %m %i %o; delete series after 600;


    My goal is with delete series after 600, that images will be removed after 10 minutes.


    It seems to be working, according to our logs


    Fri Mar 7 11:48:31 2014 Removed file: [MAG0:354660/1.2.840.113619.2.5.23161817.1394191978.602.5_0602_000146_139421751201ec.v2]
    Fri Mar 7 11:48:31 2014 Removed file: [MAG0:354660/1.2.840.113619.2.5.23161817.1394191978.602.5_0602_000147_139421751201ed.v2]
    Fri Mar 7 11:48:31 2014 Removed file: [MAG0:354660/1.2.840.113619.2.5.23161817.1394191978.602.5_0602_000148_139421751301ee.v2]
    Fri Mar 7 11:48:31 2014 Removed file: [MAG0:354660/1.2.840.113619.2.5.23161817.1394191978.602.5_0602_000149_139421751301ef.v2]


    One other question, does the log below mean the image didn't store to PACS so it's being "rewritten" or resent?


    Fri Mar 7 11:52:48 2014 Rewritten file: ./data/2535695/1.2.840.113619.2.334.3.554316804.426.1386551381.289_0002_000014_13942134260039.v2



    Thanks again for your help.

  • My Conquest Setup :: Dicom Routing/Failover/Load Balance

    I have a couple questions... Did you leave something out here?


    Quote

    or (delayed sending, default after 5 minutes)


    ExportConverters = 1
    ExportConverter0 = forward series to PACS


    With the below config, specifically for deleting studies after an hour, I don't see in the logs where studies are being deleted/destroyed and our space is filling up on our hard disk. Should the syntax be destroy instead of delete after 3600? If I search /conquest/serverstatus.log, what key word could I search by to see if conquest is deleting images after an allotted time? I also tried searching the documentation for this answer, but couldn't find it.


    ExportConverters = 2
    ExportConverter0 = forward to PACS_ARCHIVE org %u; nop %u %m %i %o;
    ExportConverter0 = delete series after 3600


    Thanks for your help Marcel.


    --Tim

  • My Conquest Setup :: Dicom Routing/Failover/Load Balance

    (1) I'm still getting errors where half of a study won't transfer over to PACS, any thoughts?


    Thu Mar 6 10:55:19 2014 Importconverter0.1: nop DIMENSIONS_AWS MG 479541 1.2.840.113681.169936052.1392965017.4388.425
    Thu Mar 6 10:55:19 2014 Importconverter0.2: destroyed received image
    Thu Mar 6 10:55:19 2014 UPACS THREAD 2264: ENDED AT: Thu Mar 6 10:55:19 2014
    Thu Mar 6 10:55:19 2014 UPACS THREAD 2264: TOTAL RUNNING TIME: 4 SECONDS
    Thu Mar 6 10:55:22 2014 ImportConverter0.5: forwarded object to VMLTA02_ARCHIVE
    Thu Mar 6 10:55:24 2014 Importconverter0.1: nop DR2_CHC CR 1343659 1.3.46.670589.26.602358.4.20140306.105357.117736.0


    Thu Mar 6 10:56:11 2014 UPACS THREAD 2266: STARTED AT: Thu Mar 6 10:56:11 2014
    Thu Mar 6 10:56:11 2014 Calling Application Title : "DIMENSIONS_AWS "
    Thu Mar 6 10:56:11 2014 Called Application Title : "CONQUESTSRV1 "
    Thu Mar 6 10:56:11 2014 Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
    Thu Mar 6 10:56:11 2014 Presentation Context 0 "1.2.840.10008.5.1.4.1.1.1.2" 1
    Thu Mar 6 10:56:12 2014 ImportConverter0.6: forwarded object to VMLTA02_ARCHIVE
    Thu Mar 6 10:56:12 2014 *** ImportConverter0.6: Forward failed to connect to host VMLTA02_ARCHIVE
    Thu Mar 6 10:56:12 2014 Importconverter0.1: nop DIMENSIONS_AWS MG 479541 1.2.840.113681.169936052.1392965017.4388.407
    Thu Mar 6 10:56:12 2014 Importconverter0.2: destroyed received image
    Thu Mar 6 10:56:12 2014 UPACS THREAD 2266: ENDED AT: Thu Mar 6 10:56:12 2014
    Thu Mar 6 10:56:12 2014 UPACS THREAD 2266: TOTAL RUNNING TIME: 1 SECONDS


    (2) If there's no clear solution to this problem, I would like to try setting up ExportConverter0 so that we can utilize RetryDelay and RetryForwardFailed


    What is the proper syntax for converting this statement from ImportConverter into ExportConverter?


    ImportConverter0 = forward to PACS_ARCHIVE org %u channel *; nop %u %m %i %o; destroy;


    perhaps?


    ExportConverter0 = forward to PACS_ARCHIVE org %u channel *; nop %u %m %i %o; destroy;


    Once the image has successfully stored, I want Conquest to destroy the image, will I need to use destroy; just as I did with ImportConverter0?


    (3) Just so I understand correctly, regardless of the fact that I already have RetryDelay and RetryForwardFailed configured, they aren't actually being triggered unless (a) I'm using a database and (b) I'm using Exportconverter0..... Is this correct? Thanks!


    --Tim

  • My Conquest Setup :: Dicom Routing/Failover/Load Balance

    Hi Marcell,


    I set ForwardAssociationLevel = SERIES


    If it's set to SERIES, would there be an association per each SERIES or IMAGE?


    Our current ImportConverter is


    ImportConverter0 = forward to PACS_ARCHIVE org %u channel *; destroy;


    To add more logging, would it look like this?


    ImportConverter0 = forward to PACS_ARCHIVE org %u channel *; destroy; nop %u %m %i %o;


    I noticed in the manual, it has these additional settings


    ImportConverter1, ImportConverter2, ImportConverters =1, etc...


    I guess I don't understand when/why you would set these additional attributes, I hope this isn't a stupid question. But what are these for? ImportConverter1, ImportConverter2, ImportConverters =1



    If we use ExportConverters, would we still need the ImportConverter0 option? or would ExportConver0 take its place?

  • My Conquest Setup :: Dicom Routing/Failover/Load Balance

    I could really use some assistance please. I'm getting tons and tons of these messages on both of my conquest servers.


    Code
    root@vlconquest01:/conquest/logs# less 20140304/PacsTrouble.log-20140304Mon Mar  3 10:54:20 2014 *** ImportConverter0.4: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:20 2014 *** ImportConverter0.4: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:20 2014 *** ImportConverter0.4: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:20 2014 *** ImportConverter0.4: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:20 2014 *** ImportConverter0.3: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:21 2014 *** ImportConverter0.5: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:21 2014 *** ImportConverter0.5: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:21 2014 *** ImportConverter0.5: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:21 2014 *** ImportConverter0.5: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:21 2014 *** ImportConverter0.5: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:28 2014 *** ImportConverter0.7: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:28 2014 *** ImportConverter0.7: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:28 2014 *** ImportConverter0.7: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:29 2014 *** ImportConverter0.8: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 10:54:29 2014 *** ImportConverter0.8: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 12:32:35 2014 *** ImportConverter0.6: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 12:38:43 2014 *** ImportConverter0.18: Forward failed to connect to host PACS_ARCHIVEMon Mar  3 12:56:00 2014 *** ImportConverter0.6: Forward failed to connect to host PACS_ARCHIVE


    I found that some of these ImportConverter0.X (where 'X' is a number) have more instances than others.


    Code
    root@vlconquest01:/conquest/logs/20140304# awk '{print $7}' PacsTrouble.log-20140304 | sort | uniq -c      1 connection      2 ImportConverter0.0:     48 ImportConverter0.1:      1 ImportConverter0.18:    192 ImportConverter0.2:      1 ImportConverter0.3:     96 ImportConverter0.4:    257 ImportConverter0.5:    701 ImportConverter0.6:    105 ImportConverter0.7:     23 ImportConverter0.8:



    Code
    root@vlconquest02:/conquest/logs/20140304# awk '{print $7}' PacsTrouble.log-20140304 | sort | uniq -c

          5 connection

          1 ImportConverter0.1:

          1 ImportConverter0.11:

          1 ImportConverter0.14:

        450 ImportConverter0.15:

          1 ImportConverter0.2:


    On conquest01, ImportConverter0.6 has the most hits (701) and
    on conquest02, ImportConverter0.15 has the most hits (450).


    I don't quite know what to think of this, but we've got hundreds of instances where we are unable to send images to our PACS via conquest.


    Do you have any idea what could be the problem and how to fix this? Thanks for your help.


    --Tim

  • My Conquest Setup :: Dicom Routing/Failover/Load Balance

    I also noticed we're getting several association aborts on our PACS, from sends from Conquest


    One error we get on our PACS is


    Unrecognized PDU


    Our PACS PDU is set at 128k and below


    Grep'ing for PDU in serverstatus.log on Conquest shows Conquest is sometimes receiving from modalities at 256k, I don't know for sure, however I'm assuming if Conquest receives at 256k, it's also sending to our PACS at 256k. How can we know for sure if this is the case?


    Most importantly, our PACS archive PDU length is set to not exceed certain values, so is there any way we can constrain the PDU length on Conquest (receiving from modalities/sending to PACS)? Thanks again!


    --Tim

  • My Conquest Setup :: Dicom Routing/Failover/Load Balance

    Hi, I keep getting this error in Conquest. Originally, I thought it was a problem caused by the interaction with Keepalived, however, I've shutdown Keepalived and am running Conquest on its own and still get the error.



    After we receive this error, often a technician will call us and let us know one series from their study didn't store to PACS. We don't usually have this problem when sending studies directly to PACS. I'm wondering if perhaps Conquest is making too many simultaneous connections to our PACS or if Conquest just doesn't retry enough times...


    I've got these two options enabled in Conquest regarding retries.


    Quote

    RetryDelay = 30
    RetryForwardFailed = 1


    (1) Is there anything else I can do to resolve this problem or have Conquest retry more often, etc?
    (2) Also, is there any way to get more information as to why Conquest failed to send or connect to PACS and what in particular it was trying to send in that moment?


    Thanks for your help!


    --Tim

  • My Conquest Setup :: Dicom Routing/Failover/Load Balance

    It's been a week and no problems. The only change I made was disabling keepalived and sending our DICOM images to just one of the Conquest servers. This morning, I implemented the changes discussed previously, regarding running with no database and using the channel option. After implementing these two changes and restarting the Conquest dgate service, I received this message in the log file


    Mon Feb 17 09:22:51 2014 *** Not enough rights to write in MAG0
    Mon Feb 17 09:22:51 2014 Started zip and cleanup thread
    Mon Feb 17 09:22:51 2014 DGATE (1.4.17c, build Fri Nov 22 15:38:03 2013, bits 64) is running as threaded server
    Mon Feb 17 09:22:51 2014 Database type: NULL driver (black hole)


    I'm not sure what the MAG0 permission error is referrencing... Any thoughts?


    If the system runs fine like this for another week, then I'll re-enable keepalived for load balancing for another week after that and see if we run into the previous problems where Conquest was failing to send after 3-4 days, in which case I may create a script to restart keepalived every 2 days. I'll keep you guys posted as to what will ultimately be our most stable setup for performance/reliability.

  • My Conquest Setup :: Dicom Routing/Failover/Load Balance

    Hi Marcel, we are using 1.4.17c.


    I've updated the Conquest config file with the following changes


    Edits for no database
    SQLHost =
    SQLServer =
    Username =
    Password =
    PostGres = 0
    MySQL = 0
    SQLite = 0


    Although I've confirmed our Conquest forwards on a series level by default, I've added this line per your suggestion
    ForwardAssociationLevel = SERIES


    And my last question is regarding the channel option. I'm not sure if I've got the proper number/position of simicolons ";"


    Is this the correct format for our forward statement with the channel option added for automatic channels?
    ImportConverter0 = forward to VMLTA01_ARCHIVE org %u channel *; destroy;


    Thanks for your help!