[Scilab-Dev] Scilab interconnection

[Sylvestre Ledru]

Le samedi 13 mars 2010 à 16:23 -0300, Federico Bergero a écrit :
> Thanks for the response Sylvestre.
You are welcome.


> Sorry I didn't gave more info regarding the work we did connecting
> Scilab with our DEVS-Simulator
> (http://sourceforge.net/projects/powerdevs/).
> We wanted Scilab to act as a workspace for PowerDEVS (as it is Matlab
> for Simulink) . To this end we modify Scilab so that it starts a new
> thread that listens on a UDP port waiting for a request from
> PowerDEVS. The request are direct representation of the command to
> execute (a string like 'x=inv(A)*-b'), so if you send a UDP message
> containing that string, it gets executed in Scilab workspace. In some
> cases the new thread in Scilab gives the result of the last operation
> (the 'ans' variable) back to PowerDEVS. Based on this mechanism we can
> read and modify Scilab's variables and use it as a calculation engine.
> This solution works but like I said before is rather nasty. It has
> some problems, for example if you try use this mechanism while Scilab
> is running another scripts, Scilabs dies.
Indeed, Scilab is not thread safe for now. We are working on it but it
is a long and painful task.
However, in the family 5, we introduced a event loop (ie a decorrelation
of the various events). Though it is not available to a user, with a
minimal work, you should be available to lock the interpreter while you
run your task and unlock it after. 
If you are interested by this potential solution, I can send you some
pointers on the Scilab code source and some help. I can also apply some
of your patches to make it available easily to external codes.

> Our first attempt was to use call_scilab, in fact we used this
> solution for some time, but it didn't fulfill our objectives because
> we needed a complete Scilab instance with GUI. This is because one of
> our objectives was that the user of PowerDEVS could keep a live
> workspace running between simulations. For example changing a variable
> in Scilab workspace, running a DEVS simulation, change the variable
> again and then run another simulation.
OK, I understand your need.

>  If we had  implemented with call_scilab, the Scilab workspace is lost after the first simulation
> (because the program ends and quits).
> Perhaps I haven't used it well but I think that if a process uses the
> call_scilab mechanism, Scilab doesnt show a GUI, and when the caller
> process finishes, the Scilab instance finishes too.
Well, no, you control the start and stop of the Scilab session
(StartScilab & TerminateScilab). It remains in the same session until
you call these functions.

> So I was wondering if there is a cleaner mechanism that the one we
> have implemented.
Well, to talk with an already running application, network (or socket)
access seems the best way to go.

Sylvestre