Re: Matlab interfaces

["D. Peter Siddons" <siddons@bnl.gov>]

The Python interface does not start from ezca; does it have the same 
difficulties/restrictions? Maybe we should start from raw ca?
Pete.


Till Straumann wrote:
> 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
> >