Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 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
<== Date ==> <== Thread ==>

Subject: Re: C++ multi threaded application.
From: Andrew Johnson <anj@aps.anl.gov>
To: Giacomo S. <giacomo.strangolino@elettra.eu>, <tech-talk@aps.anl.gov>
Date: Wed, 6 Sep 2017 10:32:54 -0500
Hi,

On 09/06/2017 03:02 AM, Giacomo S. wrote:
> I've had a look in the source code but I got lost between what is called
> new/old db/channel and so on...
> 
> // example where I got lost:
> 
> // #define dbChannelExportCAType(pChan)
> (dbDBRnewToDBRold[dbChannelExportType(pChan)])

Yeah, since all you're trying to do is write a CA client don't try to
understand the internals of the IOC, which has 2 different and totally
incompatible sets of DBF_* and DBR_* type codes — CA still uses an older
set which was replaced inside the IOC more than 20 years ago, but the
maintainers at the time couldn't replace the CA client set without
breaking too much client software which was already in use. Suffice it
to say that dbAccess.h and db_access.h use 2 different sets of data type
codes, and CA clients always use the latter (the macro you found above
is performing a translation between the new and old type codes, so no
wonder it confused you).

> So, probably it's safe to remove dbf_type_to_DBR_TIME, but in that case
> what's the difference between
> dbR type and dbF type?

DBF_* types are field types, i.e. the IOC's storage for the value data,
whereas DBR_* types are request types, and can have additional metadata
such as the units string, alarms etc. All the basic DBF_* macros are
identical to the similarly-named DBR_* macro so you can use either to
data type requests.

>> One issue that you do have to be careful of though is if an IOC gets
>> rebooted with a modified database so the data type of a channel you were
>> subscribed to changes between the connection going down and coming back
>> up. In this case CA subscriptions will reconnect using the type in their
>> original subscription request, which might now be different to the
>> native type of the channel. The client code has to be aware of that and
>> use the type information from the data update callback.
> 
> If the data type on the IOC (server) has changed, shouldn't this change
> reflect into the client?
> I mean, if on the server (IOC) side a double type becomes an integer,
> the client should change, right?

That depends, not always. If I'm writing a client which is processing
temperatures say, I might always want the values of my channels as
doubles, irrespective of what data type the IOC serves for those
channels (some IOCs might have very crude thermocouples which provide
temperatures as integers, while others may be more accurate and serve
them as doubles). For this client it's simpler to subscribe to all the
temperature channels as a double so the data will always arrive in the
type I need for processing.

Problems might occur if any of the channels gave a string that can't be
converted into a number (Freezing/Cold/Cool/Tepid/Warn/Hot/Boiling) but
my client wouldn't be able to handle that either. Maybe at connection
time it would just log an error and ignore any channels whose native
types aren't numeric.

HTH,

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

References:
C++ multi threaded application. Giacomo S.
Re: C++ multi threaded application. Andrew Johnson
Re: C++ multi threaded application. Giacomo S.
Re: C++ multi threaded application. Giacomo S.
Re: C++ multi threaded application. Andrew Johnson
Re: C++ multi threaded application. Giacomo S.

Navigate by Date:
Prev: RE: C++ multi threaded application. Mark Rivers
Next: Re: C++ multi threaded application. Michael Davidsaver
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
Navigate by Thread:
Prev: Re: C++ multi threaded application. Michael Davidsaver
Next: Re: C++ multi threaded application. Giacomo S.
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
ANJ, 07 Sep 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·