Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
GoogleCodeExporter opened this issue Mar 14, 2015 · 5 comments
Closed

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

GoogleCodeExporter opened this issue Mar 14, 2015 · 5 comments

Comments

@GoogleCodeExporter
Copy link

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 kenneth....@gmail.com on 23 Jul 2013 at 6:46

@GoogleCodeExporter
Copy link
Author

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 xiaoqian...@gmail.com on 30 Jul 2013 at 7:36

@GoogleCodeExporter
Copy link
Author

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 kenneth....@gmail.com on 30 Jul 2013 at 2:43

@GoogleCodeExporter
Copy link
Author

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 xiaoqian...@gmail.com on 9 Oct 2013 at 2:48

@GoogleCodeExporter
Copy link
Author

Original comment by xiaoqian...@gmail.com on 9 Oct 2013 at 2:49

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

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 kenneth....@gmail.com on 17 Oct 2013 at 8:28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant