Experimental Physics and
Industrial Control System

"Pearson, Matthew R. via Core-talk" <[email protected]> · Wed, 16 Jan 2019 16:48:12 +0000

Hi,

The SNS ADnED application monitors this structure:

structure
  time_t  timeStamp
  NTScalar proton_charge
    double  value
  NTScalarArray time_of_flight
    uint[]  value
  NTScalarArray pixel
    uint[]  value

For the past several years I’ve been creating the channel and setting up a monitor with this request type:

"record[queueSize=100]field()”

So that the application gets the whole structure. The monitor object always exists, and I only periodically issue a start() and stop() on the monitor. If the server channel goes away then it automatically reconnects with no problem.

I’ve recently started testing using this request type:

"record[queueSize=100]field(timeStamp,proton_charge)”

This is to cater for situations where the size of the time_of_flight and pixel arrays is too large, to avoid running out of either CPU or network bandwidth. The user will be able to change the request type as long as the monitor is not started.

If I want to change the request type, then I first destroy() the monitor, and create a new one with the new request type. This seems to work perfectly. So these two timelines always seem to work:

Start server
Start client (ADnED)
Create client channel
Create monitor for request A
Start monitor
Get data and process it
Stop monitor
Start monitor
Get data and process it
Stop monitor
Start monitor
Get data and process it
Stop monitor

and:

Start server
Start client (ADnED)
Create client channel
Create monitor for request A
Start monitor
Get data and process it
Stop monitor
Destroy monitor
Create monitor for request B
Start monitor
Get data and process it
Stop monitor
Destroy monitor
Create monitor for request A
Start monitor
Get data and process it
Stop monitor

However, this timeline seems to cause a problem, where the server is restarted and I want to change the request type:

Start server
Start client (ADnED)
Create client channel
Create monitor for request A
Start monitor
Get data and process it
Stop monitor
Restart server & client channel and monitor automatically reconnect
Start monitor
Get data and process it (this works ok, as I haven’t changed the request type yet)
Stop monitor
Destroy monitor
Create monitor for request B
Start monitor
Get no data <——— this is the problem
Stop monitor
Start monitor
Get data and process it (now it works OK)
Stop monitor

So the first monitor start() after changing the request type, and after the channel has reconnected, seems to produce no data. Doing a stop() and start() again seems to fix it.

I don’t have an easy to run example to reproduce it, but here is the section of code which I use to create the channel and handle the monitor creation:

if (!p_ChannelProvider) {
    p_ChannelProvider = epics::pvAccess::getChannelProviderRegistry()->getProvider(ADNED_PV_PROVIDER);
    if (!p_ChannelProvider) {
      throw std::runtime_error("No Channel Provider.");
    }
  }

  if (!p_Channel[channel]) {
    p_Channel[channel] = (shared_ptr<epics::pvAccess::Channel>)
      (p_ChannelProvider->createChannel(pvName, p_ChannelRequester, ADNED_PV_PRIORITY));
    connectStatus = p_ChannelRequester->waitUntilConnected(ADNED_PV_TIMEOUT);
  } else {
    std::string channelName(p_Channel[channel]->getChannelName());
    if (channelName != pvName) {
      p_Channel[channel]->destroy();
      p_Channel[channel] = (shared_ptr<epics::pvAccess::Channel>)
        (p_ChannelProvider->createChannel(pvName, p_ChannelRequester, ADNED_PV_PRIORITY));
      connectStatus = p_ChannelRequester->waitUntilConnected(ADNED_PV_TIMEOUT);
      m_newMonitor[channel] = true;
    }
    connectStatus = p_Channel[channel]->isConnected();
  }

  if (!connectStatus) {
    throw std::runtime_error("Timeout connecting to PV");
  }

  if ((!p_Monitor[channel]) || (m_newMonitor[channel])) {
    if (p_Monitor[channel]) {
      printf("Monitor destroy.\n");
      p_Monitor[channel]->destroy();
    }
    const char* request = NULL;
    if (reqType == 0) {
      request = ADNED_PV_REQUEST;
    } else {
      request = ADNED_PV_REQUEST_NODATA;
    }
    printf("Request: %s\n", request);
    shared_ptr<epics::pvData::PVStructure> pvRequest = epics::pvData::CreateRequest::create()->createRequest(request);
    p_Monitor[channel] = p_Channel[channel]->createMonitor(p_MonitorRequester[channel], pvRequest);
    p_MonitorRequester[channel]->waitUntilConnected(ADNED_PV_TIMEOUT);
    m_newMonitor[channel] = false;
  }

where:

ADNED_PV_REQUEST="record[queueSize=100]field()”
ADNED_PV_REQUEST_NODATA="record[queueSize=100]field(timeStamp,proton_charge)”

So if the request type choice has changed, I issue a p_Monitor[channel]->destroy(), followed by a p_Channel[channel]->createMonitor() with the new request type string.

Then I call:

p_Monitor[channel]->start();
and
p_Monitor[channel]->stop();

to start and stop the monitor.

Any idea what could be wrong? It’s only an issue if the server has been restarted *and* I have changed the request type.

At the moment I can work around it. Changing the request type won’t be a common operation, so I can do an extra start() and stop() behind the scenes when someone wants to do this.

Cheers,
Matt

Data Acquisition and Controls Engineer
Spallation Neutron Source
Oak Ridge National Lab

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System