Skip to main content
9-Granite
June 10, 2026
Solved

Performance issues when opening DRW files through Creoson/Creopyson

  • June 10, 2026
  • 2 replies
  • 111 views

Hello everyone,

 

First of all, I would like to express my sincere thanks to the authors of Creoson and Creopyson for their work and for everything these tools make possible.

 

We have developed a Python application to automate the export of DRW drawings into various output formats while applying specific file naming conventions.

However, we are experiencing significant delays when our application requests Creo to access DRW files. For example, opening a relatively small drawing can sometimes take several minutes. We do not observe these delays when opening the same file directly in Creo.

For reference, Creoson, our Python application, and all Creo files are hosted on an internal company server.

 

We are trying to determine the source of these delays. Could they be caused by our Python application, Creoson, Creo itself, or the server/network infrastructure?

Is there a way to monitor the communication between Creoson and Creo, enable detailed logging, or use another troubleshooting method to identify the root cause of the issue?

 

Any advice or recommendations would be greatly appreciated.

Kind regards.

 

Environment:

  • Creo 9.0.11.0
  • Creoson 3.0.1
  • Creopyson 0.7.8
  • Python 3.13.9
Best answer by DavidBigelow

Very cool.  Great use case.

 

There are a lot of variables in your post that could be causing some delays.

 

The location of your content (on a shared network drive vs locally) could be a contributing factor in delay vs local access.  But I don’t think this the issue based on your manual test vs programatic tests.

 

I would add logging to your program and run like 3-4 drawings.  Logging specifically meaning write/append a timestamp and operation for each critical step and within some looping operations, to a local file so you can trace the time of execution.

 

The log data you create will help visualize what your code is actually doing, in what order, and a simple diff between event times can help identify long operations quickly.  Then it would be easier to profile the structure and execution of the program (e.g. resetting connections each file, network search / load of content, Creo search paths, transactions with Creo, etc.) -- you might discover there is a loop, or nested loop, in your code that is running multiple times compounding delays or queries to Creo in some way or writing multiple versions of your exports over and over and over - or it could be you are overloading Creo and it is queuing your requests for execution and hanging things up.   But the point is to write log data out from your program to a console or log file so you can trace out the event times and understand the sequences to help find the pain.

 

One thing that would also help is to copy your files locally, set your working directory to where the content is locally, and try to run a simplified version of your code to head-check performance.

 

Another thing to consider is how you are performing the operation (native command or mapkey) to do the export?  If Mapkey, was it created for the version you have, and is it only the body of the Mapkey being executed?  Just throwing that out here for some consideration as you have not shared any code.   If you are dealing with a handful of files to batch through, you might be able to just load them all into Creo session, and export by looping through the files in session - but a better practice would be to get the list of files in the working directory, then erase memory, load the first drawing, export, erase memory, load next drawing, export… continue until the end as a loop.

 

So - it is likely either network / search path / or the code itself is looping incorrectly and/or overloading Creo with instructions (mapkeys stepping on mapkeys possibly).

 

When we run these types of jobs - it is super fast -- even when we are using mapkeys.   The only issues we have seen is timing issues with extremely large files or long export times where we need to add a small delay to allow Creo to finish before the next command/cycle (rare).

 

Hope this helps!

 

Dave

 

 

 

 

 

2 replies

18-Opal
June 12, 2026

Very cool.  Great use case.

 

There are a lot of variables in your post that could be causing some delays.

 

The location of your content (on a shared network drive vs locally) could be a contributing factor in delay vs local access.  But I don’t think this the issue based on your manual test vs programatic tests.

 

I would add logging to your program and run like 3-4 drawings.  Logging specifically meaning write/append a timestamp and operation for each critical step and within some looping operations, to a local file so you can trace the time of execution.

 

The log data you create will help visualize what your code is actually doing, in what order, and a simple diff between event times can help identify long operations quickly.  Then it would be easier to profile the structure and execution of the program (e.g. resetting connections each file, network search / load of content, Creo search paths, transactions with Creo, etc.) -- you might discover there is a loop, or nested loop, in your code that is running multiple times compounding delays or queries to Creo in some way or writing multiple versions of your exports over and over and over - or it could be you are overloading Creo and it is queuing your requests for execution and hanging things up.   But the point is to write log data out from your program to a console or log file so you can trace out the event times and understand the sequences to help find the pain.

 

One thing that would also help is to copy your files locally, set your working directory to where the content is locally, and try to run a simplified version of your code to head-check performance.

 

