Re: Newbie Needs Ada Advice

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 8 May 2007 11:51:53 -0700, ezkcdude wrote:

> All helpful responses. Thanks. One idea that now makes some sense
> (having thought about it for all of a couple of hours), is that the
> GUI/interface could be a separate application that simply sets up the
> experiment (i.e. microscope configuration). For example, creating an
> XML document with appropriate hardware parameters, and then feeding
> this document to the "engine", which actually controls the microscope.

What for? If the parameter dialogs is the only GUI you need, you can
accomplish that in practically any GUI library in two days.

> The GUI could then be written using something even more high-level
> (like my favorite language MATLAB!).

You can call Ada from Matlab, same as you would call C. But, Matlab is not
GPL, it is rather a lot of money. And it is extremely slow. (For our
customers we often design hardware-in-the-loop systems with Matlab/Simulink
mounted on the system's top. Of course the engine is not Matlab, as you
suggested, otherwise it would never work. But the only reason why Matlab is
used, is not fancy GUI, but modeling our customers (mechanical engineers)
wanted to do in Simulink. These are open-end systems. It does not look like
your case.)

> The engine could be written in
> Ada. I could also write another application that would graphically
> monitor the ongoing experiment (i.e. display images).  This monitor
> could be web based, and simply interact with the data that is acquired
> by the microscope controller engine.

Simply interact means what? I bet a subprogram call is the simplest thing
one can imagine. A separate GUI process would mean some communication
middleman between the data acquisition/control engine and the GUI. TCP/IP
sockets, RPC, OPC? And all this just in order to display an image, a couple
of buttons and combo boxes? It looks like an architectural mess. From what
you have described, GUI is about half man-week programming in GtkAda.

> The only issue that still bugs me is that most of the hardware drivers
> for the major microscope manufacturers (Leica, Nikon, Olympus, Zeiss)
> are in C/C++, so there will still be a need to interface Ada/C/C++ to
> some extent.

I would not consider it as a problem at all. The real problem with hardware
interface libraries from third firms is that they are *normally*
non-portable, non-functioning and have documentation describing something
quite different from what you get. Add here, that the devices are customary
malfunctioning. If you send the command A followed by B, the device
software crashes. When you make a full-duplex communication, it crashes
again. When A is sent more frequently than each 100ms it crashes once more,
and so on and so forth. Usually GUI is your least problem.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de