[SciPy-user] Scipy + Vision = LabView ?

Stef Mientki s.mientki@ru...
Sat Nov 3 19:37:28 CDT 2007



Gael Varoquaux wrote:
> On Sat, Nov 03, 2007 at 11:52:52PM +0100, Stef Mientki wrote:
>   
>> I don't think any of the mentioned packages is capable of (pseudo-) 
>> realtime programming,
>>     
>
> What do you mean by that. Reaction to the changes as they happen, a bit
> like in labview. I think enthought's pacakage would be the one to look
> at, as a reactive interaction with the user was one of their design
> goals.
>   
What I mean, is for "realtime" control loops.
Let's say I sample data at something like 20 kHz,
want to perform some calculations on it,
display it and feed the manipulated data back to my hardware,
how am I going to let the data flow:
- sample by sample, much too slow
- chunking, that will work, but do these environments support that ?
I do the latter in Scipy, but with a Delphi GUI ;-) , that works quit well.
In the radio world there seems to be a even much faster approach (real 
time demodulation).
>> so there might be room for one more package ;-)
>>     
>
> No, you mean, it would be interesting to extend an existing package :->.
>   
It's always funny to see that "others" know better what "I" mean ;-)

Well Yes and No, seeing the mentioned examples, these are my quick 
thoughts (and it's not all about taste)
- I like the Elefant / SciCos graphical view
- I like the rectangle connections of Vision
- Libraries should be organized in a tree, which consists of an 
auto-organizing part and a user configurable part, this tree should have 
full drag and drop and be fully editable
- Dataflow should be selectable per block: sample-based, chunked or 
sequential
- Each block should be directly editable, which will automatically 
create a new device (unless ..)
- A block can be created by pure code, flow chart, graphical state 
machine or any combination of these,
but also from an electrical circuit diagram, a pneumatic circuit, a 
physical design or a virtual world design.
- In sequential mode, partial execution should be possible, which means 
that all intermediate results should be stored
- The user interface of the final application should be controlled 
completely, independent of the functional program
- Not the deep nesting of LabView, everything should be available in at 
most 2 clicks
- Code snippets should be available in user organizable way

ok, I'm dreaming again ;-)

but on the other hand, most of the parts are somewhere in Python available !

cheers,
Stef



More information about the SciPy-user mailing list