On 4/2/19 8:12 AM, Heinz Junkes via Tech-talk wrote:
> Hi folks,
>
> I am running a PvData client on RTEMS on a MVME6100 (PPC) and I see a behaviour that I can't even classify:
Then I think we should try to isolate where in the stack the problem(s) are.
There are a lot of different modules involved.
Could you try replacing your client code with something based on the following?
> #include <pv/pvData.h>
> #include <pva/client.h>
> namespace pvd = epics::pvData;
> struct Example {
> pvac::ClientProvider ctxt;
> pvac::ClientChannel chan;
>
> Example()
> :ctxt("pva")
> ,chan(ctxt.connect("CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK"))
> {}
>
> void put(long val) {
> pvd::shared_vector<double> X, Y, Z, T;
>
> for(long i=0; i<100; i++)
> X.push_back(i);
>
> for(long i=0; i<100; i++)
> Y.push_back(i+1);
>
> for(long i=0; i<100; i++)
> Z.push_back(i+2);
>
> for(long i=0; i<100; i++)
> T.push_back(i+3);
>
> chan.put()
> .set("value.column0", pvd::freeze(X))
> .set("value.column1", pvd::freeze(Y))
> .set("value.column2", pvd::freeze(Z))
> .set("value.column3", pvd::freeze(T))
> .set("counter", val)
> .exec();
>
> std::cout<<chan.get();
> }
> };
> PV-Server is a pythonIOC running on a linux - system. The PvStructure is this:
Do you see the same behavior with a P4P server. eg.
> from p4p.nt import NTTable
> from p4p.server import Server, StaticProvider
> from p4p.server.thread import SharedPV
>
> mystruct = NTTable.buildType(columns=[
> ('column0', 'ad'),
> ('column1', 'ad'),
> ('column2', 'ad'),
> ('column3', 'ai'),
> ], extra=[
> ('counter', 'l'),
> ])
>
> pv = SharedPV(initial=mystruct({}))
> @pv.put
> def handler(pv, op):
> print("Update with", op.value())
> pv.post(op.value())
> provider = StaticProvider('myexample')
> provider.add('CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK', pv)
>
> Server.forever([provider])
Test with
> pvput CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK \
> value.column0=[1,2,3] \
> value.column1=[2,3,4] \
> value.column2=[3,4,5] \
> value.column3=[4,5,6] \
> counter=1
> CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK structure
> string[] labels
> structure value
> double[] column0
> double[] column1
> double[] column2
> int[] column3
> long counter
> string descriptor
> structure timeStamp
> long secondsPastEpoch
> int nanoseconds
> int userTag
> structure alarm
> int severity
> int status
> string message
I don't see anything obviously wrong with the following, but make a few minor comments
below.
> On the RTEMS-CPU the following code is used:
>
> funktion put( long val ) // gets called put ([0…9])
> …
>
> PvaClientPutDataPtr putData = pvaClientPut->getData();
>
> PVLongPtr counterField = putData->getPVStructure()->getSubField<PVLong>("counter");
> cout << "counterField : " << counterField << "\n";
I've trained myself to use getSubFieldT() by default, unless I explicitly
plan to test for NULL. Avoids some surprises.
> //shared_vector<std::string> labels;
> PVStringArrayPtr labels = putData->getPVStructure()->getSubField<PVStringArray>("labels");
> PVStringArray::const_svector l(labels->view());
> //cout << "labels : "<< labels->view() << "\n";
>
> //for(unsigned int i = 0; i < labels->getCapacity(); i++ ) {
> // cout << "label index " << i << " : " << l[i] << "\n";
> //}
>
> shared_vector<double> newX(100);
> //PVIntArray::svector newTimeIndex;
> for(int i=0; i < 100; i++) newX[i] = 0 + i;
> shared_vector<const double> x(freeze(newX));
>
> shared_vector<double> newY(100);
> //PVIntArray::svector newTimeIndex;
> for(int i=0; i < 100; i++) newY[i] = 1 + i;
> shared_vector<const double> y(freeze(newY));
>
> shared_vector<double> newZ(100);
> //PVIntArray::svector newTimeIndex;
> for(int i=0; i < 100; i++) newZ[i] = 2 + i;
> shared_vector<const double> z(freeze(newZ));
>
> shared_vector<int32> newTimeIndex(100);
> //PVIntArray::svector newTimeIndex;
> for(int i=0; i < 100; i++) newTimeIndex[i] = 3 + i;
> shared_vector<const int32> data(freeze(newTimeIndex));
>
> //PVStructurePtr pvValue = putData->getPVStructure();
> // pvValue->dumpValue(cout);
>
> PVStructurePtr pvStructure = putData->getPVStructure()->getSubField<PVStructure>("value");
> if(!pvStructure) {
> cout << "value is not a structure\n";
> return;
> }
> PVFieldPtrArray pvFields = pvStructure->getPVFields();
>
> for(size_t ind = 0; ind < pvFields.size() ; ++ind)
> {
> PVFieldPtr pvField = pvFields[ind];
> cout << "starting field " << pvField->getFieldName() << " ... " << l[ind] << "\n";
> cout << "type " << pvField->getField()->getType() << "\n";
> if(pvField->getField()->getType()!=scalarArray) {
> cout << "fields is not a scalar array\n";
> continue;
> }
>
> PVScalarArrayPtr pvScalarArray = static_pointer_cast<PVScalarArray>(pvField);
> pvScalarArray->setLength(100);
This setLength() call isn't necessary. It does an allocation which is then
replaced by the putFrom() below.
>
> switch (ind) {
> case 0: pvScalarArray->putFrom(x); cout << " put x \n"; break;
> case 1: pvScalarArray->putFrom(y); cout << " put y \n"; break;
> case 2: pvScalarArray->putFrom(z); cout << " put z \n"; break;
> case 3: pvScalarArray->putFrom(data); cout << " put data \n"; break;
> }
>
> }
> counterField->put(val);
>
> pvaClientPut->issuePut();
>
>
> On the RTEMS CPU it self I read:
>
> …
> PvaClientPut::checkConnectState channelName CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK
> counterField : 0
> starting field column0 ... x
> type scalarArray
> put x
> starting field column1 ... y
> type scalarArray
> put y
> starting field column2 ... z
> type scalarArray
> put z
> starting field column3 ... time_index
> type scalarArray
> put data
> PvaClientPut::issuePut channelName CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK pvStructure
> structure
> string[] labels ["x", "y", "z", "time_index"]
> structure value
> double[] column0 [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99]
> double[] column1 [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100]
> double[] column2 [2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101]
> int[] column3 [3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102]
> long counter 1
> string descriptor
> structure timeStamp
> long secondsPastEpoch 0
> int nanoseconds 0
> int userTag 0
> structure alarm
> int severity 0
> int status 0
> string message
> bitSet {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16}
>
> PvaClientPut::putDone channelName CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK status.isOK true
> putDone CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK status Status [type=OK]
> counter : 2
> PvaClientPut::getData channelName CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK
> PvaClientPut::checkConnectState channelName CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK
> counterField : 1
> starting field column0 ... x
> type scalarArray
> put x
> starting field column1 ... y
> type scalarArray
> put y
> starting field column2 ... z
> type scalarArray
> put z
> starting field column3 ... time_index
> type scalarArray
> put data
> PvaClientPut::issuePut channelName CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK pvStructure
> structure
> string[] labels ["x", "y", "z", "time_index"]
> structure value
> double[] column0 [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99]
> double[] column1 [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100]
> double[] column2 [2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101]
> int[] column3 [3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102]
> long counter 2
> string descriptor
> structure timeStamp
> long secondsPastEpoch 0
> int nanoseconds 0
> int userTag 0
> structure alarm
> int severity 0
> int status 0
> string message
> bitSet {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16}
>
> …
>
> On a Darwin - host with
>
> pvmonitor -r "" CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK
>
> I read:
>
> CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK structure
> string[] labels ["x", "y", "z", "time_index"]
> structure value
> double[] column0 [0,8,16,24,32,40,48,56,64,72,80,88,96,0,0,2.122e-314,5,13,21,29,37,45,53,61,69,77,85,93,3.49671e-307,6,14,22,30,38,46,54,62,70,78,86,94,3.49671e-307,7,15,23,31,39,47,55,63,71,79,87,95,3.49671e-307,2.75859e-313,6.15379e-313,9.54898e-313,1.29442e-312,1.63394e-312,1.97346e-312,6.2132e-311,2.14309e-314,0,0,2.122e-314,2,10,18,26,34,42,50,58,66,74,82,90,98,6,14,22,30,38,46,54,62,70,78,86,94,2.02073e-321,3.60739e-313,7.00259e-313,1.03978e-312,1.3793e-312,1.71882e-312,2.05834e-312,2.43117e-315,0]
> double[] column1 [1,9,17,25,33,41,49,57,65,73,81,89,97,5,13,21,29,37,45,53,61,69,77,85,93,101,3.18299e-313,6.57819e-313,9.97338e-313,1.33686e-312,1.67638e-312,2.0159e-312,2.09612e-296,5.26795e-304,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
> double[] column2 [2,10,18,26,34,42,50,58,66,74,82,90,98,1.9098e-313,5.30499e-313,8.70018e-313,1.20954e-312,1.54906e-312,1.88858e-312,5.26795e-304,3.05017e+06,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
> int[] column3 [3,7,11,15,19,23,27,31,35,39,43,47,51,55,59,63,67,71,75,79,83,87,91,95,99,0,42691016,42691272,16195288,1414742849,1258291200,16195288,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
> long counter 1
> string descriptor
> structure timeStamp
> long secondsPastEpoch 0
> int nanoseconds 0
> int userTag 0
> structure alarm
> int severity 0
> int status 0
> string message
> CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK structure
> string[] labels ["x", "y", "z", "time_index"]
> structure value
> double[] column0 [0,8,16,24,32,40,48,56,64,72,80,88,96,1,9,17,25,33,41,49,57,65,73,81,89,97,2,10,18,26,34,42,50,58,66,74,82,90,98,6.36599e-314,4.03179e-313,7.42699e-313,1.08222e-312,1.42174e-312,1.76126e-312,2.10078e-312,5.09279e-313,1.86736e-312,0,0,9.16401e-72,5,13,21,29,37,45,53,61,69,77,85,93,1.71457e-311,9,17,25,33,41,49,57,65,73,81,89,97,1.4854e-313,4.88059e-313,8.27578e-313,1.1671e-312,1.50662e-312,1.84614e-312,4.29492e-311,1.6458e+98,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
> double[] column1 [1,9,17,25,33,41,49,57,65,73,81,89,97,2,10,18,26,34,42,50,58,66,74,82,90,98,6.36599e-314,4.03179e-313,7.42699e-313,1.08222e-312,1.42174e-312,1.76126e-312,2.10078e-312,5.09279e-313,1.86736e-312,0,0,9.16401e-72,5,13,21,29,37,45,53,61,69,77,85,93,1.71457e-311,9,17,25,33,41,49,57,65,73,81,89,97,1.4854e-313,4.88059e-313,8.27578e-313,1.1671e-312,1.50662e-312,1.84614e-312,4.29492e-311,1.6458e+98,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
> double[] column2 [2,10,18,26,34,42,50,58,66,74,82,90,98,6.36599e-314,4.03179e-313,7.42699e-313,1.08222e-312,1.42174e-312,1.76126e-312,2.10078e-312,5.09279e-313,1.86736e-312,0,0,9.16401e-72,5,13,21,29,37,45,53,61,69,77,85,93,1.71457e-311,9,17,25,33,41,49,57,65,73,81,89,97,1.4854e-313,4.88059e-313,8.27578e-313,1.1671e-312,1.50662e-312,1.84614e-312,4.29492e-311,1.6458e+98,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
> int[] column3 [3,7,11,15,19,23,27,31,35,39,43,47,51,55,59,63,67,71,75,79,83,87,91,95,99,2904,1,42698272,24,0,5205556,1095189855,88,0,0,0,0,0,0,0,0,0,2,0,825241856,0,42693840,1074266112,1075052544,1075576832,1075970048,1076232192,1076494336,1076756480,1076953088,1077084160,1077215232,1077346304,1077477376,1077608448,1077739520,1077870592,1077968896,1078034432,1078099968,1078165504,1078231040,1078296576,1078362112,1078427648,1078493184,1078558720,1078624256,1078689792,1078755328,1078820864,1078886400,1078951936,1079001088,1079033856,1079066624,1079099392,1079132160,1079164928,1079197696,1079230464,1079263232,1079296000,1079328768,1079361536,1079394304,1079427072,1079459840,1079492608,1079525376,1079558144,808,1074266112,1075052544,1075576832]
> long counter 2
> string descriptor
> structure timeStamp
> long secondsPastEpoch 0
> int nanoseconds 0
> int userTag 0
> structure alarm
> int severity 0
> int status 0
> string message
>
>
> Only every 4th element is included in the int array (ind == 3) and every 8th element in the double arrays (ind == 0-2)?
>
>
> If I run the client code on the Darwin host, everything looks fine. All 100 elements are taken over in the arrays on the server.
>
>
> CRYVISIL:STM:FASTSCAN:IMAGE_CHUNK structure
> string[] labels ["x", "y", "z", "time_index"]
> structure value
> double[] column0 [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99]
> double[] column1 [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100]
> double[] column2 [2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101]
> int[] column3 [3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102]
> long counter 9
> string descriptor
> structure timeStamp
> long secondsPastEpoch 0
> int nanoseconds 0
> int userTag 0
> structure alarm
> int severity 0
> int status 0
> string message
>
> Does anyone have any idea what's happening?
> I guess of course something with type-len (int ==4, double ==8).
>
> Danke, Heinz
>
- Replies:
- Re: PvData , PvAccess, Confusion with different hardware architectures Heinz Junkes via Tech-talk
- Re: PvData , PvAccess, Confusion with different hardware architectures Michael Davidsaver via Tech-talk
- References:
- PvData , PvAccess, Confusion with different hardware architectures Heinz Junkes via Tech-talk
- Navigate by Date:
- Prev:
Re: EPICS Base 3.15 release notes epicsVersion.h macro snippet issues J. Lewis Muir via Tech-talk
- Next:
Splitting the motor module Peterson, Kevin M. via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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:
PvData , PvAccess, Confusion with different hardware architectures Heinz Junkes via Tech-talk
- Next:
Re: PvData , PvAccess, Confusion with different hardware architectures Heinz Junkes via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·