EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <2015>  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <2015>  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: variable-length-pCAS task
From: Matej Sekoranja <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Fri, 3 Apr 2015 10:01:03 +0200

On 31 Mar 2015, at 21:44, Andrew Johnson <[email protected]> wrote:

Hi Matej,

On 03/31/2015 07:54 AM, Matej Sekoranja wrote:
Just a quick question: I’ve updated CAS code and I want to test it.
My plan is to take makeBaseApp example caServer and change scan
method to change array size (aka new_size = (size+1) % 10).
However, I cannot get monitors working (I get no updates… even the
first one). Is it supported to work? The code surely looks so. Note
that it worked one time (one try out of 20) :/

I just built the makeBaseApp caServer example and ran it with no
arguments. It creates a fixed set of PV names in exServer.cc, so I
connected to the first one:

tux% caget jane
jane                           0.251968
tux% cainfo jane
jane
   State:            connected
   Host:             tux.aps.anl.gov:5064
   Access:           read, write
   Native data type: DBF_DOUBLE
   Request type:     DBR_DOUBLE
   Element count:    1
tux% camonitor jane
jane                           2015-03-31 14:37:48.289811 0.363631
jane                           2015-03-31 14:37:49.105167 0.297269
jane                           2015-03-31 14:37:49.200278 0.286364
jane                           2015-03-31 14:37:49.295394 0.285211
jane                           2015-03-31 14:37:49.390555 0.191317
...

There appear to be two array PVs, alan and albert:

tux% cainfo alan
alan
   State:            connected
   Host:             tux.aps.anl.gov:5064
   Access:           read, write
   Native data type: DBF_DOUBLE
   Request type:     DBR_DOUBLE
   Element count:    100
tux% cainfo albert
albert
   State:            connected
   Host:             tux.aps.anl.gov:5064
   Access:           read, write
   Native data type: DBF_DOUBLE
   Request type:     DBR_DOUBLE
   Element count:    1000

I ran a monitor on alan and did get updates at approximately 2-second
intervals:

alan 2015-03-31 14:41:30.308907 100 0.0281111 -1.37381 -0.0501572
-1.87784 -0.0724163 -2.59972 10 -2.09125 1.98438 2.05837 10 2.01229
2.09781 1.98737 10 -2.10059 0.019677 0.973619 -1.9144 1.94156 0.0663385
1.5041 0.0853122 1.89756 -10 1.47849 -10 -1.88661 10 2.04674 0.0998941
1.91355 -0.0615228 -1.91691 -10 -2.02705 0.0651823 2.1016 0.0380806
-1.93923 0.0770579 2.62829 0.0993508 -1.98814 -1.93405 -1.43175
0.0739289 -2.08905 0.0791035 1.25692 10 -2.06133 -0.0976014 -1.47581 -10
-2.07948 -1.97491 -1.22827 -0.0803436 -1.98453 2.05749 -1.36555
-0.0819845 -2.00783 2.09792 1.93183 1.90012 2.00088 0.0827901 -2.46831
10 -2.00536 -0.0488323 -2.66015 10 -1.92829 10 1.99522 1.90963 -2.08556
0.035228 -1.37246 2.06614 1.82821 -2.01243 -1.2947 -0.090387 -2.03256
0.0768224 -1.46944 -2.09861 2.10339 -10 1.22894 2.03087 -2.05932 10
-1.89597 -1.909 1.78418
alan 2015-03-31 14:41:43.674576 100 0.0853598 1.29053 -10 -1.92847
-0.0969795 -1.40443 -10 -2.08363 0.0849282 -1.38379 -0.0987254 -2.0946
0.0862604 2.56504 0.0479391 -1.91148 -0.078574 1.9901 -2.00295 1.90767
-0.0603079 2.60706 10 2.0883 0.0643035 2.07442 -2.06107 1.99286
0.0994668 2.6072 -0.0100181 -2.05559 0.0250058 1.23494 -0.0368261 1.9684
0.00206198 -2.0871 0.0141491 2.07869 0.0948962 1.28269 0.0743063 1.91721
0.0999062 1.3875 -2.09855 2.04559 -0.0255224 -2.66151 -10 1.97276
0.0948873 -2.5551 -10 -2.0382 0.0562314 2.56209 10 1.92939 1.95493
1.50592 0.0967445 2.01051 2.0287 -1.47036 -10 -1.9629 0.00887928
-2.46858 -2.06924 -2.0951 0.0326452 1.28041 -1.902 2.10855 0.093258
1.27432 -10 -2.07336 -0.0993881 1.50338 0.0971787 2.05764 10 1.38648 -10
-2.07846 2.0619 -1.91754 2.09746 -1.94883 10 1.40086 0.00148764 -2.10204
2.09958 1.50572 0.0764796 1.80712
alan 2015-03-31 14:41:45.670113 100 1.99038 1.33862 -0.0366539 1.82196
-0.0803481 -2.4766 -10 -1.94076 -0.0404291 -1.4677 0.0672416 -2.01883
-0.079026 -2.60114 0.0272036 -1.91046 0.0425553 1.31998 0.0978497
-1.82747 0.0996829 -1.34931 -0.0128216 -2.01298 -10 1.49011 2.09999
2.12744 -0.0691764 1.2244 -0.099818 -1.92703 2.08421 -1.49781 10 1.99197
0.010173 -2.06323 0.0560521 1.93894 10 -1.46341 0.0631703 1.97924
-0.0987476 2.48062 -10 1.91496 -0.0532784 1.46752 -1.94502 1.92071
0.0619675 -1.96381 0.0880527 1.93956 -10 1.40031 1.99663 2.11775
-1.90065 -1.13485 0.0233576 -2.07014 2.05053 1.10947 1.94223 1.94585
-0.0437987 -1.27021 0.00902123 2.04099 -0.0966582 0.934403 -1.92521
-2.02095 2.09998 1.15595 -10 1.92619 -10 1.49681 -10 1.82596 0.0152453
1.39714 -0.0358195 1.90327 -0.0473308 1.41716 -0.0995372 1.84132
0.0971676 -1.91778 -1.97241 1.90991 -0.0695922 -1.17116 -1.92475 -2.05158
...

