EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: snc/seq enhancements ... local-variable access
From: "Chestnut, Ronald P." <[email protected]>
To: <[email protected]>
Date: Tue, 4 Apr 2006 10:45:57 -0700
Snc/seq afficianados!

I wanted to give a bit more context to Mike's posting. In the past few EPICS meetings Matthias and I have discussed incremental enhancements to snc/seq code which are useful for the present EPICS version, and as well are important for the identified future need of supporting redundant snc/seq code for immediate fail-over.

We (including Mike) will be discussing this at the June EPICS meeting in more detail.

Mike now generates the internal variable "symbol table", and, as demonstrated in his posting, has code which accesses scalar values. One program, even with two state sets, has only one set of internal variables (they are file scoped). So for simple data access, one need only specify the program name (or id) and symbol name, as Mike has so far provided. It is important to note that only variables "seen" by the snc/seq processor are included in the internal variable table; declarations in escaped code cannot be dealt with. 

The initial access to the seqVarxxx API is via a small set of PVs which support an action string, access to the internal seqVarxxx code (GENSUB), and a result string. This simple, scalar-only access should provide enough framework to support the next step, "state level debugging". Matthias has given thought to an eventual future API, which will support redundant snc/seq code (as I remember, not via Channel Access).

One thing Mike is asking for is input on the desired interim API. Do we require that programmers do seqShow to get ids, then seqValShow to get names, i.e. totally know that they are doing? Or do we provide programatical access for discovery - select an IOC and fill in the sequence name menu, select a sequence and get the state set menu filled, select a state set and get the process variable names, etc. Do we get arrays of names returned, or use an iterator? How should access to arrays work? Should individual elements be selectable or should the user code on the client end worry about that?

The "out of order transitions" Mike speaks of are one of the ideas associated with state-level debugging, wherein you can force a transition to any state mentioned in any when-clause in the current state. We have two tentative scenarios for implementing state-level debugging, now that the internal variables are available; more later (or in June, when we demo all this.)

Ron Chestnut

-----Original Message-----
From: Laznovsky, Michael [mailto:[email protected]] 
Sent: Tuesday, April 04, 2006 12:01 AM
To: [email protected]
Cc: Laznovsky, Michael
Subject: snc/seq enhancements ... local-variable access

Greetings EPICS fans- I'm sending this email to solicit suggestions and comments for some snc/seq enhancements I'm working on, in this case support for access to local variables within sequence code.

Access is provided by show/get/put functions, and also via special PVs when a small database is added to the IOC.  Progress thus far includes snc producing the required data structures and the aformentioned seq functions.  For example, the following illustrates a set of declarations in a source file and the output of a series of "seqVarShow" calls:

	char         errmsg[256];
	char        *pbuf;
	char        *pbuf2;

	short        n;
	int          xyz[5][10];
	unsigned int m;
	long         foo;

	float        a;
	double       z;
.....

Get thread ID:

	epics> seqShow
	Program Name     Thread ID  Thread Name      SS Name
	zz99Control      1e7a80     zz99seq          zz99_ctrl

"seqVarShow" with no arguments displays all local variables in all state programs (or you can provide the thread id as an argument to limit output):

	epics> seqVarShow
	Program: zz99Control
	  Name                  Type            [n][n]  Address Value
	  -----------------------------------------------------------
	  errmsg                char            [256]   1e5334  "0"
	  pbuf                  char *                  1e5434  (NULL)
	  pbuf2                 char *                  1e5438  192270 -> "90 0 34 ..."
	  n                     short                   1e5448  "-77"
	  xyz                   int             [5][10] 1e5536  "3"
	  m                     unsigned int            1e544c  "1"
	  foo                   long                    1e5330  "0"
	  a                     float                   1e543c  "1.0"
	  z                     double                  1e5328  "0.1873811581904769"

"seqVarGet" with thread ID and variable name displays just that variable:

	epics> seqVarGet 1e7a80,"z"
	"0.9685835438816328"

"seqVarPut" with thread ID, variable name, and value (as string) modifies the variable:

	epics> seqVarPut 1e7a80,"m","33"
	epics> seqVarGet 1e7a80,"m"
	"33"

Things to note (all preliminary at this point):

Both reentrant and non-reentrant cases are properly handled.

Variables of type "pointer" are resolved, so that the objects pointed to are get/put, rather than the pointers themselves (unless the pointer is NULL). 
Maybe provide a way to alter the pointer itself?

Character arrays (strings) are displayed/entered as numeric byte sequences (could be selectable?).

Need a general way to get at arbitrary array elements.  Currently only the first element is accessible.

While local variables are file-scoped (and thus shared by all state sets within a given source file) the only way I see to uniquely identify a collection of them is via a "thread ID"... "program name", "thread name", and "SS name" 
are all potentially subject to collisions when multiple sequences are loaded and/or invoked.

Short-term future plans include database and EDM display infrastructure to support run-time debugging of state programs, including state single-stepping and forced out-of-order transitions.

Feedback welcomed.

Mike


Navigate by Date:
Prev: Re: snc/seq enhancements ... local-variable access Eric Norum
Next: Re: snc/seq enhancements ... local-variable access Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: snc/seq enhancements ... local-variable access Dalesio, Leo `Bob`
Next: RE: snc/seq enhancements ... local-variable access Laznovsky, Michael
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024