Re: App blueprint, advice please!

[Michael L Torrie <torriem chem byu edu>]

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


-- 
Michael Torrie
Assistant CSR, System Administrator
Chemistry and Biochemistry Department
Brigham Young University
Provo, UT 84602
+1.801.422.5771