Posts by glevan

    Hi Marcel,


    Thanks for replying.
    I find it a bit odd that we program conquest to have a specific calling AET, Conquest then it presents itself to the vendor with that calling AET plus spaces to fill 16 characters.


    This happens on both the Called AET and Calling AET.


    I'll find a way around it I hope.


    Thanks,


    Glevan

    Hi Again,


    I don't know how to write this without coming across as stupid.
    Sending to the Archive doesn't work
    We can query/retrieve from the vendors archive without issues.
    Changing the vendors archive AET to 16 characters then sending from Conquest to the vendors archive works. If the vendors AET is "DICOM_ARCHIVE" putting "DICOM_ARCHIVE___" three spaces are behind ARCHIVE I used _ to show it, the images are received okay by the vendors archive! I have tested other vendors and some dicom test tools, they display the AET correctly. so I'm assuming some vendors can strip the space others cannot.


    Is the AET held in the DB, if so can I adjust the field to the character length for this archive.


    Really sounds dumb, doesn't it!


    Glevan

    Hi Again,


    Sorry for the previous post, it's not an issue with conquest, I can query and retrieve from the vendors archive. (AET is fine) I tried sending to it with the Conquest Test patients, these didn't go across either!


    The vendor is chasing down what is happening.


    Thanks for the forum, I've found it very useful!


    Glenn

    The sending destination has 12 Chars, in looking through the conquest debug log, I see "XXXXXXXXXXXX ", there is four spaces after the xxxxxxxxxxxx as the called AET, the receiving destination is rejecting our system, I'm assuming it's because of the "padding/spaces"


    Thanks,


    Glenn

    Thanks Marcel,


    Worked well!


    We have another issue associated with this, the called AET is being padded out with spaces, the receiving device is not promiscuous. I’ve been able to change the conquest AET to 16 char. Is there a way of limiting the AET in the known providers to the name specified, without the program padding the AET with spaces on sending.


    Glenn

    Thanks Marcel,


    This didn't fix my problem, have since found that the Vendor only supports extended negotiations for DICOM associations. When another program does not support extended negotiations for DICOM associations, it fails. The vendor is looking at changing its behaviour.


    Glenn

    Recently we've just gone to PACS, we've had our Conquest server for some time now and would like the vendor to connect to our Conquest Server. When they do a query to our Conquest server we get the following error


    4/04/2007 2:45:52 PM [CONQUESTTEST1234] UPACS THREAD 0: STARTED AT: Wed Apr 04 14:45:47 2007
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] Calling Application Title : "QUERY_TEST"
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] Called Application Title : "CONQUESTTEST1234"
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] Application Context : "1.2.840.10008.3.1.1.1"
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.1.1"
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] Presentation Context 1 "1.2.840.10008.5.1.4.1.2.1.2"
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] Presentation Context 2 "1.2.840.10008.5.1.4.1.2.2.1"
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] Presentation Context 3 "1.2.840.10008.5.1.4.1.2.2.2"
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] Presentation Context 4 "1.2.840.10008.5.1.4.1.2.3.1"
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] Presentation Context 5 "1.2.840.10008.5.1.4.1.2.3.2"
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] *** Association rejected: you may need to add the listed presentation context as sop to dgatesop.lst
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] UPACS THREAD 0: ENDED AT: Wed Apr 04 14:45:52 2007
    4/04/2007 2:45:52 PM [CONQUESTTEST1234] UPACS THREAD 0: TOTAL RUNNING TIME: 5 SECONDS


    AET's match okay in known server tab.


    Conquest has all the sop listed in the dgatesop.lst our server was 1.4.12c now is 1.4.13alpha with the same results.


    Is there away of setting "accept any context" I've tried renaming the dgatesop.lst as mentioned in a previous post, when restarting the server it created a new dgatesop.lst with the same sop's


    Thanks.......