Re: GPIB serial poll of an instrument

[Ron.Simonson]

On 07/12/2013 05:08 AM, CdeMills wrote:

> Hummmm ... I've developped high performance acquisition solutions over
> years. My advice is NOT to try to design some ONE-DO-IT-ALL tool. You are
> mixing problems and constraints, bug in one piece of the code turn may
> contaminate other part of the design ...
>
> I prefer an clean approach, where the main task is subdivided into subtasks
> and programs:
> 1) acquisition and data storage: the simpler the better. Use low-level
> language (C) and buffer everything in a simple format. Store enough
> information to be able to reconstruct a complete description of the
> measurements.
> 2) data processing: Octave comes handy, use a pattern like load - analyse -
> save
> 3) data consolidation and plotting: use either Octave in a second step,
> either programs more oriented towards statistics, like R.

I agree quite strongly with the points made by CdeMills!  These points
are particularly important for tests that take a considerable length
of time to run and/or those that you cannot repeat if something goes
wrong.