Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Mon, 10 Oct 2016 02:20:58 +0000

Hi Michael,

Great thanks it's working now.  This is the pvaDriver that Bruno Martins wrote.  I've just added some features:

- Implements ADAcquire, ADImageMode, ADNumImages.  So acquisition can be started and stopped, and can be
  done in Single, Multiple, or Continuous mode

- New PvName PV allows changing the EPICS V4 PV name at runtime, so it can switch between receiving arrays
  from different servers (that's what your help was for)

- Added medm screens for pvaDriver and NDPluginPVA

- Implements autosave

The new version is in the master branch of ADCore and ADExample on github.

Mark

________________________________________
From: Michael Davidsaver [[email protected]]
Sent: Sunday, October 09, 2016 5:49 PM
To: Mark Rivers; EPICS Tech-Talk
Subject: Re: EPICS V4 question

On 10/09/2016 06:16 PM, Mark Rivers wrote:
> Hi Michael,
>
> Thanks for the quick response.
>
> I have another newbie question.
>
> My class has
>
> private:
>     std::string m_pvName;
>     std::string m_request;
>     short m_priority;
>     ChannelProviderPtr m_provider;
>     ChannelPtr m_channel;
>
> How do I initialize m_channel in my constructor so that I know that
>
>   m_channel = m_provider->createChannel(m_pvName, m_thisPtr, m_priority);
>
> has not yet been call, so I should not call m_channel->destroy()?  If this were a normal pointer I would initialize it to 0 and test that, but that does not work for a ChannelPtr.
>
> If I unconditionally call m->channel->destroy() before m_channel has been created the first time I get an access violation.

You should do just what you would with a plain pointer in the ctor.  The
difference is that instead of initializing with 'm_channel(0)', just do
'm_channel()'.  The default ctor for shared_ptr initializes to NULL.

then for cleanup:

> if(m->channel) m->channel->destroy()

An important note is that shared_ptr does *not* protect you from races
when changing the pointer.  So what I would do is the following with a
mutex which guards 'm_channel', but isn't held for destory() or the
dtor, which avoid even the possibility of lock order bugs.

> {
>   ...
>   ChannelPtr temp; // aka. shared_ptr<Channel>
>   {
>      Guard G(somemutex); // aka. epicsGuard<epicsMutex>
>      temp.swap(m_channel);
>   }
>   if(temp) temp->destory();
>   ...
>   // temp goes out of scope and Channel dtor runs
> }

>
> Thanks,
> Mark
>
> ________________________________________
> From: Michael Davidsaver [[email protected]]
> Sent: Sunday, October 09, 2016 1:37 PM
> To: Mark Rivers; EPICS Tech-Talk
> Subject: Re: EPICS V4 question
>
> Mark,
>
> First, the *Requester classes are somewhat "transient", so it's probably
> not a good idea to combine this with ADDriver, which isn't.  You may
> also get into trouble should you wish to have one ADDriver associated
> with more than on PVA channel (as you have inadvertently done).
>
> Disconnecting is done with Channel::destory(), not the ChannelRequester.
>  For various annoying reasons it is *not* sufficient to let a connected
> Channel be destroyed (as in c++ destructor).  Calling Channel::destory()
> is mandatory.
>
> You may (or not) find the following test code useful in understanding
> the Channel/Monitor lifecycle.
>
> https://github.com/mdavidsaver/pva2pva/blob/master/testApp/testtest.cpp
>
> Michael
>
>
> On 10/09/2016 01:24 PM, Mark Rivers wrote:
>> I have some EPICS V4 client code that basically does the following:
>>
>>
>>
>> class epicsShareClass pvaDriver : public ADDriver,
>>
>>         public virtual epics::pvAccess::ChannelRequester,
>>
>>         public virtual epics::pvData::MonitorRequester
>>
>>
>>
>> …
>>
>>
>>
>>     try
>>
>>     {
>>
>>         ClientFactory::start();
>>
>>         m_provider = getChannelProviderRegistry()->getProvider("pva");
>>
>>         m_channel = m_provider->createChannel(m_pvName, m_thisPtr,
>> m_priority);
>>
>>         m_pvRequest = CreateRequest::create()->createRequest(m_request);
>>
>>         m_monitor = m_channel->createMonitor(m_thisPtr, m_pvRequest);
>>
>>     }
>>
>>     catch (exception &ex)
>>
>>     {
>>
>> …
>>
>>     }
>>
>>
>>
>> The monitorConnect() and monitorEvent() methods are being called as
>> expected, and everything is working.
>>
>>
>>
>> Now I want to extend the code to allow the current channel to be
>> disconnected, and call m_provider->createChannel() to a different
>> channel.  What do I need to do for this?  I found that if I just call
>> m_provider->createChannel with a different p_pvName it does not throw an
>> exception, but it appears to simply stay connected to the existing channel.
>>
>>
>>
>> Thanks,
>>
>> Mark
>>
>>
>>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System