Re: variable-length-pCAS task

[Matej Sekoranja <matej.sekoranja@cosylab.com>]

On 31 Mar 2015, at 21:44, Andrew Johnson <anj@aps.anl.gov> 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