You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’re using your pcaspy library, i.e. the CA server lib for python, to create python-based “IOCs”.
Overall, it works great, but today we’ve run into an issue with enum-typed PVs that took some time to figure out.
We had created PVs where some of the enum strings were longer than 25 characters.
A plain IOC database will not allow this. It you create an “mbbi” record where for example the ZRST has more than 25 characters, you get an error message “can’t set XXX.ZRST to ..”.
This is based on db_access.h, where the dbr*enum types limit the enum state labels to MAX_ENUM_STRING_SIZE, which is defined as 26 (25 + ‘\0’ ?).
The portable CAS-based pcaspy does not enforce any limits, so you can in there define an enum PV with longer enumeration state labels, but the resulting PV doesn’t fully work.
You can write numeric enum values to it.
But when you ask the PV for its enumeration labels via channel access, you get the strings shortened to 25 chars.
When you then try to write such a shortened string, it doesn’t match the longer original enumeration label, and the PV doesn’t seem to receive the written data.
Not sure if the actual issue is in pcas, gdd, or the pcaspy python code.
Maybe gdd and pcas behave as if enumeration labels could be longer?
In any case, would be good for the pcaspy library would catch this.
For example, SimpleServer.createPV(prefix, pvdb) could warn if any of the ‘enum’ strings is too long.
The text was updated successfully, but these errors were encountered:
From: Kasemir, Kay
We’re using your pcaspy library, i.e. the CA server lib for python, to create python-based “IOCs”.
Overall, it works great, but today we’ve run into an issue with enum-typed PVs that took some time to figure out.
We had created PVs where some of the enum strings were longer than 25 characters.
A plain IOC database will not allow this. It you create an “mbbi” record where for example the ZRST has more than 25 characters, you get an error message “can’t set XXX.ZRST to ..”.
This is based on db_access.h, where the dbr*enum types limit the enum state labels to MAX_ENUM_STRING_SIZE, which is defined as 26 (25 + ‘\0’ ?).
The portable CAS-based pcaspy does not enforce any limits, so you can in there define an enum PV with longer enumeration state labels, but the resulting PV doesn’t fully work.
You can write numeric enum values to it.
But when you ask the PV for its enumeration labels via channel access, you get the strings shortened to 25 chars.
When you then try to write such a shortened string, it doesn’t match the longer original enumeration label, and the PV doesn’t seem to receive the written data.
Not sure if the actual issue is in pcas, gdd, or the pcaspy python code.
Maybe gdd and pcas behave as if enumeration labels could be longer?
In any case, would be good for the pcaspy library would catch this.
For example, SimpleServer.createPV(prefix, pvdb) could warn if any of the ‘enum’ strings is too long.
The text was updated successfully, but these errors were encountered: