![]() |
![]() ![]()
Experimental Physics and
| ||||||||||||||
|
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: "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
| ||||||||||||||
ANJ, 19 Mar 2025 |
![]() · Download · Search · IRMIS · Talk · Documents · Links · Licensing · |