Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Tue, 18 Dec 2007 14:35:52 +0100

Emmanuel Mayssat wrote:

No. Just use @init {readRegister;}
Example:
readRegister { out "\$1"; in "%i";}
writeRegister { ...  @init {readRegister;} }

This is interesting. It means that writeRegister and readRegister must
have the same parameters and in the same order. readRegister($1, $2) for
example would seem more intuitive, besides I could also do
readRegister($2,$1), or readRegister(23,$3), etc.

Well, there is no need to use references to other protocols if this is a problem
for you. In other words, you may use the commands directly like

writeRegister { out "\$1 %i"; @init {out "\$2"; in "%i";} }

and call writeRegister with 2 parameters, one for output, the other for init.

I looked at the aai record.
Why is the aai record not compiled in?
I suspect it is because R3.13 did not include it in its epics bases, is
this the case?

Yes, aai and aao are commented out in CONFIG_STREAM because they are commented
out by default in some EPICS versions. Just comment them in and recompile
stream. The code is already there.

I noticed that my IN directive for a protocol is hitting a limit.
I did not investigate this problem in depth.
But I am faced with the situation where I have something like
in "%*x,%*f,%*i,%*X,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f, (a few
more ;-),%*f,%*f" ;
If the IN directive is too long (or there are too many converter
matching), then the program complains and do not work.
Is there a "length" and/or "number" limit(s) on the directives?

There is an implementation limit in the parser of 20 formats in one line of the
protocol, resulting in the error message "Too many formats in line". Just break
the string into more lines. (I should change the error message to something more
helpful.)
in "%*x..many more %"  # 20 formats, closing quotes, new line, no semicolon
   "more % formats";   # opening quotes, string continues, semicolon.
I will try to avoid this limit in a future version.

I use a device with crc/checksum checking. the converter works very
well. But the communication is flaky. So I get crc errors for 20% of my
messages. As a result my IOC terminal is flooded with asyn/stream error
messages. Is there a way to disable those globally? or locally at the
protocol level?

Not yet. Message filtering is something I wanted to implement for a long time.
Maybe I'll find some time for this next year.

Before implementing the aai record, I tried with several ai configured
as I/O intr scanned records.
1/ For one of my devices, I have the reply from the device broken in two

segments and the matching by the I/O intr ai is not working.

The matching would clearly work on the complete reply.
The situation I am facing is similar to
the value is in the first reply segment, but I need to check the crc

which is in the other segment of the reply.

What the pollTimeout parameter to control just that?

With I/O Intr, all records should read the complete reply, pick their piece of
data and ignore the rest with %*. For example with 2 floats:
read1 {in "%f,%*f%<crc8>";}
read2 {in "%*f,%f%<crc8>";}
Both records get the checksum for the complete reply.

2/ I have another device with whom I can do 1 ai trigger record ( with

the OUT directive) and several ai records configured as I/O intr. I

noticed that the trigger record times out (STAT = TIMEOUT right after

all the @init complete) if too many I/O intr records are attached.
Is that expected? Do I/O intr record lock the asyn interface?

I/O Intr records process their input inside the asyn thread that originally got
the input (your trigger record). Actually they get their input even before the
trigger record gets it. That's how it is implemented in asynDriver. At the
moment, the I/O records not only get their input within this thread, they are
even processed within this thread (and all their FLNKs and so on). This can
cause delays. I plan to change this. For the moment, try to make the timeout
longer.
Finally (and this is on my wish list), I would like to have protocol

directives able to communicate on different asyn interfaces.
For example, I would like to OUT on an asyn file interface for debugging

purpose or IN on again a another asyn file interface for the init value.

Right now, I can do that but it requires each time rewriting the asyn

interface code. So allowing for the asyn port/interface to be set in the

protocol would be welcome.

I'm not sure if I really understand what you want to do. Do you want to
communicate to different ports in the same protocol? That would require a quite
complicated change in the driver. At the moment I use the locking mechanism
built in to asnDriver on a port by port basis. Changing this to work on multiple
ports is not trivial.

Dirk

--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System