Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System