Re: StreamDevice : scope of system variables

[Peter Milne via Tech-talk <tech-talk at aps.anl.gov>]

Hello Dirk

The short answer #3 is exactly what I wanted to hear, and the additional detail is very helpful.

Many Thanks

Peter

On Thu, 13 Mar 2025 at 10:11, Zimoch Dirk <dirk.zimoch at psi.ch> wrote:

Hi Peter,

 

Short answer is 3.

 

The scope of any variable defined outside a protocol is all protocols that follow in the same file. That means the value can be changed between protocols. But it has no effect on other files. There is no “global” definition that affects other protocol files. If a variable is not defined in one protocol file (but in another), the default value of that variable is used (which can be a hard coded constant, or the value of another variable, or an asyn setting of the port). There is no “spill-over” from previously used protocols from a different file on the same asyn port/socket.

 

You can also define a variable inside a protocol. This overrides whatever the file-global setting is at the moment. Its scope is limited to that protocol. Inside a protocol, variables are currently position independent. That means you can define variables after the commands, and they still work. But that also means you cannot change a variable between two commands. Only the last value would be in effect for the whole protocol. I recommend to define variables inside a protocol at the beginning, because in the future I would like to change that behavior so that you can actually change the value (e.g. ReplyTimeout, InTerminator or MaxInput) between two commands.

 

If you “include” one protocol in another, i.e. use the name of another protocol (from the same file) instead of (or in addition to) ‘in’ and ‘out’ commands, that uses only the commands, not any variables defined before or inside the referenced protocol.

 

Multiple asyn ports / sockets can use the same protocol file and the same port can use protocols from multiple files. The variable scope is always bound to the used protocol and thus to the file the protocol is taken from. There are no per-port variables.

 

However, asyn itself has some per-port settings. For example, you can define different terminator strings for different ports. They are used by StreamDevice only if you do not define your own terminator variables in the protocol. Otherwise, StreamDevice will temporarily change the terminators to its own settings while the protocol is active and restore the value afterwards. Thus, even in this case there is no spill-over.

 

“I/O Intr” scanned records are a bit special. They passively receive a copy of any input that the currently active record receives. If no record is active, one of the “I/O Intr” records is (not quite randomly but unpredictably) selected to poll the device. Thus, having different values for different “I/O Intr” records (i.e. their respective protocols) listening at the same asyn port may have “interesting” effects.

 

Be aware that StreamDevice serializes communication only on a per port basis. If you use two ports to talk to the same hardware, StreamDevice sees this as two independent devices and thus does not prevent sending a new request on one port before an active request on another port has been answered (or timed out). Depending on your device, that may or may not be a problem. I do not recommend this. I do recommend to use different priorities, e.g. HIGH for commands and LOW for periodic status readout. Higher priority records will be processed before any lower priority record currently queueing for access to the port. It will of course not interrupt any lower priority protocol already active.

 

Best,

Dirk

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Peter Milne via Tech-talk
Sent: Donnerstag, 13. März 2025 09:53
To: EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: StreamDevice : scope of system variables

 

Hello, this question is really for Dirk if you are there:

 

Our system uses StreamDevice together with Asyn to set and get parameters on local socket connections.

When there is a lot of traffic (eg 50 parameters) on one socket connection, I'd tend to open another socket to the same parameter services, maybe one socket for high priority and one for low priority, this works better, faults are more localized and it's easier to debug.

 

We have a requirement to increase the System Variable: ReplyTimeout on one command in one protocol file.

 

So, it's easy of course to add the appropriate ReplyTimeout to the top of that protocol file; now all the commands in the file get that timeout, but it's OK, there are only a few, and in any case, if the scope of the System Variable is limited to the single protocol file, it would be easy to split out the single command response into its own protocol file if necessary. 

That would be absolutely fine and good but does it really work like that?

My question about System Variables, is what is their scope?

is it:

1/ Global across the whole IOC, across all sockets/channels and protocol files.

2/ Local to a given socket/channel, but applying across all protocol files using that socket  or

3/ Local to the protocol file. Other protocol files used on the same socket/channel are unaffected.

 

I'm hoping it's a 3,  could be indicated by:

https://paulscherrerinstitute.github.io/StreamDevice/protocol.html#sysvar

"System and user variables can be set in the global context of the protocol file or locally inside protocols".

 

But I'm not sure, do all the protocol files really have independent context, or is it "the last value setting is the one that sticks"

 

ie if two protocol files set the same SystemVariable on the same socket, do each get their own setting, or is it undefined which one we end up with.  That would be amazing, but I'm thinking the answer may really be #2 "local to socket".   I'm sure it's not a crude full-program global as per #1

 

 

Thanks

Peter

 

 

--

Peter Milne, Director of Sales

www.d-tacq.com

--

Peter Milne, Director of Sales

www.d-tacq.com