As a software consultant of 45 years, who's worked in hundreds of different environments with written thousands of programs over the years, I have NEVER seen a software problem this peculiar before. It's as if the guys who wrote this thing were primarily concerned about saving system resources while the console appears to be unattended.
This an undeniable problem with Inventor, which, frankly, makes me question its suitability for any task not involving a person sitting in front of it while it works. This behavior is highly reproducible, having been demonstrated here on multiple workstations running two completely different application developed by different programming teams over the course of the last three years.
There is no question that the behavior exists: Set up a long-running automated process which generates a new part file, generates hundreds of elements within it, moves onto the drawing stage, and creates your final result all without human interaction. About a half hour into the process, Inventor slows to a halt, and then stops completely.
You can clearly observe this behavior by generating timestamped logs of program activity, and also by simply opening the Task Manager, and observing that Inventor's share of CPU has dropped to zero, even though it is in the middle of the process. It may have been sitting there literally overnight, after falling asleep at any random point in the program. All you need to do wake it up is move the mouse pointer around the screen WITHOUT EVEN CLICKING ANYTHING and Inventor suddenly pops back into action.
It's like the boss just walked into the room.
One thing that does seem to help a bit is keeping the Task Manager open. This seems to fool Inventor into thinking someone is watching.
The problem seems even worse, however, on machines without a physical monitor or keyboard, which are strictly accessed via Remote Desktop. I'm thinking the next step is to write a routine which somehow simulates a user performing random mouse activity of no purpose other than to keep Inventor awake.
A related problem is the fact that Inventor has no garbage collection. This results in long running processes eventually consuming all available memory. This behavior is easily reproducible as well. Simply run your code which does all sorts of things for an hour or so on an automatic basis, and then have it automatically close out all documents, including the invisible ones. The result will be a copy of Inventor which has consumed most of the memory on the workstation and yet has absolutely nothing open.
This behavior is so bad it's become necessary to incorporate checkpoint processing into the application, which writes out all current state information, then launches a second instance of Inventor which picks up processing from that checkpoint, while the first instance then performs an Application.Quit to release that memory. This byzantine architecture is the only we we've found so far to keep Inventor working in a fully automated manner for more than a few minutes.
We'll just skip over the fact that Inventor does not use multiple processor cores. You can get the most powerful workstation there is, with the fastest disk, and the most memory, but Inventor just plods along like some relic from the 1980s using a single core.
So there you have it: Inventor is fundamentally flawed on so many levels when your goal is fully automated engineering:
* A truly bizarre user interface model which appears to have the goal of saving processor time for OTHER applications
* No garbage collection
* Single-core processing
We have a comparable automated engineering process which runs in AutoCAD, and there is NOTHING remotely like this behavior. AutoCAD start working, stays on working at full speed, releases memory when it's done and moves on the next task, working all night long if the queue is that long.
We have spent decades here developing long-running automated engineering routines with the sole purpose of saving valuable personnel time. The irony is that the peculiar design of Inventor seems to make that impossible. Inventor appears incapable of execution without constant human interaction: essentially making it pointless as a labor saving device.
