I plan to develop a scilab GUI application to manage realtime communication of local machine with a remote web server (http_get() requests) : basically a loop executed every xx seconds to retrieve some live data and update some internal state variables (Scilab application) that are sent back to the web server for live update there, and recording in database remotely.
I assume the realtime execution of the loop should be driven by Scilab realtime() function , may anyone share any documentation or link to existing online materials about similar applications ?
Is the GUI events management independant from the realtime() management?
If you mean reponse to GUI callbacks the answer is no. In fact triggering each loop iteration should be the events themselves, but Scilab does not have this mechanism (software interrupts).
Hello Stephane,
indeed I was meaning response to GUI callbacks… Does it mean that we can’t conduct a realtime acquisition/control process from a Scilab GUI ? I’m a bit confused because I have the feeling that similar mechanisms around GUI and realtime acquisition/control process are involved in the demo of Arduino interaction module, or NI gateway (VISA or NIDAQ). While the low level data acquisition and process that I want to manage with scilab is actually performed by NI’s hardware/software interfaces , the variables themselves are available in read/write mode from a internal standardized web server that I can access through standard scilab web functions.
In my minimal requirement case I will have to go on this way with realtime() and either console outputs/inputs or eventually(?)GUI callbacks execution, synchronized with the control/command loop.
In that case you have a DLL that deals with the synchronous or asynchronous acquisition stuff. That’s different from doing this with pure Scilab commands, if you have a main loop waiting for measurements e.g. from a serial port you cannot do something else as there is no concurency at the user level in Scilab.
Thank you Stephane for the clear explanation and eventual way to go.
Then the topic of -/not having concurrent execution levels in Scilab is becoming a philosophical matter: I suppose discourse is the right place to have such users discussion, user’s experience feedbacks !
!