Community
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.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Visual Studio Code debugging activation

9 REPLIES 9
Reply
Message 1 of 10
dinocoglitore
2787 Views, 9 Replies

Visual Studio Code debugging activation

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

9 REPLIES 9
Message 2 of 10
kandennti
in reply to: dinocoglitore

During script development, browser tabs were always opened with more than 10 API HELPs.
Development is much easier because the variable window has higher performance than spyder.

 

I installed Pyrigh because the static type check was weak with just the ms-python extension.

https://github.com/Microsoft/pyright 

Message 3 of 10
dinocoglitore
in reply to: kandennti

I'm glad you enjoyed my long post (maybe a little too long). I guess you've already solved the problem I'm talking about in the post. It is not dedicated to those who already know but to those who wander in the dark. Thanks for Pyright's suggestion I will add it to VC extensions.

Many thanks

Dino

Message 4 of 10

Wow this worked.  I'd spent half a day on it and was not even close to figuring it out.

 

I can confirm that it will work with the following:

  • Fusion last update of October 2019

  • Visual Studio Code October 2019

  • Python extension for Visual Studio Code: 2019.9.34911

  • Python 3.7.3 64 bit (win 10)

Which is good because I haven't yet figured out how to revert the version of Visual Studio Code.  The only thing that seems to matter is the old version of the Python Extension.

Message 5 of 10

@KennethOfLeesburg  Thank you very much for your confirmation.  your answer makes me understand that it was not entirely useless to repeat something that had already been discussed in the forum. 

Thanks

Dino

 

Message 6 of 10
kandennti
in reply to: dinocoglitore

I have tried and felt about the '.vscode' folder before, including launch.json.


・'.vscode' folder is created when editing or debugging a script or add-in.


・The launch.json port is the setting value of 'API'-'Debugging Port' in the Preferences.
10.png


・I think that 'launch.json' and 'settings.json' have been copied from this folder. (Win)

C:\Users\[UserName]\AppData\Roaming\Autodesk\Autodesk Fusion 360\API\Python\vscode


If you need to modify 'launch.json', you will probably need to modify this file.
(I don't need it ...)

 


I think 'launch.json' and 'settings.json' will be copied every time to support the update.
(python.pythonPath)

Message 7 of 10
dinocoglitore
in reply to: kandennti

 

hi @kandennti,

thank you very much for the warning. I found the directory you are talking about and files contained in vscode. Currently I also don't need to change launch.json but I don't know if at some point it will be necessary.

Thanks

Dino

 

Message 8 of 10
Anonymous
in reply to: dinocoglitore

Hi @dinocoglitore , you summarized what I just went through a few days ago. Same lessons learned the same hard way. But there are still some issues that maybe you could help me with. Every time I launch a debug session, VSCode starts up seemingly good but I don't see expected behavior and then as I stop debugging fusion freezes. Let me give a little background information, step by step.

 

I want to edit a sculpted body programatically. That's where it all started. So I created a test body in the sculpting environment:

Screen Shot 2020-01-16 at 8.19.16 PM.png and downloaded @kandennti 's add-in: TSplineBodyDoorway. As an aside, @kandennti, let me ask whether I installed your add-in correctly. This is how it looks in the file system:

Screen Shot 2020-01-16 at 8.01.45 PM.png Please tell me if this is correct. I think so, because it shows up where it is supposed to:

Screen Shot 2020-01-16 at 8.24.13 PM.png under TOOLS -> UTILITY, but when I want to use it (TSpline Body Export ->Body 1 -> select destination folder -> Open),  Screen Shot 2020-01-16 at 8.31.25 PM.png it gives me this error: Screen Shot 2020-01-16 at 8.32.30 PM.png .

 

But this is not even my main problem. The main problem is that when I want to run a debug session, VS Code is launched automatically but the "StepOver", "StepInto", "StepOut" buttons are grayed out, even though if I click on "Python:Attach" it says that it is already running. So, I can't reach any breakpoints and debug normally:

Screen Shot 2020-01-16 at 9.05.36 PM.png      Screen Shot 2020-01-16 at 9.07.41 PM.png

Plus, if I hit ⇧F5 or simply stop VSCode, Fusion gives me the spinning wheel of death Screen Shot 2020-01-16 at 9.15.56 PM.png and goes comatose. I have to go to the Activity Monitor and force quit.

 

Any pointers? On Mac running Catalina.

Thanks in advance

Shanyi

Message 9 of 10
kandennti
in reply to: Anonymous

Hi @Anonymous . Thank you for downloading.

 

The settings for the add-in are then correct.

I can not reproduce because there is no environment to try MAC.


The error is issued when this return value is false.

https://help.autodesk.com/view/fusion360/ENU/?guid=GUID-301CA846-2F42-4556-9071-88B0C1FEA1CA 

 

This add-in was created using this "Fusion360AddinSkeleton".
https://github.com/tapnair/Fusion360AddinSkeleton 

 

Is it the same if I set this part of the "TSplineBodyDoorway.py" file to True?

1.png

 

 

Restart debugging with VSCode while ui.messageBox is displayed on the GUI side will make debugging impossible.
The only way to recover is to restart Fusion360.
However, it was the same for spyder.

Message 10 of 10
kandennti
in reply to: Anonymous

@Anonymous .

 

Remembered that the file path delimiter was not compatible with Mac, and fixed it.

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

Post to forums  

Autodesk Design & Make Report