testDatabase

Introduction

This contains database and client code to test some esoteric features for providers pva and ca connecting to DBRecords in an EPICS IOC.

At present there are no regression tests.

testDatabaseCPP is available at: testDatabaseCPP

DBRecordTypes

Reason for the test

DBRecordTypes provides a test of client code that accesses DBRecords in an ioc database. The test database has record types for every DBF type supported for DBRecords
For waveform records, i. e. array records epics-base has support for all the types. For scalar records support is available as follows:

DBF_CHAR      //implemented by this test
DBF_SHORT     //implemented by this test
DBF_LONG      //implemented by epics-base
DBF_INT64     //implemented by this test
DBF_FLOAT     //implemented by epics-base
DBF_DOUBLE    //implemented by epics-base
DBF_STRING    //implemented by epics-base
DBF_UCHAR     //implemented by this test
DBF_USHORT    //implemented by this test
DBF_ULONG     //implemented by this test
DBF_UINT64    //implemented by this test

In addition the test provides tests for a record named DBRlongstring. This is a record that can be accessed by a client as either a DBF_STRING or as a DBF_CHAR array that is actually an array of ascii characters that the client can convert to a string. If the client just specifies the channel name then a DBF_STRING is the type seen by the client and is subject to the MAX_STRING_SIZE if the client is using the channel access network protocal. If the client appends VAL$ to the channel name then an array of ascii characters is returned.

Issues found by the tests

The following issues are all related to client provider pva connecting to a DBRecord via the server side provider qsrv.

DBF_INT64 and DBF_UINT64

Both of the following fail to connect:

mrk> pvget -p pva DBRint64
Timeout
DBRint64 
mrk> pvget -p pva DBRuint64
Timeout
DBRuint64

lso record type

Consider the following:

mrk> pvput -p ca -r value[pvtype=pvString] DBRlongstring.VAL$ abc
Old :  
New : abc 
mrk> pvget -p ca -r value[pvtype=pvString] DBRlongstring.VAL$
DBRlongstring.VAL$ abc 
mrk> pvget -p pva DBRlongstring.VAL$
DBRlongstring.VAL$ 2018-11-26 08:15:52.895  [97,98,99,0]
mrk> pvget -p pva DBRlongstring
DBRlongstring 2018-11-26 08:15:52.895  abc

I maintain that provider pva should return the value as a string when VAL$ is appended to the channel name.

Running the test

To run the test start the database via:

mrk> pwd
/home/epicsv4/masterCPP/testDatabaseCPP/iocBoot/DBRecordTypes
mrk> ../../bin/linux-x86_64/recordTypes st.cmd

Then run the client:

mrk> pwd
/home/epicsv4/masterCPP/testDatabaseCPP
mrk> bin/linux-x86_64/DBRrecordTypesClient -p pva
mrk> diff temp.txt pva.txt

The only differences should be timeStamp differences. i. e. differences in secondsPastEpoch and nanoseconds.

Then run:

mrk> pwd
/home/epicsv4/masterCPP/testDatabaseCPP
mrk> bin/linux-x86_64/DBRrecordTypesClient -p ca
mrk> diff temp.txt ca.txt

There should be no differences.

caLink

Reason for the test

This test demonstrates that the ca provider and be used in the same address space as as the channel access API. The test database has DBRecords with CP links and PVRecords that use the ca provider to link to DBRecords

Running the test

To run the test start the database via:

mrk> pwd
/home/epicsv4/masterCPP/testDatabaseCPP/iocBoot/caLink
mrk> ../../bin/linux-x86_64/caLink st.cmd

In another window issue the command:

mrk> pvget -m DBRinLink DBRdouble DBRoutLink PVRGetLink PVRMonitorLink PVRPutLink

In yet another window issue the commands:

mrk> pvput DBRoutLink 1
mrk> pvput PVRPutLink 2

In the monitor window you will see:

mrk> pvget -m DBRinLink DBRdouble DBRoutLink PVRGetLink PVRMonitorLink PVRPutLink
DBRinLink      <undefined>             0 INVALID DRIVER UDF 
DBRdouble      <undefined>              0 INVALID DRIVER UDF 
DBRoutLink     <undefined>              0 INVALID DRIVER UDF 
PVRGetLink     2018-11-21 09:48:43.495  0 INVALID CLIENT disconnected 
PVRMonitorLink 2018-11-21 09:48:43.496  0 INVALID UNDEFINED UDF 
PVRPutLink     2018-11-21 09:48:43.495  0 INVALID disconnected 
DBRoutLink     2018-11-21 09:49:11.688  1 
DBRdouble      2018-11-21 09:49:11.688  1 
PVRMonitorLink 2018-11-21 09:49:11.689  1 
DBRdouble      2018-11-21 09:49:17.701  2 
PVRPutLink     2018-11-21 09:49:17.701  2 
PVRMonitorLink 2018-11-21 09:49:17.701  2

