Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: Writing PVs from an amalgamated structure
From: Ralph Lange <ralph.lange@gmx.de>
To: EPICS Tech Talk <tech-talk@aps.anl.gov>
Date: Mon, 9 Oct 2017 16:03:27 +0200
Here's my dreigroschen:

I find exposing internal C structures to the client a very brittle API that calls for trouble. How will you be organizing the necessary locking? How will you make sure the client does not completely screw up your structure by writing out-of-bounds of arrays/strings?
IMHO the better interface would be a functional one. Define a few setters and getters (can be taking the parameter name as an argument), and you'll be type-safe, can add sanity checks to values you get from the client, all locking is internal and in the scope of your library, and you are free to change your parameter structure as needed at any time.

Such a functional API can easily be interfaced using standard device support (one jump table per record type you want to support) or through ASYN's C++ driver class (one set of methods for each data type you need to get/set).

Cheers,
~Ralph



On Mon, Oct 9, 2017 at 3:49 PM, Arnold, Ned D. <nda@anl.gov> wrote:


Hey Iain -


I would do this in the sequencer (SNL - State Notation Language). The sequencer will do all the connection handling to the PVs and you can include your own library (C/C++) for the file operations.  I think you'll find it a nice environment to work in on the IOC.


   Ned



From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on behalf of Iain Marcuson <Iain.Marcuson@sydorinstruments.com>
Sent: Monday, October 9, 2017 08:23 AM
To: Johnson, Andrew N.
Cc: EPICS Tech Talk
Subject: RE: Writing PVs from an amalgamated structure
 
I have attached a diagram of what we are planning at the moment.  The functions ReadConfigFile() and WriteConfigFile() would be called when the user requests a load or save.  The configuration data would be stored in one big structure.  GetData() returns a pointer to the structure, and is intended as the link between the PVs and the library.



> -----Original Message-----
> From: Johnson, Andrew N. [mailto:anj@aps.anl.gov]
> Sent: Saturday, October 07, 2017 6:59 AM
> To: Iain Marcuson <Iain.Marcuson@sydorinstruments.com>
> Cc: EPICS Tech Talk <tech-talk@aps.anl.gov>
> Subject: Re: Writing PVs from an amalgamated structure
>
> Hi Iian,
>
> I think we need to know quite a bit more about what you're trying to do, and
> where/when these configuration files will be read and/or written. The
> answers are likely to be very different depending on what you tell us, and I
> don't think anyone wants to spend time answering the wrong question.
>
> - Andrew
>
> --
> Sent from my iPad
>
> > On Oct 6, 2017, at 6:22 PM, Iain Marcuson
> <Iain.Marcuson@sydorinstruments.com> wrote:
> >
> > I need to create support for reading and writing a configuration file, but I
> also have to support non-EPICS environments.  I am thus considering making
> a library to be used in the IOC.  My present idea is to pass EPICS a pointer to a
> structure containing all the configuration options.  However, I do not know
> what best practices are for mapping PVs to the memory location.  What are
> the accepted methods?
> >
> > Thank you,
> >
> > Iain.
> >
> >


References:
Writing PVs from an amalgamated structure Iain Marcuson
Re: Writing PVs from an amalgamated structure Johnson, Andrew N.
RE: Writing PVs from an amalgamated structure Iain Marcuson
Re: Writing PVs from an amalgamated structure Arnold, Ned D.

Navigate by Date:
Prev: Re: Writing PVs from an amalgamated structure Arnold, Ned D.
Next: EPICS IOC Redundancy Configuration Michaelsmith2017
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: Re: Writing PVs from an amalgamated structure Arnold, Ned D.
Next: Basic String Concatenation in EPICS Sobhani, Bayan
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 10 Oct 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·