We import STEP files created in Solidworks, and it is important that the object name used in Solidworks comes through to Rhino. In V4, you could explode the nested block instances, and the object name would stick. In V5 that doesn’t happen anymore. I’ve posted about this for years, but it doesn’t look like anyone is going to change it anytime soon. So I wrote a script in Rhinoscript that took the block instance name and applied it to the exploded block instance, so that the polysurface would be named correctly. Works well.
Fast forward to 2014, and I have re-written this script in Python. Now, if I import what I consider a medium size STEP file (say 50Mb) using Python, Rhino hangs for 4 or 5 minutes. When it finally wakes up, the operation is completed successfully. Try it with an 80Mb STEP file and it hangs for over 10 minutes. It appears to have locked up, but if you wait long enough it succeeds.
Here is what has me stumped. If I import a STEP file using Rhino’s traditional import command, then run a “stand-alone” version of the script, it doesn’t hang. If I go back and import the file using Python, which includes the exact same code as the “stand-alone” version, it hangs again.
I can’t post the STEP file publicly, but if anyone at McNeel is interested in testing this, I can supply the scripts and the STEP file for analysis.
Thanks for trying to get some attention to this topic. I believe I corresponded with @chuck about the ExplodeBlock command back in the beta days of V5. I felt (and still do) that the naming of the exploded objects was broken. In V4 a named Solidworks object would maintain the name when the block instance was exploded. In V5, the object is named after an operation used to create that object. For example, in V4 if an object in Solidworks was named “Detail 1”, then in Rhino it would also be named “Detail 1” after the imported (through STEP) block instance was exploded. In V5, that object named “Detail 1” in Solidworks will be named something like “fillet” or “hole”. I don’t understand how that is useful to anybody.
Anyway, back to the present…
Let me attack this issue from a different angle. In my script, as I mentioned, Rhino will hang if I import the STEP file then run the ExplodeBlockInstance Python method within the same script. If I take that exact script, and remove the import functionality, the script doesn’t hang. So there is some direct connection between importing the file and exploding it that Rhino doesn’t like. Separate the operations and it is fine. In fact, I can run a scripted STEP import function directly ripped out of my main script and then run the Explode functionality pulled from the same main script, and if I run them one after the other it doesn’t hang.
So… The next logical step seems to be to keep them separate, then just call the second script up from within the first one, after the import is complete. Nope. It hangs again.
So here is my question: Short of just going back to the Rhinoscript version which doesn’t hang Rhino, what can I do to make this work correctly using the Python version? Is there a way to “flush” the memory, or whatever, to emulate two separate operations from within the one script?