fastcalc

Reason for the test

This is a test for accessing a record defined as:

record(calc, "$(name)") {
    field(INPA, "$(name).VAL CP")
    field(CALC,  "(A<B)?(A+C):D")
    field(INPB, "09999999")
    field(INPC, "1")
    field(INPD, "0")
    ...
}

This record has a channel access link to itself. Each time it processes a request to process itself is issued. Thus it processes at the maximum rate possible.

The propose of the test is to see if a client using channel provider pva or ca can properly handle connections to the channel. The reason for the test is that pvAccessCPP has an example that failed on the following:

mrk> pwd
/home/epicsv4/masterCPP/pvAccessCPP/examples
mrk> O.linux-x86_64/monitorme -p ca FAST1

It was not possible to stop the test with ctl/c. Now it is. In addition other tests were created to measure rates and to test get and put.

Running the test

To run the test start the database via:

mrk> pwd
/home/epicsv4/masterCPP/testDatabaseCPP/iocBoot/fastcalc
mrk> ../../bin/linux-x86_64/recordTypes st.fast1

Then you can run any of the following:

mrk> pwd
/home/epicsv4/masterCPP/testDatabaseCPP
mrk> bin/linux-x86_64/monitorrate -help
 -h -p provider -r request - d debug channelNames 
default
-p pva -r value,alarm,timeStamp -d false PVRdouble
mrk> bin/linux-x86_64/monitormerate -help
Usage: bin/linux-x86_64/monitormerate [-p <provider>] [-w <timeout>] [-r <request>] [-R] <pvname> ...
mrk> bin/linux-x86_64/getputmonitorrate -help
 -h -p provider -r request - d debug -s sleepTime -o showGetPut channelNames 
default
-p pva -r value,alarm,timeStamp -d false -s 0 -o false -b true PVRdouble
mrk> bin/linux-x86_64/monitor -help
 -h -p provider -r request - d debug -v printValue -s 0.0 channelNames 
default
-p pva -r value,alarm,timeStamp -d false -v true -v 0 PVRdouble
mrk> bin/linux-x86_64/monitorme -help
Usage: bin/linux-x86_64/monitorme [-p <provider>] [-w <timeout>] [-r <request>]  [-v <printValue>]  [-R] <pvname> ...
mrk>

For example:

mrk> bin/linux-x86_64/monitorrate -p ca FAST1
mrk> bin/linux-x86_64/monitorrate -p ca FAST1
provider ca channelName PVRdouble request value,alarm,timeStamp debug false
_____monitorrate starting__

total events/second 43163

total events/second 43653.1

total events/second 42939.7

A report is given every time enter is pressed.

manyChannels

Reason for the test

Test providers pva and ca connecting to many channels. The test database consists of 50,000 records.

Running the test

To run the test start the database via:

mrk> pwd
/home/epicsv4/masterCPP/testDatabaseCPP/iocBoot/manyChannels
mrk> ../../bin/linux-x86_64/recordTypes st.cmd

Then you can run any of the following:

mrk> bin/linux-x86_64/timeManyChannel -help
-p provider -n nchannels  
default
-p pva -n 50000
mrk> bin/linux-x86_64/timeManyChannelGet -help
-p provider -n nchannels  
default
-p pva -n 50000
mrk> bin/linux-x86_64/timeManyChannelPut -help
-p provider -n nchannels  
default
-p pva -n 50000
mrk> bin/linux-x86_64/timeManyChannelMonitor -help
-p provider -n nchannels  
default
-p pva -n 50000
mrk> bin/linux-x86_64/timeManyChannelGPM -help
-p provider -n nchannels  
default

For example:

mrk> bin/linux-x86_64/timeManyChannel -p pva

testDatabase

26-November-2018

Table of Contents

Introduction

DBRecordTypes

Reason for the test

Issues found by the tests

DBF_INT64 and DBF_UINT64

lso record type

Running the test

caLink

Reason for the test

Running the test

fastcalc

Reason for the test

Running the test

manyChannels

Reason for the test

Running the test