Re: Matlab interfaces

[Till Straumann <strauman@slac.stanford.edu>]

Allison, Stephanie wrote:

> Hi Timo,
>
>  
>
> > we at PSI have been looking at the Matlab-EPICS interfaces. 
> > There seems to exist two: labCA and mca. 
> >    
> ...snip...
>  
>
> > What are the advantages of one package vs. the other?
> >    
>
> LabCA Advantages:
> (1) Ability to set timeout on CA gets and puts (the old version of mca hardcodes 1 second, maybe newer versions allow for it to be tuned).
> (2) Nice documentation.
> (3) Multithreading available for 3.14 (don't know if mca allows for it).
>  
>
> (4) Easier to install than mca (my opinion).
>  
Should also be fairly easy to port to other programs (matlab and scilab
are currently supported), i.e., doing an octave interface wouldn't be
very hard.

> LabCA Disadvantages:
> (1) Uses the EZCA package which some think (after looking at the code) is a challenge to maintain.  Till has moved a copy of EZCA into labCA and keeps that one up-to-date (not the one distributed in EPICS extensions).
> (2) In the past, people have mentioned that EZCA doesn't handle monitors properly, in particular, reconnecting on IOC restart.  But I believe Till has fixed those problems with his latest version of labCA.
>  
I think I did. The disadvantage I see is that ezca (and therefore labCa)
basically uses 'ca_pend_event()' and this means that any call to ezca
has a timeout granularity of no less than the timeout given to 
ca_pend_event().

If for example a pend-timeout of 0.1s is used no lcaGet() will ever return
in less than 0.1s - even if the data arrive faster.

The total timeout (which, as Steph has pointed out, is configurable)
equals the basic ca_pend_event() timout times a number of 'retries'.

If you want the system to be more responsive then the pend-timeout
has to be shorter and the CPU ends up burning more cycles since
there is essentially a loop

for (i=0; i<nRetries; i++) {
   ca_pend_event( 0.1 seconds );
   do_ezca_work();
   if ( all_outstanding_requests_satisfied() )
      break;
}

I don't claim that labCA is perfect. At the time, I needed an interface
to scilab and using ezca was just the fastest to get something going.
Later, some people here at SSRL liked it and the fact that it supported
EPICS-3.14 (which MCA at the time did not) permitted transferring
large arrays and they asked me for the matlab interface.

IMO it could be worthwile to develop a clean CA interface for packages
like matlab/scilab/octave from scratch -  with emphasis on a 'properly
layered' approach so that different packages can easily be supported.

-- Till

BTW: working on a CA interface for integration with an existing
application (matlab/scilab) painfully exposes (one of) the weaknesses
of C++ (compatibility issues of run-time libraries/executables)
-- innumerable hours I spent debugging exception handling and
wishing CA had never gone C++. There always arise subtle and
compiler-version dependent problems...

> Stephanie Allison
>