Did you set the “Format" to “string" in the MEDM widget property?
On 02 Mar 2015, at 23:09, Jameson Graef Rollins <[email protected]> wrote:
Hi, folks. We have applications using pcaspy (v0.4.1) to serve up
character array records for long strings. Whenever we use MEDM to
connect to one of these character array channels, we see the following
error messages:
On the server side:
filename="../../../../src/cas/generic/casStrmClient.cc" line number=895
No conversion between src & dest types no conversion between event app type=16 and DBR type=18 Element count=60
On the MEDM side:
medmUpdateChannelCb: Bad status [400] for T1:TEST-SYS_STR: No reasonable data conversion between client and server types
Using caget I don't see any particular issue with the channel (other
than maybe the "Status: UDF" and "Severity: INVALID"):
servo:~/ligo/src/guardian [master*] 0$ caget -d DBR_CTRL_CHAR T1:TEST-SYS_STR
T1:TEST-SYS_STR
Native data type: DBF_CHAR
Request type: DBR_CTRL_CHAR
Element count: 60
Value: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Status: UDF
Severity: INVALID
Units:
Lo disp limit: 0
Hi disp limit: 0
Lo alarm limit: 0
Lo warn limit: 0
Hi warn limit: 0
Hi alarm limit: 0
Lo ctrl limit: 0
Hi ctrl limit: 0
servo:~ 0$
After the channel has been updated at all, even if it's been set back to
an empty array, new screens do not produce this error. So it appears
there's something peculiar about how pcaspy is initializing char arrays
that is problematic. If I configure the server to set the
alarm/severity so that they both show up as NO_ALARM the problem
persists, so I don't think it has to do with that.
Anyone know what might be causing this, and how to avoid it? Is there a
way to get a full dump of the channel record that might help illuminate
what it is that's different between the cases when it the error is throw
and when it's not?
jamie.
|
