跳至主內容

搜尋

搜尋

Printer Restarting A Print Job

評論

3 條評論

  • Avatar
    Shotaro Ito
    [quote name='nRyder' timestamp='1342712804' post='2901']
    Every now and then, the printer will stop printing, pause for a bit, and then restart printing [b]from the beginning of the print job[/b]. This is extremely wasteful to resources and expensive materials. How could this possibly be happening? The print spooler must be re-sending this data, as it would not have been stored locally in the printer for that long. The user of this PC has disabled Bi-Directional Support in the printer properties due to past issues. Should this be re-activated?
    [/quote]
    Don't have a very good idea...

    Uninstall current driver and try the latest Seagull driver, revert to default setting, direct USB to USB (without docking station), take all other USB device out and try again to see if that's repeatedly happens.
    Enable bi-directional support, and Tools > Logging options, enable printer job logging and printer code recording to see what actuary happening.

    About BarTender 10.0 upgrade or not,I'm not sure that's even related to BarTender or not. Check if that happens with other software by printing from Word, excel etc.
    0
  • Avatar
    Legacy Poster
    Thanks for the thoughts. It's a very tough issue to track down, since it doesn't appear to be immediately replicatable. It seems to happen once every 2 or 3 weeks during a print job, but that is too many times. I have seen a couple other forum posts of users with this issue doing print jobs through Word on a sheet-fed printer - so it's highly possible it is not BarTender specific.
    0
  • Avatar
    Ian Cummings
    版主
    This could be a memory heap issue. How is printing from/via BarTender set-up is Commander being used or some other service made by yourselves for controlling BarTender? Here follows a description of what the non-interactive desktop heap is and how it can affect some perpetually automated BarTender printing solutions.

    Desktop Heap

    Synopsis
    When BarTender is used in a "service context", it can be negatively impacted by a system setting known as "desktop heap". It is important to understand when this can occur, and how to correct the problem.

    Desktop Heap
    The "desktop heap" is a certain area of memory that is used to store information about windows, as well as objects that are used for drawing and printing. For more advanced technical information about what desktop heap is, see here: http://blogs.msdn.com/b/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx

    In general, console (command line) applications do not use desktop heap memory. However, BarTender is a "Windows application", rather than a console application. When Commander controls bartend.exe processes one must understand that the BarTender application file is an integral part of the label designer, and it is impossible to print without creating several different windows, including the entire editor view. Those windows exist even when you cannot see them, and they use "desktop heap" memory.

    Each instance of BarTender takes up desktop heap memory, and each format that is opened uses a bit more. (The exact numbers are difficult to measure, and vary by version, but in general as we add features in newer versions, we've been using a bit more desktop heap.)

    The total amount of desktop heap memory depends on the "session" you are using. When you log in to your system, you have a visible "desktop" that belongs to your user name. That session has a block of heap memory, which is shared between applications in that session. If a different user logs in through Remote Desktop, they are using a separate desktop heap. The amount of desktop heap memory available to these sessions is known as the Interactive Desktop Heap.

    Services run under a different session and have their own "desktop", even though you can't see it. Each service can have its own desktop, and therefore its own desktop heap. But there are many services on your system, so in order to limit the memory usage, Windows defaults the desktop heap size to a much lower value in this case. The amount of desktop heap memory available to these sessions is known as the Non-Interactive Desktop Heap.

    Now, BarTender always uses desktop heap memory (every application that shows a user interface does). The interactive desktop heap is a number large enough to let you open thousands of windows, so we rarely see desktop heap as a problem in interactive sessions. But when running as a service, we can max out the default non-interactive desktop heap.

    Symptoms
    This can be difficult to diagnose. A common symptom is that when loading another format, BarTender may log an error like "Failed to create empty label format." However, this message is not guaranteed, sometimes BarTender will crash instead. It can also potentially print incorrectly, with missing fields. Depending on the credentials the service is running under, it may also be sharing a desktop heap with other services, and cause those services to malfunction in unpredictable ways.

    If you are running BarTender under a service context, and you are encountering any type of reliability problem which does not occur when running BarTender either interactively or when running Commander as an application, this is a possible cause.

    Solution
    You can adjust the heap settings in the registry. However, the settings are embedded within a larger configuration string, and making a mistake is potentially dangerous. Therefore, we've created a tool to make this easier:

    DesktopHeapControl.exe
    ftp://ftp.seagullscientific.com/TechSupport/Resources/DesktopHeapControl.exe

    You will need to reboot for the setting to take effect (restarting the service is not enough).

    I suggest you start with a value of 1024 KB increasing to 2048 KB if you still see the problem. Don't get carried away with too high a value as that could cause system instability.

    In BarTender v9.40 SR2 onwards we made changes to limit the problems caused by this issue; BarTender v10 improved upon this yet further.
    0

登入寫評論。