since a few months RSA 2024 is out. in our company we do have quite a few scripts that we rewrote from ironpython2 tot Cpython3 due to the switch from ‘dynamo studio’ to integrated dynamo.
Now we run in RSA 2022 with Dynamo 2.11. Works perfectly fine.
In RSA 2024 its the new 2.17 Dynamo.
and when we now start checking our scripts we have a problem with the load assignment.
This is what we get with 2022
import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *
from System import Environment
user = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
sys.path.append(user+r"\Dynamo\Dynamo Core\2.11\packages\Structural Analysis for Dynamo\bin\RSA\Interop.RobotOM.dll")
clr.AddReference('interop.RobotOM')
#clr.AddReference(user+r"\Dynamo\Dynamo Core\2.11\packages\Structural Analysis for Dynamo\bin\RSA\Interop.RobotOM.dll")
from RobotOM import *
from System import Object
objects = IN[0]
LoadCaseID = IN[1]
ILRT = IN[2]
LoadPX = IN[3]
LoadPY = IN[4]
LoadPZ = IN[5]
application = RobotApplicationClass()
project = application.Project
structure = project.Structure
labels = structure.Labels
loads = structure.Cases
CreatedLoads = []
case = structure.Cases.Get(LoadCaseID)
simplecase = IRobotSimpleCase(case)
rec = IRobotLoadRecordMngr(simplecase.Records)
count = rec.Count
for i in range(count+1)[::-1]:
rec.Delete(i)
for j in range(len(objects)):
#for k in range(len(objects[j])):
Uniform = []
Uniform.append(rec.New(ILRT))
LoadRecord = IRobotLoadRecord(rec.Get(Uniform[0]))
LoadRecord.SetValue(0,LoadPX)
LoadRecord.SetValue(1,LoadPY)
LoadRecord.SetValue(2,LoadPZ[j])
LoadRecord.Objects.FromText(' '.join(str(objects[j]) for el in objects))
#CreatedLoads.append(LoadRecord.UniqueId)
#LoadRecord.Objects.FromText(str(objects[j][k]))
application.Visible = True
application.Interactive = True
application.Project.ViewMngr.Refresh()
OUT = objects
And this is what we get with RSA2024 (same script no changes).
Hi @1234eddie
I wrote it in the quick start guide, and I suppose things didn’t change (I don’t use RSA anymore): you cannot use CPython with RSA! install the Ironpython package and run your python scripts with it.
Sol is on vacation and I don’t have Robot installed at the moment. I may have a project starting soon which would require it, so if that kicks off I will jump in if I can.
Hi. We haven’t changed API in that area. So, I checked “Loads” API in c# project (is easier to debugging) and there everything works fine. The problem is elsewhere, but I don’t know where. We will look at that.
Hi @1234eddie@c.poupin@jacob.small
I apologize for the late reply but we had vacation time. After few tests we know that problem occurs when CPython3 is used. If you install package with the older version of Python in the new Dynamo (and you adapt a litle your code) evrything will works fine. Evrything works with other lenguages (C++, C#) too. Test was made with two version of Dynamo and two vwerion of RSA and we see that only Python version is important.
This is not a problem with “LoadRecord”. We found a few RSA methods witch work inproperlly too and returns invalid object for CPython3, or object is invalid interpreted on CPython3 side.
In this moment we try to investigete behaviour of different Python version outside of Dynamo enviroment.
We have three potential sources of bug:
somthing in the Dynamo enviroment when CPython3 is used,
CPython3 (and other new versions of Pythons?) interpreter ,
different implementation of a few API method in RSA witch are invalid treated in new Python version.
That’s all we know now. I will let you know if we find anything.
Hi @sanzoghenzo
You write in the article Quickstart Guide for Dynamo in RSA 2023 that COM API doesn’t work in CPython3. Is this your experience with RSA API or you found that information about COM API somewhere? I see similar information here: Troubles with switching from IronPython2 to CPython3 but without explanation. I still can’t find the reason, we were sure that it should work (but we are not Python specialist). Especially that it works for many RSA COM objects.
Robot COM API are old, and Autodesk needs to provide a better, .NET API for things to work well with dynamo and python3
pythonnet, the Cpython3 engine used in dynamo, doesn’t support com api and probably never will
Dynamo developers made a huge mistake in pushing cpython as the default interpreter, especially for RSA, since everybody thinks it can be used flawlessly when it obviously it isn’t the case.
That being said, there’s a workaround to handle com objects described here but it’s tedious to use that class to wrap every single COM object.
Do yourself a favour and stick with IronPython 2 until Autodesk developers fix this nightmare…
The TLDR of this is that this simply isn’t something that Autodesk can fix. Python 2 (and therefore Iron Python 2) had to be removed from Dynamo for security reasons, as it is no longer supported and therefore unsecure. Python is owned by a separate entity. Autodesk could implement a different flavor which interacts with the .net environment (just like Iron Python 2 and Iron Python 3), it isn’t our area of expertise. Microsoft (who owns the .net environment, Component Object Model or COM, and the Common Language Runtime or CLR) was the driving force behind Iron Python for a half decade before abandoning the project. I can’t confirm it, but I suspect much of the reliability of Iron Python 2 is likely due to their involvement.
The good news in all of this is that while neither Dynamo nor Autodesk can fix Python implementation issues, we can provide options.
Iron Python 2 should you want to risk it, CPython 3, and Iron Python 3 are all available as engines for you to deploy in your work. Flexibility is good in general as we can ‘get stuff done’ and work to develop in a secure environment.
One last note on this, I suspect a lot will change with the conversion from .net 4.8 to a more modern .net implementation (6, 7 or 8) with the 2025 product line. While some existing code will break, I’m hopeful that more things will be fixed int he long term by that modernization effort.
PythonNet 2.5.x has bugs with the .Net environment and the arrival of .Net 6 may not help things if PythonNet 2.5.x is maintained (instead of PythonNet 3.x)
However, PythonNet 3.x has significant changes (break)
@gwizdzm
Many thanks for your reply.
so if there is a solution with the Cpython3 let me know.
Because it’s now holding us back on upgrading to newer RSA versions.
Robot COM API are old, and Autodesk needs to provide a better, .NET API for things to work well with dynamo and python3
Agreed. Also the API is a bit messy, incomplete and cumbersome. However, I can’t see it being fixed without rewriting extensive parts of RSA software. One may just as well start form scratch as Arup did with GSA.
pythonnet, the Cpython3 engine used in dynamo, doesn’t support com api and probably never will
PythonNet supports COM, I’ve used it with other software successfully (Excel for example works like a charm). For those who are not sure what COM is, check out the wikipedia page.
I suspect that the way Robot’s API is written is a bit substandard compared to a Microsoft bulletproof approach, hence the bugs we observe.
This is not to say PythonNet is perfect, but it’s been around for a while and is still being actively developed.
To be clear, PythonNet is a piece of software written in C# and Python that allows two things: embedding CPython in a .Net application (i.e. the software offers a Python console to interact with it as well as GUI buttons) and accessing a .Net library from Python (our case here). It’s not an “engine” and it can be used elsewhere than in Dynamo.
Dynamo developers made a huge mistake in pushing cpython as the default interpreter, especially for RSA, since everybody thinks it can be used flawlessly when it obviously it isn’t the case.
I would argue that choosing IronPython is the source of all evil, as Microsoft decided to dump this somewhat unsuccessful project. McNeel’s Rhino has the same headaches trying to revert back from that decision. IronPython was written at a time where most companies looked at CPython thinking it would disappear in the next ten years unless a large company like Microsoft supports it. There is a lesson to be learned here about the success of an open-source language like Python.
Now what I’ve learned from using PythonNet is that there are a few things which are tricky to handle, namely:
.Net interfaces (too bad, Robot’s API is entirely written using them ): there is no such thing as an interface in Python, so it translates to a class but it can’t be instantiated so easily if I remember correctly.
methods with multiple signatures: again no such thing in Python which is / was a typeless language.
passing arguments by reference: python simply doesn’t do that because of the clever way it creates namespaces for each scope (you can find workarounds with global but it’s usually a sign of something gone wrong). This is a difference in paradigm between .Net languages and Python, not much we can do about that.
enumerations: my understanding is that Enum’s in .Net inherited from C, whereas Python has a enum class which is a layer above this to bring more flexibility. There’s been some work being done on that in PythonNet 3+, and Robot’s enums work better with this latest changes.
)
): there is no such thing as an interface in Python, so it translates to a class but it can’t be instantiated so easily if I remember correctly.