Re: Stream protocol configuration

[Dirk Zimoch <dirk.zimoch@psi.ch>]

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