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.
Solved! Go to Solution.
Solved by KrisKaplan. Go to 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
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?
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
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
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.
How did you manage to open a socket?
I got "cant find variable" errors for both XMLHttpRequest and WebSockets.
I can't find the original file anymore, but I believe I used python's sockets.