Fixing broken program after RSL executor upgrade?

General Questions
1
Situation:
I have a simulation made in 3D Automate (by someone else, who is no longer available). I have imported to Visual Components 4.0. Some of the robots (Fanuc M-70iC/50) would not load (appeared invisible). I discovered I could use the Exchange Robot option BUT it required an upgrade of the RSL excutor.

However once I upgrade, the program breaks.

Traceback (most recent call last): File "r1::MainLogic", line 247, in OnRun IndexError: list index out of range
Line 247 is: robot_executor = robot.findBehavioursByType(VC_RSLEXECUTOR)[0]

Given that VC warns upgrading the executor may break the program, has a fix for this break (and/or explanation of why it breaks some programs) been provided so people can fix it after the upgrade?

Thank you.

 

 

2

Because the executors are not the same. Anyone upgrading from 2012/2014 to 4.x should be informed about this when upgrading, especially if you have old layouts that you want to upgrade to latest version.

If you need to update the scripts, do the first few lessons of the Python Robotics course in Academy to get familiar with the new executor and object types. vcRsl types are deprecated in 4.x product and marked that way in API reference.

Anyone upgrading from 4.0 to 4.1 should know that the executors are the same type but different.

  • Main difference is 4.1 executor uses "statement handlers" to customize the execution of statements -- there is a Word doc that explains this and provides different use cases, see this post https://forum.visualcomponents.com/forums/topic/4-1-features. In API reference, this change mostly relates to vcPythonProcessHandler since it can act as a statement handler referenced by a vcExecutor object.
  • Other difference worth mentioning is the thread execution of routines and statements in which you can force the script to not wait for completion of a routine/statement by the executor -- be very careful with that because there is no built-in queue for multiple calls, so each call would override the last one if it is not already complete.
    • One additional benefit is you have the option to clear the call stack before statement execution. I don't remember off hand, but to avoid recursive loop with call subroutines, this option comes in handy and is enabled by default... I think... check the API reference.