Fusion
Visual Studio Code debugging activation
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
I would like to share my experience regarding the possibility of debugging a script written in Python for Fusion 360 using Visual Studio Code. There is nothing of original in what I write and there is nothing new in this post but I hope that sharing my difficulties and my solution can help someone else.
I had to work hard before knowing that you don't have to make any somersaults to make things work. Although it required me not a little effort to understand.
For some time I have not written any code with Fusion API for personal reasons but now that I restart writing code I found a series of innovations in Fusion that have destabilized me a little: the new UI and above all the new Visual Studio Code editor.
A bit doubtful for the change (once I developed a significant amount of code with Spyder) I roll up my sleeves and started working on it.
Fusion helps in the change and the first thing was having to install Visual Code by downloading the latest version from the site. Delighted for the success of the fact I clashed with the first novelty: each python file (ie each script or rather each project) must be in a separate directory containing the .vscode subdirectory in addition to the file (or files) .py.
This makes me a bit uncomfortable given the amount of examples already written to verify the functioning of the API. I don't know if there is an automatic solution provided by Fusion or VC but it will be necessary to review the entire baggage of .py files to make them visible to VC in order to reactivate them and try again on Fusion.
At the beginning I was satisfied with the fact (as suggested by someone on the forum) that we should neglect the debug part of VC and use the editor for its fantastic code completion features. Launch the script ‘in the dark’ contenting only with any (a bit cryptic) Fusion errors. Unfortunately I started to regret the old Spyder with its debugger features.
But using an editor when you know it can do more is not very pleasant!
Continuing to follow the directions of the various posts, I came to the conclusion that it was necessary to install an extension for VC: Python extension for Visual Studio Code which has the function of adding what is needed to allow remote debugging via VC.
This step led me (like everyone, I guess) to debug from VC.
I naturally clashed against an inevitable error that also blocked other developers who wrote on the Forum: 'Failed to Attach (connect ECONNREFUSED 127.0.0.1:9000)'
This led to a long phase of research on the Forum and on Google to find an answer to the problem. A problem that took me two days of research.
A further investigation of Google and the Forum has led me to understand that VC can perform extremely powerful debugging that cannot be overlooked. Browsing left and right I read the material provided directly by Visual Code starting from the basics (https://code.visualstudio.com/docs/python/python-tutorial#_configure-and-run-the-debugger) and then going into more detail with debugging related pages (https://code.visualstudio.com/docs/editor/debugging).
Very useful reading but, I must say, all in all, a bit heavy!
These readings made me understand the structure of remote debugging and prompted me to do a series of tests on the ‘lauch.json’ file located in the .vscode subdirectory of the project that is used to configure the debug session. Here again great disappointment and frustration at the fact that despite the innumerable examples of configuration nobody (obviously) refers to Fusion. The test results were disappointing.
But these readings have brought me back to a Fusion API forum post that I have read countless times without ever actually understanding it (https://forums.autodesk.com/t5/fusion-360-api-and-scripts/api-debugger -doesn-t-work-after-oct-2019-update / td-p / 9074827). The post comes from a request of @lorraine5RWGT and @kdrector with the solution of @Anonymous. The invitation to those who had the same problems as me is to read it very carefully and calmly.
I can definitely say that you don't need to launch any import sys or import ptvcd on the Fusion console and not even ptvsd.enable_attach () or even less modify the contents of the python script (as suggested in some posts).
The problem of the lack of communication between the VC and Fusion debugger arises from a "simple" incompatibility between Fusion and the version of Python extension for Visual Studio Code (as highlighted rightly in the post of @Anonymous).
When installing the extension, the latest version available to date is automatically loaded into the VC, it is 2019-10-44104. We simply have to go back to the version about a month ago (2019.9.34911).
To do this you need to be absolutely certain that Fusion 360 is closed and not working. Only after switching to the 2019.9.34911 version in Visual Code and restarting Fusion can you be sure that what was discussed in Python Specific Issues (http://help.autodesk.com/view/fusion360/ENU/?guid = GUID-743C88FB-CA3F-44B0-B0B9-FCC3) is true.
In this document there is a very brief indication (actually not very explicit and without any graphic reference) to the extension of which we speak: '...... VS Code requires the optional ms-python.python extension ... .. '. And in any case there is no reference to the actually working version !!!
It remains to be verified and clarified whether, once the .py script has been opened on VC, the script can be launched directly from Visual Code.
In conclusion I would like to highlight the versions of the various software that I currently have the opportunity to verify:
Fusion last update of October 2019
Visual Studio Code September 2019
Python extension for Visual Studio Code: 2019.9.34911
Python 3.7.3 64 bit (win 10)
In addition I would like to share the content of lauch.json that I have absolutely not modified despite all the documentation of VC speaks about it extensively
{
"version": "0.2.0",
"configurations": [
{
"name": "Python: Attach",
"type": "python",
"request": "attach",
"localRoot": "${workspaceRoot}",
"remoteRoot": "${workspaceRoot}",
"port": 9000,
"host": "localhost"
}
]
}
Thanks to @Anonymous we can now proceed! Good job.
PS: I apologize for the English. I asked Google to help me!
Dino Coglitore
