Re: App blueprint, advice please!

[Patrick <optomatic rogers com>]

Hi Michael

Thanks for the signals and slots tip, that's great.

As for NI:
<rant>
My experience is limited and quite dated(8-9 years) but it is my 
understanding that in order to distribute "free" (as in beer) Labview 
code the recipient must have Labview loaded. It is possible to generate 
an executable that will run without Labview loaded but a small license 
fee must be paid back to NI. In addition I believe this executable code 
generation option is at an additional premium to the base Labview.

Indeed some of the instruments I want to control have their own NI 
drivers already. This however has not displaced the native software that 
shipped with the instruments originally. I believe only an open source 
model will provide enough empowerment to tempt lab operators away.

I started with Linux back in 2004 but it is only in the past year that I 
have started posting to lists. I have been completely awestruck at the 
responses to my questions, both here and on other lists. With so many 
talented people like you answering my questions without expectation of 
compensation, how can a company like NI compete in terms of "customer 
service", I am saving up for this project. I would rather spend 2K 
sponsoring my open source comrades then those punks at NI
</rant>

Okay I am back now, Have a great day-Patrick



Michael L Torrie wrote:
> Patrick wrote:
>   
> > Lets say a customer had a detector and a pump to pump a sample through 
> > it. We could write a Bash script that works something like this:
> >
> > -icon launches Bash script
> > -sends variable " 2" to pump command to pump 2 ml per minute
> > -pump command sends signal to serial port or GPIB bus, etc
> > -bash sends variable "230" to set the detector to wavelength 230 nm
> > -bash autozeros detector
> > -launches plot command
> > -after that launches data process command
> > -then launches database storage command
> > - emails whoever, turns your coffee maker on or whatever....etc..etc
> >     
>
> Seems to me that the lingua franca of this kind of scientific instrument
> control and data collection is LabView.  Most institutions already have
> site license for this software.
>
> LabView is ideal for several reasons:
> - Works with most GPIB cards, indeed most interface cards come with
> labview drivers
> - Easy graphical environment.  Lets you chain things together (in a
> similar manner to bash, actually), but it's all within the program,
> rather than kludging together non-integrated programs.  Plus it's all
> in-process.  No external spawning things needed, which is expensive.
> - Royalty free code.  You can sell you "vi" programs or give them away,
> or whatever.  They aren't compiled, but can be obfuscated, or not.  So
> you could sell labview code that people could modify.
>
> On the other hand, there's no reason why you couldn't use GTK and, say,
> Python to do similar things provided that you have drivers for the GPIB
> boards, and have a well-defined interface that you can use to easily
> build modules that you can string together.  Certainly I don't believe C
> is the appropriate language to do any gluing.  I would recommend python.
>  Data collection modules that need to be close to the hardware can be
> done in C, but the rest could easily be done in python.  If you defined
> a protocol for modules to communicate with each other, then you can very
> easily string modules together, hooking data out buses on one module
> (object) with the data in on another module.  The GTK signals and slots
> mechanism would make this quite easy to do, all in-process.
>
> Michael
>
>
>   
> > It's a terrible over simplification but hopefully illustrates the idea.
> >
> > I only have a few hundred dollars to put towards this now but hopefully 
> > by the later half of 2008 it will be a few thousand. Please feedback 
> > with any thoughts you might have on this whole process. Thanks-Patrick
> >
> >  
> >
> >
> > _______________________________________________
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
> >     
>
>
>