I built this against the tip of the 3.15 branch.

Thanks. I’ve figured out what the problem was. I’ve increased CA proto minor version only (w/o completely fixing the rest of the code) - strangely I got no errors reported.

Anyway, the fixes I committed into the bzr branch nicely work. Pretty simple fix - just replace msgHeader’s count with actual getElementCount(). Fine for monitors, however
read and readNotify (and first monitor event, that calls read) need additional code in the casPV::read(const casCtx &, gdd & protoIn) method. pCAS programmer needs to implement this method.
For “read” a DBR is created first (protoIn variable) and then the value is copied into the “protoIn”. If “0” count is given by the CA client then the GDD created has no “bounds” set and this implies a scalar GDD.
Consequently “read” will always return only one element.

So, the implementation of casPV::read(const casCtx &, gdd & protoIn) needs to check if “bounds” exists and create one if necessary (getBounds() == 0 && element count > 1):

if (!protoIn.getBounds() && this->info.getElementCount() > 1)
{
    // convert to atomic
    gddBounds bds;
    bds.setSize ( this->info.getElementCount() );
    bds.setFirst ( 0u );
    protoIn.setDimension ( 1u, & bds );
}

This check cannot be done in casStrmClient.cc since only the casPV implementation knows that the value actually is. 
I think this is acceptable design requirement: if “bounds” is not provided then casPV::read implementation needs to set one.
(Before it was:  if “bounds” is not provided then this implies scalar GDD.)

Matej



HTH,

- Andrew

--
Light thinks it travels faster than anything but it is wrong.
No matter how fast light travels, it finds the darkness has
always got there first, and is waiting for it.
   -- Terry Pratchett, Reaper Man

References:
Re: variable-length-pCAS task Andrew Johnson
Re: variable-length-pCAS task Matej Sekoranja
Re: variable-length-pCAS task Andrew Johnson
Navigate by Date:
Prev: Build failed in Jenkins: epics-base-3.16-win64s #12 APS Jenkins
Next: Small arrays in rsrv Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <2015>  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: variable-length-pCAS task Andrew Johnson
Next: Small arrays in rsrv Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <2015>  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·