06-20-2017 12:34 AM
Hi everyone,
I am currently using the Labview to Scilab Gateway and really enjoying it. However, my scilab script is quite big, and requires 5-10 seconds by itself to execute.
To facilitate the user, I intended to use a progression bar. However, I think it is not possible to dynamically get values out of the Scilab Script node. (I was simply thinking of putting a time variable in my script (suppose integer t) and increment it after every 5 lines or so. I could then display it in progress bar.
Is there any way to do this. I could also use set cursor to busy, but that would not be as helpful. Kindly give any suggestions if possible.
Solved! Go to Solution.
06-20-2017 04:05 AM
(SubVI) with Horizontal progress bar
set scale range
loop until a timeout
update loop with progress along progress bar (numeric value)
simple
Lots of nice extras can be added and tweaks to make it nicer as you wish.
James
06-21-2017 05:14 AM
Hi James,
As I mentioned earlier, I am facing problems with updating the loop with the numeric values for the progress bar. The scilab script node returns value only when it has completed executing, like a sub VI.
I cannot obtain values from it dynamically. However, I would like to give the user a measure of how much time it would take to complete the script. (It generally takes 5-10 secs but may sometimes it takes 30 secs also for large input data.
It does not immediately seem possible to me. Is there a way??
06-21-2017 06:26 AM
I think you misunderstood me.
If you know the estimated time remaining - from previous empirical experience, then you can create the above described subVI and launch it as a Dialog in parallel to the SciLab function.
A reference to a stop Boolean will allow closing of this immediately on completion of the Scilab function.
This is a technique I often use when I have to launch a process over which I have no control but which I have a good idea how long it might take to complete, just so that the operator knows that the system has not hung. (a classic example would be when programming a chipset via a remote module.)