cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X

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

Matteo_1987
15-Moonstone

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

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.

1 ACCEPTED SOLUTION

Accepted Solutions

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

View solution in original post

7 REPLIES 7

Hi,

please ask PTC Support.


Martin Hanák

Are you telling me to open a call? 

Ty,

Matteo.

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

 

Hi,

I think your answer belongs to different discussion.


Martin Hanák

Hi,

YES I do.


Martin Hanák

Hello @MartinHanak 

 

Oh yes ... Sorry for that. I posted my reply in the proper discussion now in parallel.

 

Sorry also @Matteo_1987 for this confusion

 

I was looking at your post also in parallel of the other one, and did a mistake when replying. Hence the confusion in my eralier post in this context...

I will try to provide further guidance, but for now, all what I can already say it's that, when exporting Drawings with multiple sheets in DWG Format:

  • It's expected to produce multiple DWG files when using dwg_2d_export.ttd Task in PTC Distributed Batch
  • it's expected (even though not aligned with above) to produce one unique DWG file when performing >File >Save as (or Export) from an interactive session of Creo Parametric

 

My axis of investigation:

  1. create a mapkey exporting dwg in Creo
  2. use mapkey.ttd task (instead of dwg_2d_export.ttd one) calling this mapkey in PTC Distributed Batch

Possible caveat => The name of file which will be registered in the mapkey ... Not tested yet

 

Not sure yet therefore if this will help, and unfortunately no time to test this right now,  but I'll try to find some later today or tomorrow, and will share then further views later.

 

Regards,

 

Serge

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

Top Tags