01-23-2023, 04:32 PM
Hi Albert,
Thanks for the help with this.
I created a shareable version of my workstation that has proprietary object models removed. Hopefully this will not impact its usefulness for debugging. (Attached as "shareable.rdk")
When conducting the debugging you recommended, I am already running with the -NOUI flag, so I did not attempt to call RDK.Render(False). Let me know if I should go back and try that.
Since I am running with -NOUI, I added the command line arguments from RoboDK-Debug.bat directly to my code rather than starting RoboDK using the .bat file. Again, let me know if I should go back and try starting it that way. Command line arguments below:
["-NOSPLASH", "-SKIPMAINT", "-NOUI", "-DEBUG", "--enable-logging --log-level=3 --v=1", "^>logfile.stdout.txt"]
Connecting with the Python API first provoked a hang, as described in issue 1. The log file is attached: "python_first_issue_1.txt". Note that:
1. Both the Python and C APIs are attempting to get handles for almost every item in the workstation. This is the intended behavior.
2. It looks like some of my console prints ended up in the debug output. I believe most lines without a timestamp are something that I added. Go ahead and ignore those.
Connecting with the C API first was interesting. The C API connected then provoked a hang, as described in issue 1. This produced the attached log file "c_first_issue_1_c_log.txt". (I removed some file path information from the log file that might be too confidential for the forums. The placeholder text should be obvious.) After the C API hung, I started the Python API, which was able to successfully connect to RoboDK and produced the attached log file "c_first_issue_1_python_log.txt". Note that as usual, the Python calls never hung. The Python program successfully retrieved handles for all desired workstation objects.
I think that covers everything you mentioned.
#######################################################
I did notice one more thing that may be useful. My current architecture involves farming out operations to multiple virtual machines running on my laptop (exploits multiple cores and gets around Python's GIL). My physical machine sends information to the virtual machine, then the virtual machine conducts RoboDK operations based on that and returns a result to the physical machine.
I noticed that the issues I am describing with hangs occur exclusively on virtual machines. When running code directly on my laptop, I am not able to reproduce any of the issues described in this post.
The virtual machines are on VMware Workstation 15 Pro, 15.5.7 build-17171714, running windows 10, 64-bit. They network with the physical machine through a socket created in Python. The Python port does NOT conflict with the RoboDK port.
Thanks for the help with this.
I created a shareable version of my workstation that has proprietary object models removed. Hopefully this will not impact its usefulness for debugging. (Attached as "shareable.rdk")
When conducting the debugging you recommended, I am already running with the -NOUI flag, so I did not attempt to call RDK.Render(False). Let me know if I should go back and try that.
Since I am running with -NOUI, I added the command line arguments from RoboDK-Debug.bat directly to my code rather than starting RoboDK using the .bat file. Again, let me know if I should go back and try starting it that way. Command line arguments below:
["-NOSPLASH", "-SKIPMAINT", "-NOUI", "-DEBUG", "--enable-logging --log-level=3 --v=1", "^>logfile.stdout.txt"]
Connecting with the Python API first provoked a hang, as described in issue 1. The log file is attached: "python_first_issue_1.txt". Note that:
1. Both the Python and C APIs are attempting to get handles for almost every item in the workstation. This is the intended behavior.
2. It looks like some of my console prints ended up in the debug output. I believe most lines without a timestamp are something that I added. Go ahead and ignore those.
Connecting with the C API first was interesting. The C API connected then provoked a hang, as described in issue 1. This produced the attached log file "c_first_issue_1_c_log.txt". (I removed some file path information from the log file that might be too confidential for the forums. The placeholder text should be obvious.) After the C API hung, I started the Python API, which was able to successfully connect to RoboDK and produced the attached log file "c_first_issue_1_python_log.txt". Note that as usual, the Python calls never hung. The Python program successfully retrieved handles for all desired workstation objects.
I think that covers everything you mentioned.
#######################################################
I did notice one more thing that may be useful. My current architecture involves farming out operations to multiple virtual machines running on my laptop (exploits multiple cores and gets around Python's GIL). My physical machine sends information to the virtual machine, then the virtual machine conducts RoboDK operations based on that and returns a result to the physical machine.
I noticed that the issues I am describing with hangs occur exclusively on virtual machines. When running code directly on my laptop, I am not able to reproduce any of the issues described in this post.
The virtual machines are on VMware Workstation 15 Pro, 15.5.7 build-17171714, running windows 10, 64-bit. They network with the physical machine through a socket created in Python. The Python port does NOT conflict with the RoboDK port.