Why can't PO work in background

Some times PO takes quite long to plot.

It starts new separate ustn-sessions - so why can't it work in the background.

I'll be fine with the files being locked while PO is using them.

Parents
  • Short answer: the part of Print Organizer that runs in the interactive process, responsible for iterating over the print definitions and starting and stopping the worker process as necessary to support different workspaces and other needs, requires an exclusive lock on resources that other parts of MicroStation would need access to were Print Organizer to hide its window and return control to the user.

    Background operation could be implemented, and would certainly be an improvement.  But it would not be a trivial task.

          
    .

  • Thanks for answer. For me it would some times speed things up.

    Some thoughts around this:

    Is it the same with Batch Converter?

    I use ABD, which can be started in different flavors. What will happen if I normally use Architecture-ABD, but use Microstation-ABD in a parallel session for PO or BP?

    regards / Thomas Voghera

  • Since Batch Convert loads its files into the interactive process, like the old Batch Print did, it's in a much more difficult position with regard to background processing.  Adding that behavior to Print Organizer is within the realm of possibility -- with Batch Convert as it exists today, much less so.

    I can't speak for ABD, whether it supports parallel sessions or not, but I assume it does.  I wouldn't expect there to be any explicit reason against running two sessions at once, with one session driving Print Organizer.  By default, Print Organizer opens files for read-only access.  If you change that setting, then you would need to be careful about which files were open for editing.  Print Organizer silently falls back to read-only access if it's asked to open a file for read/write but cannot do so, which can lead to problems with workflows that depend on automatically updating local styles from dgnlibs upon file load.  You would need two ABD sessions, though -- not ABD and MS.  ABD supplies its own symbology rules that MicroStation doesn't know anything about.  In order to get the correct printed output, Print Organizer needs to be running inside ABD.  The biggest concern with that, assuming it's supported, would be memory usage.  ABD is a big product.  Running three instances at once (counting Print Organizer's worker process) might place an undue burden on the machine.

          
    .

  • Thanks again for elaborate answer.

    1- ABD can be started in several flavors. Architectural, Structural etc., but also in a 'microstation'-mode still possible to open and read, but not edit, ABD-elements with resymbolization from correct workspace etc. Ment for drafting and a lot quicker than a full ABD session.

    And my thought was to use that for running PO. But I'll take the discussion over to the ABD-forum for that. From a PO point of view it seems not to be a problem though.

    2- Regarding PO - it starts two! ustn/ABD sessions ? One 'worker' process, and another. Well, we'll see if it is to heavy for the machine.

    regards / Thomas Voghera

Reply
  • Thanks again for elaborate answer.

    1- ABD can be started in several flavors. Architectural, Structural etc., but also in a 'microstation'-mode still possible to open and read, but not edit, ABD-elements with resymbolization from correct workspace etc. Ment for drafting and a lot quicker than a full ABD session.

    And my thought was to use that for running PO. But I'll take the discussion over to the ABD-forum for that. From a PO point of view it seems not to be a problem though.

    2- Regarding PO - it starts two! ustn/ABD sessions ? One 'worker' process, and another. Well, we'll see if it is to heavy for the machine.

    regards / Thomas Voghera

Children