Skip to main content
M
Matteo_198716-Pearl
16-Pearl
March 1, 2022
Solved

Distributed Batch 8.0.2.0 Export a multi-sheet .drw file into a single dwg file

  • March 1, 2022
  • 1 reply
  • 3246 views

Hello everybody,

Is it possible to export a multi-sheet .drw file into a single dwg file using the Distributed Batch?

Now, selecting the dwg_2d_export export .ttd file, a file is created for each sheet.

 

Matteo.

Best answer by sacquarone

Hello @Matteo_1987 

 

I pursued investigations in this direction, but I'm afraid to not be able to help you in the context of Distributed Batch on this buisness need for the following reasons.

 

When starting from q drawing with multiple sheets:

  • When using dxf_2d_export.ttdor dwg_2d_export.ttd in Distributed Batch, multiple files are produced (one per each sheet, and no config option or format enum entries in ttd files can be configured to avoid this)
  • Save as DXF or DWG in Interactive sessions produce one single file with multiple sheets (aligned with what you're expecting)
    • A mapkey can be recorder performing >File >Save as >DWG (or DXF), and, if name is NOT specified after "Save as" (just pressing OK with default name, before stopping to record the mapkey), then system is working as expected when mapkey is launched from other drawings (generating <drw_name>.dxg or dxf unique files per each drw - even if drw has multiple sheets - and <drw_name> being different in each drawing, the dwf/dwg files are not rewritten, still aligned with what you want)
    • However, if configured in mapkey.ttd to be launched with Distributed Batch:
      1. Outcome says Complete in Distributed Batch UI (leading in assumption that expected DXF/DWG unique files were creted)
      2. BUT DXF/DWG FIles are NOT generated on disk

Searching in this direction, I identified (and rememberd, because already faced it in the past) about the limitation documented in article 207715

  • This limitation prevents Distributed Btach to produce external objects (not defined in Input "Objects" field of the task).
  • In other words, calling mapkey in Disrtibuted Batch is:
    • Useful when intent is to modify existing objects affected by DBatch task, like in examples documented in article 109444
    • But useless when intent is to produce objects not defined as "Input Objects" in the task (like export actions being matter of interest in this post)

Due to above limitation in the context of mapkey execution via DBatch, I'm afraid to not be able to provide additional guidance in Distributed Batch direction. Quicker way to produce what you would like is probably therefore to:

  1. Register a mapkey, similar to the one shown below
  2. Export dwg files from interactive session by retrieving drawings and running mapkey (manual action for each drawing)
  3. Alternatively, a trail file could be produced doing aboe steps, and then reworked on disk (in a text editor) by copying/pasting lines dedicated to the Open and Export process, and change name of objects to open in the reworked trail file
Example of Mapkey:

mapkey dwg_export @MAPKEY_LABELdwg_export;~ Close `main_dlg_cur` `appl_casc`;\
mapkey(continued) ~ Command `ProCmdModelSaveAs` ;~ Open `file_saveas` `type_option`;\
mapkey(continued) ~ Close `file_saveas` `type_option`;\
mapkey(continued) ~ Select `file_saveas` `type_option` 1 `db_560`;\
mapkey(continued) ~ Activate `file_saveas` `OK`;~ Activate `export_2d_dlg` `OK_Button`;

 

I'm sorry to not be able to help you more efficiently on this request,

 

Regards,

 

Serge

1 reply

M
MartinHanak24-Ruby III
24-Ruby III
March 1, 2022

Hi,

please ask PTC Support.

M
Matteo_198716-PearlAuthor
16-Pearl
March 8, 2022

Are you telling me to open a call? 

Ty,

Matteo.

S
sacquarone21-Topaz I
21-Topaz I
March 9, 2022

Hello @Matteo_1987 

 

Yes. This was what @MartinHanak suggested. No need anyway, as I give PTC Technical Support's answer here in this post.

 

What you're facing is a current limitation. When driving presence of parameters with pre-defined values coming from tables in restricted parameter files, according to guidance documented in article 66567, the names and values of parameters are walwyas read dynamically in the file where restricted_val_definition config.pro option points to.

 

In other words:

  • If system CAN access this file:
    • it's possible to create and modify parameters , based on the row selected in the table
    • Possible then for new and legacy objects
  • If system CANNOT access this file:
    • In new objects, the tables are not available when creating parameters (which makes sense obvioulsy)
    • in legacy objects where parameter driven by table were existing:
      1. The existing definition (which was produced when table was accessible) is persisted
      2. But it's not possible to access the table, because system does not find it anymore (tables are not supposed to be stored in parts, they are supposed to be always accessed dynamically on disk, where restricted_val_definition config.pro option points to).

         

This is illustrated in little movie below.

 

Based on above considretaion:

  • This use case is NOT eligible to be reported to our R&D as a SPR, because system works as expected technically in this use case
  • But we nevertheless understand what you have behind in mind (sharing objects with partners who do not have access to the restricted parametr definition file for example), and makes sense therefore to be reported as a new Idea in our PTC Community (for eventual considreation later by our Product Managers when building sepcs of our future versions)

 

Regards,

 

Serge

 

(view in My Videos)

Terms & ConditionsAccessibility statement