Hi Jamie,
On 03/02/2015 04:09 PM, Jameson Graef Rollins 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
DBR type=18 is DBR_TIME_CHAR, which is the data type MEDM will request
for a channel with native type DBF_CHAR. The cas app type number 16 is
gddAppType_value.
> On the MEDM side:
>
> medmUpdateChannelCb: Bad status [400] for T1:TEST-SYS_STR: No
> reasonable data conversion between client and server types
That message string is the error string for ECA_NOCONVERT, which
matches the server's error.
> 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$
The server error message comes from the cas code that handles monitors
rather than gets, so you won't be able to replicate it exactly using
caget, and camonitor doesn't let you select the data type to request.
> 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.
Very unlikely to be anything related to the alarm status/severity,
those are just data fields to the CA client and server code and are
not used for error reporting or handling.
> 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?
I have no experience with pcaspy and not much with writing cas tools
so I can't really help there, but these errors appear to be consistent
with MEDM making requests that the server can't seem to handle.
Whether this is a pcaspy or a cas problem I'm not sure though, any cas
users out there want to chime in? Does anyone else implement long
strings in a cas tool?
- Andrew
--
Doctorow's Law: Anytime someone puts a lock on something you own,
against your wishes, and doesn't give you the key, they're
not doing it for your benefit.
- Replies:
- Re: "No conversion between src & dest" warning with pcaspy Kasemir, Kay
- References:
- "No conversion between src & dest" warning with pcaspy Jameson Graef Rollins
- Navigate by Date:
- Prev:
Re: "No conversion between src & dest" warning with pcaspy Wang Xiaoqiang (PSI)
- Next:
Re: asyn R4.26 Benjamin Franksen
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: "No conversion between src & dest" warning with pcaspy Wang Xiaoqiang (PSI)
- Next:
Re: "No conversion between src & dest" warning with pcaspy Kasemir, Kay
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|