Problems with the obtaining of the Print Job Id - DICOM

This is a discussion on Problems with the obtaining of the Print Job Id - DICOM ; Hello, We are developing a software that prints Dicom images. We also want to follow the Execution Status using Print Job SOP Class. I've read in PS-3.6 2007 that the attribute Referenced Print Job Sequence (2100,0500) is retired. I obtain ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Problems with the obtaining of the Print Job Id

  1. Problems with the obtaining of the Print Job Id

    Hello,

    We are developing a software that prints Dicom images.
    We also want to follow the Execution Status using Print Job SOP Class.
    I've read in PS-3.6 2007 that the attribute Referenced Print Job
    Sequence (2100,0500) is retired. I obtain this sequence from the
    N-ACTION Response from the Basic Film Session SOP Class in order to get
    the Print Job Id.

    If the attribute Referenced Print Job Sequence has been retired, is
    there any other way to obtain the Print Job Id?

    Thanks,

    Marta


  2. Re: Problems with the obtaining of the Print Job Id

    Hello,

    I think there is no definitive method for print monitoring.

    On the one hand there was the Print Queue Management SOP Class, which
    you cannot rely on since it was retired in 2006 edition.

    On the other hand, there is the Print Job SOP Class, which lets you be
    informed by the printer by receiving N-EVENT-REPORTS. Unfortunately,
    it is an optional SOP Class so you cannot expect the printer to
    implement it.

    As far as I know, there is no general method to know when a print job
    has finished and how it finished.
    As a curiosity, if the SCU never knows when a print job has finished,
    when should the SCU send N-DELETE to delete the Basic Film Session SOP
    Instance?

    See you,
    ivan


  3. Re: Problems with the obtaining of the Print Job Id

    Hi,

    we normaly send N-Delete directly after the N-Action has been send and
    answered.
    Luckily most (or all) printers seem first to print and delete afterwards.
    Our customers did not have problems with this solution yet

    Print is realy the dark side of DICOM I think.

  4. Re: Problems with the obtaining of the Print Job Id

    > As far as I know, there is no general method to know when a print job
    > has finished and how it finished.


    If I remember correctly, the original idea of the DICOM Print Management Service Class was that a
    Print SCP and SCU would either negotiate the Print Job SOP Class, in which case the completion of a
    print job would be notified through an EVENT-REPORT-RQ, or alternatively the Print SCP would not
    return the N-ACTION-RSP before the print job was completed. In fact, however, all printers I am
    aware of return the N-ACTION-RSP immediately, so the Print SCU cannot know when the print job
    is completed.

    > As a curiosity, if the SCU never knows when a print job has finished,
    > when should the SCU send N-DELETE to delete the Basic Film Session SOP
    > Instance?


    This is clearly defined. As a result of the N-ACTION transaction, the Print SCP will create a
    "snapshot" of the complete print session, and process the print job based on this snapshot.
    That means, as soon as the Print SCP returns the N-ACTION-RSP message, the SCU can safely
    delete or modify objects without affecting the print job in progress.

    Regards,
    Marco Eichelberg
    OFFIS

  5. Re: Problems with the obtaining of the Print Job Id

    Hello,

    Thanks for the answers.

    I have a doubt with the N-EVENT-REPORT service from the Printer class.
    Has Print Client to be prepared to receive N-EVENT-REPORT message at
    any time?

    I mean, is it possible that Print Client is sending a message (such as
    N-ACTION-RQ, N-CREATE-RQ...) at the same time that the Print Server
    sends a N-EVENT-REPORT-RQ?

    If messages are sent simultaneously the Print Server may receive N-
    ACTION-RQ, N-CREATE-RQ... as a response to a N-EVENT-REPORT-RQ.

    Is this an unintended case of asynchronous operation?

    Thanks in advance,

    Marta


  6. Re: Problems with the obtaining of the Print Job Id

    marta.pujol@gmail.com wrote:
    > I have a doubt with the N-EVENT-REPORT service from the Printer class.
    > Has Print Client to be prepared to receive N-EVENT-REPORT message at
    > any time?


    Yes, absolutely.

    > I mean, is it possible that Print Client is sending a message (such as
    > N-ACTION-RQ, N-CREATE-RQ...) at the same time that the Print Server
    > sends a N-EVENT-REPORT-RQ?


    Yes.

    > If messages are sent simultaneously the Print Server may receive N-
    > ACTION-RQ, N-CREATE-RQ... as a response to a N-EVENT-REPORT-RQ.


    Correct.

    > Is this an unintended case of asynchronous operation?


    This is asynchronous, but not unintended - this is how the N-EVENT-REPORT
    primitive works, and any SOP Class that makes use of event report
    along with one of the other DIMSE-N messages has this feature.

    This is different, though, from the kind of asynchronous communication
    negotiated through the async message window in DICOM - that would allow
    one side to send multiple messages without waiting for incoming responses.

    That said, one of the first configuration options I had to implement in
    our DCMPRINT Print SCP was an option to disable the generation of
    N-EVENT-REPORTs, because MANY SCUs fail to correctly handle them.

    Regards,
    Marco Eichelberg
    OFFIS

+ Reply to Thread