Additional types (short, ushort, ulong, long, uchar)

[GoogleCodeExporter]

Additional types from the ait enum should be accessible in pcaspy. I've been 
patching it on my end as follows:

from pcaspy import driver as pcaspy_driver
pcaspy_driver._ait_d['short'] = cas.aitEnumInt16
pcaspy_driver._ait_d['ushort'] = cas.aitEnumUint16
pcaspy_driver._ait_d['ulong'] = cas.aitEnumUint32
pcaspy_driver._ait_d['long'] = cas.aitEnumInt32
pcaspy_driver._ait_d['uchar'] = cas.aitEnumUint8

Original issue reported on code.google.com by [email protected] on 23 Jul 2013 at 6:46

[GoogleCodeExporter]

This is my reason not having these types in the beginning. Python only has 
float/int/string as basic types. There is little meaning, to me,  to support 
those different width integers. Moreover channel access protocol makes no 
difference between signed and unsigned numbers. 

I am not against to support more types but I want to be careful not to cause 
confusion to Python programmers.

Do you have any use cases when these are necessary? 

Original comment by [email protected] on 30 Jul 2013 at 7:36

[GoogleCodeExporter]

This is coming from a case where I am mimicking a record and attempting to keep 
all of the types the same. For example, a motor's "motor is moving" field 
.MOVN, is a short:

$ cainfo IOC:m1.MOVN
IOC:m1.MOVN
    State:            connected
    Host:             10.0.0.2:5064
    Access:           read, no write
    Native data type: DBF_SHORT
    Request type:     DBR_SHORT
    Element count:    1

I can understand your reasoning from the Python user's standpoint. I'm 
perfectly OK with modifying it on my end for my purposes.

Original comment by [email protected] on 30 Jul 2013 at 2:43

[GoogleCodeExporter]

For the completeness I have added 'short' type as cas.aitEnumInt16 in commit 
54baa32625b6.
Now the data type supported are DBF_CHAR DBF_SHORT DBF_ENUM, DBF_LONG, 
DBF_DOUBLE.

Unsigned numbers are deliberately left out because channel access makes no 
difference of it.

Original comment by [email protected] on 9 Oct 2013 at 2:48

[GoogleCodeExporter]

Original comment by [email protected] on 9 Oct 2013 at 2:49

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for updating this. I found one small related issue so far:

_checkAlarm() doesn't check for the short, so it returns None, subsequently 
nameOf crashes since None isn't in the list of severities (not that it should 
be, either):

113         logging.getLogger('pcaspy.Driver.setParam')\                        

114             .debug('%s: %s %s %s', reason, value, Alarm.nameOf(alarm), 
Severity.nameOf(severity))

Original comment by [email protected] on 17 Oct 2013 at 8:28