Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <[email protected]> · Wed, 16 Jan 2019 09:03:35 -0800

What module versions/git revisions are involved?

On 1/16/19 8:48 AM, Pearson, Matthew R. via Core-talk wrote:
> 
> 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