A Print Problem

  • Hi Everyone:
    I use 2 devices to send images to a Conquest Sever to print them in PDF files. The order of DIMSEs is:


    1, device 1: N-CREATE (Film Session)
    2, device 1: N-CREATE (Film Box)
    3, device 2: N-CREATE (Film Session)
    4, device 2: N-CREATE (Film Box)
    5, device 1: N-SET
    6, device 2: N-SET
    7, device 1: N-ACTION
    8, device 1: N-DELETE
    9, device 2: N-ACTION
    10, device 2: N-DELETE


    But after printing, there is only ONE pdf file, and the file only have ONE page. 2 images are printed on the same page and same position.The 1st image is covered by the 2nd image.(I can seperate them by using PDF Editor)


    Actually, the image from device 2 is printed after step 7. In Step 9, nothing is printed.


    Is there anyone knows the reason?


    Thanks very much!

  • Hi,


    as documented in the manual, the actual printing interface in the conquest GUI is unfortunaly not multi-user safe. Can you show me the Server status log of your overlapping operation? Maybe I can use the thread number to separate the jobs.


    Marcel

  • Yes, there are 2 threads. But their logs are cross with each other.


    The original problem is that we send 3000 patients to a Conquest Server for printing and storage from ONE device. Every patient contains 1 exam ,and every exam contains 1 image. But the printed result only have 2966 pages.
    It seems that many lines in the log files is lost. these are numbers of lines in the log file in the latest test. the numbers is not constant in every test.


    "Written file:..." 2997 times
    "Creating Basic Film Session" 2967 times
    "Creating Basic Film Box..." 2960 times(the fisrt is film# 0, and the last is film# 2999)
    "Printing file:..." 2992 times
    "Printing Basic Film Box" 2966 times
    "UPACS THREAD XX: STARTED AT..." 5959 times (the fisrt is thread 1, and the last is thread 6000)


    the problem may only occur on my computer,because when we use another computer as conquest server, the printed result and the log are both correct.


    Is this problem related with computer environment?

  • Hi,


    The print server uses the GUI log, which is known to drop lines if the server is very busy. So, the printer option is not production grade. That one machine works and the other not maybe related to having a different number of cores?


    I will see what I can do to improve upon this problem for upcoming releases.


    Marcel

  • Hi Marcel,


    the cpu of the one works is Intel Pentium Dual E2180 @ 2.00G, and the cpu of the one NOT works is Intel Core2 Duo E4600 @ 2.40G. They both have 2 cores. The 2nd cpu is more strong than the 1st one, and we didn't run any other program during test.Why the server is busier on the 2nd cpu?


    Even if on the problem computer, this problem didn't occur before several weeks. so I can't determine the reason. you said that if the server is busy,it will drops logs. then, In this condition, will it drop the processing of printing request ? In log file ,"Printing Basic Film Box" apears 2966 times. And the printed result has 2966 pages. Can this prove that the server processes N-ACTION-RQ 2966 times?


    Do you know how can I reappear the dropping log problem on other cpu? I tried that running other programs to raise the usage of cpu. then the logs refreshed very slow, but they didn't drop any line.


    thank you very much!

  • Quote from marcelvanherk

    Hi,


    as documented in the manual, the actual printing interface in the conquest GUI is unfortunaly not multi-user safe. Can you show me the Server status log of your overlapping operation? Maybe I can use the thread number to separate the jobs.


    Marcel


    Hi,


    Could you tell me the position where the manual says that the actual printing interface in the conquest GUI is not multi-user safe. I want to read the detail and expain to my colleague.


    Thank you very much!

  • Hi,


    I had to look carfully as well: it is in DicomConformance_FilesLST_Changes.pdf, on page 9 and 10.:


    Quote

    The CONQUEST user interface (Windows only) will queue incoming
    images and will asynchronously convert each DICOM file into a BMP file,
    load it in memory and assemble the pictures to be printed on a page.
    Processed DICOM files and BMP files are deleted. Note: the basic print
    support in the CONQUEST user interface will not handle multiple
    simultaneous print requests correctly!


    Marcel

  • hi,


    I added some code in dgate.exe to directly send 3000 groups of SocketUDP to GUI program, just like the way when processing dicom print request. And I put 3000 dcm files in the data/printer_file folder. But after printing, the windows print queue only had 2996 files. 4 files were left in the data/printer_file folder.


    Is that because dgate.exe send SocketUDP too fast and GUI program process too slow?


    thank you!

  • Hi,


    that is correct - the GUI cannot keep up. And it does not distinguish between print jobs of different users, so they get mixed if you print at the same time. A better solution would be to print directly from dgate.exe, where each job is processed in a different thread. But that requires quite a bit of coding.


    Marcel

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!