Fusion API and Scripts
Got a new add-in to share? Need something specialized to be scripted? Ask questions or share what you’ve discovered with the community.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Python nostops working and occasionally starts working again

Message 1 of 2
212 Views, 1 Reply

Python nostops working and occasionally starts working again

I can edit my python script in Spyder, but nothing happens when I run it from the scripts menu or when I am in the Spyder IDE. Same is true for the debugger.  In a few cases, which I haven't been able to reproduce,  I am able to run the program from the script menu, but cannot debug the program from there. When I click any of the debugging buttons, the name of the command is printed in the console area of Spyder, but nothing happens. Clicking run does nothing as well.


I am not sure how or why, but killing python in the task manager and then quiting out of Fusion360 occasionally resolves the issue.


I am running the latest update of Fustion 360. version 2.0.1593. I am wondering if the recent update is causing this problem.



Message 2 of 2
in reply to: markusbarnes

The most common cause of the behavior you describe with a single script is if there is a runtime error in the script that is thrown out of the script's main module.  That would be script code (including init and module level code run by any import statements) at the module level or the 'run' function level outside of a try-catch block (with a handler that logs or displays an error message).  In this case, the script will silently fail when run.  However, the debugger will attach and run to the point of the runtime failure in the code.  But if this failure is on the first import statement, it would be easy to think the debugger isn't attached, because the next or continue will hit the error and the script and debug session will end.


Unfortunately, the Spyder IDE doesn't provide much feedback that the debug session has stopped (e.g. if your script ends normally or fails).  The debug command toolbar buttons are always enabled and selecting them just pumps the 'next', 'step', 'continue', etc... commands to the console, even if we aren't debugging.  So if your script stops and you use the debug commands, they will always just echo to the console.  I find the easiest way to avoid confusion is to wrap all functionality in the 'run' function in a try block, and set a breakpoint on a statement in the finally block.  (If debugging a command based script, then in the equivalent try/finally in the appropriate event handler functions.)  The other option would be to look at the script manager dialog to make sure that your script is still running.  Or you can issue the following statement to see if your module is still loaded "next(k for k in sys.modules.keys() if k.endswith('MyScript_py'))".  (You can use more of the script's (escaped) path if you want to handle cases where multiple scripts have the same name or same ending substring.)


But the behavior of a failing script would be limited to a specific script.  So if you tried to debug another (e.g. a sample) script everything would behave as normal.  In testing around, I was able to get into a state that sounds like the one you described, but only after forcing a syntax error in the script that is loaded, and attempting to debug that script.  This seems to trigger an interpreter failure in a way that does not properly end the debug session.  So any further attempts to run or debug any script from Spyder are ignored.


I will file a bug for this and we will look to get it fixed.  But in the meantime, it seems like I could resolve the problem either by simply restarting Fusion, or by manually resetting the debugger from the console.  To manually reset the debugger in the current Fusion session, you can use File-->View-->Show Text Commands to display the text command window, check the 'Py' radio button next to the command line, and issue the following statements:


    import sys


    del sys.monitor

    del sys.debugger

    sys.debugger_running = False


(If calling reset or deleting either of those values fails, that's OK, but it means the debugger was already properly stopped.)



Kris Kaplan

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th

Autodesk Design & Make Report