Possible to Create a Fusion Model in Node.js

[codefoster]

I realize that I can write JavaScript that I can execute within Fusion 360 that affects the environment and the model, but I'm wondering if it's possible to write a Node.js app that essentially bootstraps the Fusion 360 engine without the user explicitly launching Fusion 360 first.

Of course F360 is going to have to be installed on the machine, but I'm just wondering if it's possible to spin up the Fusion 360 process from Node.js and then start interacting with the model from there making it a programmatic process from end to end.

[KrisKaplan · Accepted solution]

There isn't currently a 'server mode' client for Fusion, or any bootstrap launcher API.  But in Node.js you could search for an installed Fusion and run the Fusion360 app on your own.  On Windows, this is normally in %localappdata%/Autodesk/webdeploy/production/HASH (the hash folder with the latest creation date, or the subfolder that contains the Fusion360.exe with the latest date).

The next issue is that Fusion doesn't currently expose an interprocess API to be able to call the Fusion API remotely from your Node.js process.  But you could provide something yourself by creating a 'run on startup' addin script that will run when Fusion is started that will open an interprocess communication channel (e.g. a websocket on a local port, named pipe, etc...) and wait for commands from your Node.js application and forward them to the appropriate Fusion APIs.

Kris

[codefoster]

Thanks, Kris. That makes sense.

[benRUVCJ]

@KrisKaplan

Is there any update on this?

We are trying to fire up Fusion Engine from within a process using Python (or C++) and trying to bypass launching the Fusion App. For any automated environment this functionality is essential.

Basically, we just want to talk to the engine directly through the API.

If none of this is yet available:

1. Do you have plans to open up the engine so that an external process can directly hook into the engine?

2. When launching Fusion360.exe the GUI opens. How can we just start the engine without the GUI?

3. In case of Python or C++, are you in possession of a "run on startup" addin code snippet?

[KrisKaplan]

Unfortunately, no.  The situation has not changed.  Fusion360 is not yet available as a public service for applications, but only as a UI application.  I am not aware of any immediate plans to provide this.  But Fusion360 data is becoming available as part of FORGE platform APIs.  This is starting out as fairly high level, and access to geometric design data is not yet exposed, but I would expect finer grained design services to be added in the future, but I do not have any timeline for something like that.

Kris

[tyler.brownBUNQN]

Kris,

I have attempted doing something to what you suggested by opening up a port using a startup script, which works mostly. The problem that I am encountering is any call to something that causes the UI to render a component causes Fusion360 to lock up and crash.

I have tried 2 methods:
1. Keep the startup script addin running by not returning from the run method. This keeps the socket open and UI interactions works, but Fusion360 does not like this and crashes after a minute or so. (Tried also adding a progressDialog to keep the UI from freezing, that actually made it worse).

2. Using threads and adsk.autoTerminate(False) I can keep Fusion360 running and open up the socket in a new thread. Using this method I can proxy calls to Fusion and get information out and do non-interface things. As soon as I do a simple ui.messageBox, it crashes Fusion360.

I'm using python for the script language, and have tried using a simple http server and sockets to do this, both come out with the same results.

Thoughts on this? I can post snippets or get crash logs if needed.

[KrisKaplan]

Yes.  As you have noticed all user interface interactions must be done from the main thread.  (The API layer should be better at blocking the thread and sending the call to the main thread for handling, or at least error-ing out with a meaningful error from calls that require calling on the main thread.)

The correct way would be to have your socket code running on a thread, but marshal the API calls (at least those that require it) to the main thread.  The problem is in how to get the calls back to the main thread, because your code is not running an event loop on the main thread, the Fusion application is.  For Python, this is a bit of a problem, as there's no really good way (that I'm aware of) to do this.

From a C++ application, you could use native platform APIs to post a message to the main loop, and the Fusion main event loop should dispatch the message (for example, on Windows, you could post a custom windows message and the Fusion event loop will dispatch that message back to your code).

We have discussed, but it is not yet available, adding an API to our API that would allow an addin to send itself events on the main thread, to make a multi-threading application more convenient (for Python code, or for C++ code to do it conveniently and in a platform neutral way).

A less attractive ('poor mans') option would be to have your addin spin in a while loop in your run function, calling adsk.doEvents to pump the main event loop.  (This might be what you were doing for your option 1.)  This would not be a good general solution, and I would expect it to cause problems with Fusion eventually (which may be the problems you mentioned with option 1) because you never allow Fusion to return to the main event loop.  Several critical operations/tasks/idle tasks/etc... are performed when the main event loop is returned to, and spinning in a long term doEvents loop bypasses this.

Another option could be to use a JavaScript addin to do this.  The JavaScript code will always run on its own thread and the API calls are always marshalled to Fusion's main thread.  But the big problem here is the limited access to the operating system (for example, to open a port).  But you could access a local server to make rest calls, or connect to your external node process through a web socket.

Kris

[tyler.brownBUNQN]

Thanks Kris,

You confirmed what I thought about the threads and the main event loop. Not allowing Fusion to return from the main thread (option 1) does cause Fusion to crash eventually.

I'll try to make some headway with cross thread communication in python to see if there is a viable option, if not it seems like JS and C++ both have options to use. I'm fairly familiar with websockets and libs like socket.io that could make this work.

Thanks again for the information!

[hansmbakker]

Hi,

I created a feature request for external interaction with Fusion 360 at http://forums.autodesk.com/t5/ideastation-request-a-feature-or/allow-external-calls-to-your-api-from....

Please have a look and vote there for a chance for this to be picked up by the Fusion360 developers! 🙂

[XanderLuciano]

Any add-in can be run at startup with this checkbox here:

And I did exactly what Kris was talking about for my socket script, though it's still extremely beta.

[cdorrat]

How did you manage to open a socket?

I got "cant find variable" errors for both XMLHttpRequest and WebSockets.

[xander.luciano]

I can't find the original file anymore, but I believe I used python's sockets.