Another thing to consider is how you are performing the operation (native command or mapkey) to do the export?  If Mapkey, was it created for the version you have, and is it only the body of the Mapkey being executed?  Just throwing that out here for some consideration as you have not shared any code.   If you are dealing with a handful of files to batch through, you might be able to just load them all into Creo session, and export by looping through the files in session - but a better practice would be to get the list of files in the working directory, then erase memory, load the first drawing, export, erase memory, load next drawing, export… continue until the end as a loop.

 

So - it is likely either network / search path / or the code itself is looping incorrectly and/or overloading Creo with instructions (mapkeys stepping on mapkeys possibly).

 

When we run these types of jobs - it is super fast -- even when we are using mapkeys.   The only issues we have seen is timing issues with extremely large files or long export times where we need to add a small delay to allow Creo to finish before the next command/cycle (rare).

 

Hope this helps!

 

Dave

 

 

 

 

 

Steelfoot9-GraniteAuthor
9-Granite
June 17, 2026

Hello Dave,

Thank you for your feedback. I didn't have a chance to reply earlier.

We recently had the opportunity to run the program again internally and observed somewhat different behavior. In some cases, we encounter errors indicating that CreoPyson had been disconnected or that some files occasionally become inaccessible on the network. In other cases, the program ran perfectly without any issues.

As you suspected, the program relies on mapkeys for functions that are not natively accessible through the API.

The parts and drawings are opened sequentially in Creo to retrieve parameters, but they are not cleared from memory as the process progresses. Therefore, there is indeed a possibility that memory usage is gradually increasing and contributing to the issue.


As a non-software developer, I also suspect that there is significant room for improvement in my program itself, particularly when it comes to minimizing network access and reducing the number of requests sent to Creo.

 

I am going to investigate the program's execution following your recommendations and try to better identify the root cause of the problem.

If permitted, I can send you the program via private message for review. I'm not very familiar with the rules regarding open-source licensing and code sharing. The program is fairly large and is written in French. However, I can quickly translate the user interface into English if needed.

Thank you for your help and suggestions.

Best regards,

Steelfoot

 

18-Opal
June 17, 2026

I am not a python guy - so I would not provide “expert advice” on the code - but the structure and flow should be obvious.

 

Here is a pro tip I could not recommend 2 years ago (because the tech was just not there)

 

If you have a calude.ai account (you can even just sign up and use the FREE version for a bit)…. do this.

 

Start a new chat (assuming you have a pretty light script/file(s) for this).

  1. Provide Context to Claude AI - Upload your python program/script file into a chat and provide some context for that file… something like “This is an Automation Application/Script for Creo Parametric that uses CREOPYSON (https://creopyson.readthedocs.io/en/latest/modules.html). The script does this, that, this, that with the objective(s) of X, Y, Z...” - At the end of that overview ask it to review the code provided and explain the code back to you (this helps ensure that you understand that it understands the scope and code). Chat with Claude to refine anything it is not picking up on or needs refinement in understanding of your objectives. Once you have confirmed it is locked into the scope of what you are trying to do (you objectives)… then….
  2. Explain the problems you are having / want to solve - ask it to identify where those problems are likely occurring in the code and propose fixes. (note: we are in a narrow space of knowledge relative to Creo Parametric and CREOPYSON - but fundamentally the coding should be easy for it to understand and provide some good guidance).
  3. Ask Claude AI to propose fixes to your code - Claude AI can fix specific thing in your code or re-write it if it is bad enough 😂 .. I would review the code with Claude AI for a bit in chat looking for obvious things (it can make mistakes) - but you should be able to quickly get to code you can copy/paste/download locally to run and try - you should also have claude include command line logging so you can watch the flow of the code as it runs - I suggest indentation on the log print statements for looped calls so you can see the structure of what the program is executing - this is super helpful to see the depth and overall structure of what is going on.
  4. IF you find problems - point them out to Claude AI in the chat - copy / paste errors for it to consider (logging is helpful for this) -- and you will be amazed at how fast this gets fixed. (not kidding - Claude AI is really good - suggest at Least Sonnet 4.x but Opus 4.8 is the best model for this kind of thing) 

 

That is how I would approach the fixes to this -- it will work - and you can add to your AI skills quickly.   You will be tempted to do more with AI - when you get to that point happy to provide some best approaches to bigger coding efforts with AI.

 

Hope this helps.

 

Dave