[Scilab-Dev] Scilab interconnection

[Federico Bergero]

On Sun, Mar 14, 2010 at 9:30 AM, Sylvestre Ledru
<sylvestre.ledru at scilab.org> wrote:
> 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.
Ok. Send me info and pointers about how to do this. Is this solution
possible both in Linux and Windows?
>
>> 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.
And call_scilab starts a complete Scilab instance? With GUI? Anyway
the problem is that this kind of communication wouldn't be available
after the caller process finishes, in order for a new process to
communicate with the running Scilab, is that right?
>
>> 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.
Yes. We've implemented thorught UDP beacuse it is message orientated
but we now have problems beacuse of UDP packet limit (we cannot send a
complete matrix in a UDP message), so we are thinking of using TCP.
Federico
>
> Sylvestre
>
>
>



-- 
I find television very educational. Every time someone switches it on,
I go into another room and read a good book.