Posts by ctao

    thank you Sabine - the entry "DIMSE receiveFileData: 16378 bytes read <last: NO>" is the last one that I have seen. It has not been followed by a "YES".

    Although - I have not seen the "DIMSE receiveFileData: 16378 bytes read <last: NO>" at all the past couple times I ran verbose mode, including now after I created a new imagebox in C:\

    Now the log entry reads:

    PDU Type: Associate Request, PDU Length: 202 + 6 bytes PDU header
    01 00 00 00 00 ca 00 01 00 00 4f 4e 49 53 32 32
    20 20 20 20 20 20 20 20 20 20 4f 4e 45 50 41 43
    53 50 4f 4c 4c 45 52 20 20 20 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 10 00 00 15 31 2e
    32 2e 38 34 30 2e 31 30 30 30 38 2e 33 2e 31 2e
    31 2e 31 20 00 00 2e 01 00 00 00 30 00 00 11 31
    2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 31
    40 00 00 11 31 2e 32 2e 38 34 30 2e 31 30 30 30
    38 2e 31 2e 32 50 00 00 37 51 00 00 04 00 02 00
    00 52 00 00 11 31 2e 32 2e 34 30 2e 30 2e 31 33
    2e 31 2e 31 2e 31 53 00 00 04 00 00 00 00 55 00
    00 0e 64 63 6d 34 63 68 65 2d 31 2e 34 2e 33 31

    Our Implementation Class UID: 1.2.826.0.1.3680043.2.360.
    Our Implementation Version Name: IIS_354
    Their Implementation Class UID:
    Their Implementation Version Name: dcm4che-1.4.31
    Application Context Name: 1.2.840.10008.
    Calling Application Name: ONEPACSPOLLER
    Called Application Name: ONIS22
    Responding Application Name:
    Our Max PDU Receive Size: 16384
    Their Max PDU Receive Size: 131072
    Presentation Contexts:
    Context ID: 1 (Proposed)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Accepted SCP/SCU Role: Default
    Proposed Transfer Syntax(es):
    Requested Extended Negotiation: none
    Accepted Extended Negotiation: none
    called AE: ONIS22
    Constructing Associate AC PDU
    DIMSE receiveCommand


    does any of that make sense to you? it does not to me, except that I think one of my sending stations is called "ONIS22" and/or "ONEPACSPOLLER" - although I do not actually know who they are!

    I will be checking with my sending station's vendor later today to hopefully get a more detailed log.

    I think my hard disk still has room, 347 GB used, 233 GB free. My database (imagebox, right?) is, or was: C:\KPacs\Imagebox\
    now the database is C:\KPACSImagebox\

    I'll have to get someone to send me something and see what happens and will keep you posted. Thank you again for your help and expertise, Sabine!

    Quote from Sabine Stridde

    This means that K-PACS is currently receiving data. The images are sent over the network in individual data packages of 16378 Bytes per package (= PDU size). The information "<last: NO>" means that the just received package is not the last one and that more data will follow. It will keep the association open.

    Ah great, I thought I was getting somewhere :( sorry I assumed that this meant that I was receiving images. I guess I am receiving data, but not enough, so the studies are incomplete? So I am in fact not receiving the images.

    To make matters more complicated, one of my sending stations reported the error message was in the AET. I have never changed mine, and neither has the sending station, but we checked anyway and of course they were the same.

    I do not have any filters on, and I have 1066 studies in my worklist, and 1097 folders in the KPacs/Imagebox. I am not sure why there is a difference, but I did just delete a bunch of older studies. I assume when I delete them from KPACS that they are deleted from the computer file folder...?

    If I sort the computer files by date, I do not find any of the "missing" studies, at least within the past week or so when this started happening

    thank you for all your help, Sabine. It seems like KPACS is receiving the data, but there is something internal to KPACS that is not allowing the images to appear in the worklist. When I run verbose mode,I get other info in the log but mostly it's that line, "DIMSE receiveFileData: 16378 bytes read <last: NO>" that I see, and there are no new images that appear in the, a software bug is how I see it. I will look into other programs including iQ-VIEW. thank you again! :)

    ok, I was wondering how to activate verbose mode - didn't know you had to stop the server. you are right the log is pretty long and I cannot even scroll up to see the full log anymore...but right now there are probably hundreds of lines saying the same thing:

    DIMSE receiveFileData: 16378 bytes read <last: NO>

    what does that mean?

    if I get iQ-VIEW I want to make sure these issues do not occur again.

    thank you for your help Sabine!

    ok thanks Sabine. my dynamic IP has not changed in about a year, and every time I have problems receiving images, I check the IP and it is the same. I also check my download/upload speeds and they are normal.

    I have also checked the Server Admin Tool (under Local Settings), and the KPACS server status always says: "Server is running" Is there something else I should be looking for?

    thanks Sabine. sorry if this is a duplicate post - not sure where the other one went. anyway, I do NOT have a static IP. I used to, but then discovered the dynamic IP accounts were much less expensive and the address never changes anyway...but it sounds like there may be some other issues as well? do you know if having a dynamic IP address (that stays the same) may be an issue?

    the cost to have a similar down/upload speeds (similar to my current residential account) with addition of a static IP over here requires a business account which is about 3X the cost!

    thank you, Sabine. I have not noticed any particular time of day that is prone to this problem. I am receiving plain x-rays only from several different sources/stations. Some just send a few images at a time, some may send 50 at a time, but the problem exists regardless of incoming volume. I'm not sure what multi-frame images are - are they multiple images that can be scrolled thru? - I do not usually receive those types.

    the log or error message on the sending machine side says, "communication error", or on another source it will say:

    Device Error Occurred
    [Socket Connection Error]

    my process log (in process manager) doesn't seem to show any errors - it always says it's listening on port 104

    I have adequate download speed (80 Mbps), but I my sending machines have DSL and so their upload speed should be ok (?), but at about 1.5 Mbps.

    Any other ideas? could it be that the slower connection on the sending side is a problem?

    Hello, I am new to this forum!

    I have been using KPACS 1.6 to receive images from multiple servers (they are actively sent from multiple servers). KPACS will intermittently not be able to receive the images - servers will report an error message - sometimes this is resolved with a re-boot, but not always. I have Win 7 64. I don't see anything showing in Process Log, and my status is always "listening".

    Is this a common problem (I have not seen any other posts about this specifically)?

    Please help! I am not that tech-savvy. Thank you in advance!