Typically: "How do I... ", "How can I... " questions
Pouya
Posts: 12
Joined: 15 Feb 2013, 11:19

Hello,

I use v-rep in different projects and one aspect that bugs me a lot is they way that plugins load upon v-rep launch. Say that I have two projects, Prj1 and Prj2 with two shared objects libv_repExtPRJ1.so and libv_repExtPRJ2.so.

When I work on Prj1 I have to remove Prj2 shared library from v-rep directory and do the converse when I switch to Prj2. My question: Is there any way to load plugins on demand? For instance is it possible to put plugins in a separate folder and pass them as command line option? Or even better, would it be possible add a lua script to the scene related to PrjN which loads the associated plugin only?

Thanks,
Pouya.

coppelia
Posts: 7925
Joined: 14 Dec 2012, 00:25

Hello Pouya,

you are right, this wasn't possible until now. We have now added that functionality, which should be available in next release. We will very probably also update the binaries of current version (i.e. 3.2.3) in the next few days, and the changes will be reflected. You will then be able to dynamically load a plugin from a script with simLoadModule, and dynamically unload it with simUnloadModule (in current version these commands were only available from the C-API).

You will only have to watch out for 2 situations:
• ***THIS RESTRICTION WAS SOMEHOW RELAXED. SEE NEXT POST*** If a script is dynamically loading a plugin, it will not be able to use the custom Lua functions that the plugin registers, until the time the script is initialized again (e.g. at simulation start for instance for a child script). This means, you will have to load that plugin in the init phase of the main script, or in another child script that initializes before the script that will use the custom Lua functions. You can do this by setting an execution priority to that first child script, if it is located in a same scene hierarchy tree level.
• Dynamically unloading a plugin could lead to a crash if that plugin registered custom Lua functions in the old way. So if your plugin is intended to be dynamically loaded/unloaded, then register Lua functions by specifying the function name with functionName@pluginName, instead of functionName as until now. If your plugin is v_repExtMyPlugin.dll and your function name is simExtMyFunction, you would submit a function name simExtMyFunction@MyPlugin to simRegisterCustomLuaFunction.
Cheers

coppelia
Posts: 7925
Joined: 14 Dec 2012, 00:25

The first situation mentioned above was slightly relaxed:
• If a script is dynamically loading a plugin, it WILL BE ABLE to use the custom Lua functions that the plugin registers. Other scripts that were already initialized will however not be able to use those custom Lua functions, unless they are reinitialized again (e.g. next time simulation starts again).
Cheers

malacasse
Posts: 2
Joined: 09 May 2017, 18:50

Can you give an example of how to dynamically load a plugin ?
I have a plugin that works when loaded at start up but I have not been able to load it at runtime.
I rename my plugin "gripperplugin.so" and try to load it with "sim.loadModule('/opt/gripperplugin.so', 'gripperplugin') in a child script but without success.

thanks

coppelia
this looks about right. What is the return value for the sim.loadModule call?