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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: garbage in zero length arrays |
From: | "Hill, Jeff" <[email protected]> |
To: | Mezger Anton Christian <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Fri, 17 Jan 2014 17:07:50 +0000 |
Hi Anton, Thanks for taking some time to report this issue.
I will emulate the typical computer support personal and respond to a question with an escalating number of questions
:-). Ø
The Array has zero length (NORD=0) after boot. Then I get garbage as first
Ø
character while the number of elements is 128 in my case and this number
Ø
was requested. When specifying 0 at request I get
args.count=0 as it should Ø
with 3.14.12. o Is this issue repeatable when testing with a different client side code other than
caget? If so, which ca client code is in use? o Is this issue repeatable when testing with multiple record types and or multiple device support modules? o You mention that the issue is related to NORD being zero just after booting the IOC. Does the problem persist
or does it happen only once; if it doesn’t persist then what is the action that causes an improvement? For example, I could imagine some different scenarios where the behavior might improve the second time that a CA client attaches, in a particular client’s
second subscription update, the first time that the record processes, or the second time that the record processes. o In what versions of EPICS does it fail, and in
what versions does it work correctly; is it working correctly in 3.14.12? Thanks for your help. best regards, Jeff From: Mezger
Anton Christian [mailto:[email protected]] Hi Jeff, The Array has zero length (NORD=0) after boot. Then I get garbage as first character while the number of elements is 128 in my case and this number was requested. When specifying 0 at request I get args.count=0
as it should with 3.14.12. Regards Anton __________________________________________ From: Hill, Jeff [mailto:[email protected]]
Anton, As memory serves, a request for a zero length subscription will probably be rejected by an old version of the CA server.
Jeff From: Mezger Anton Christian [mailto:[email protected]]
Thank you Jeff, this confirms that I can set 0 in the
ca_add_event_array. In any case of epics combinations (ioc, client) that would work properly at monitor receive. Thanks and best regards Anton __________________________________________ From: Hill, Jeff [mailto:[email protected]]
Ø
My question is: when specifying 0, how does that behave in older epics versions and channel
Ø
access gateways. Does it use then the maximum amount of elements ? When a channel connects the maximum number of elements is supplied by the server as a channel attribute. In newer versions of EPICS the current number of elements is returned with each subscription update. In older versions the maximum
number of elements was always returned; when the current number of elements was less than the maximum number then any additional elements at the end were zero padded. Jeff From:
[email protected] [mailto:[email protected]]
On Behalf Of Mezger Anton Christian Hi all, When monitoring a non initialized char array with ca_add_event_array, one gets most of the time in the first element of the array. This only when the request uses ca_element_count(chid) which is non zero. When using the dynamic behavior by specifiying 0 elements, the received args.count correspond to the actual size of the array, including zero when not initialized. My question is: when specifying 0, how does that behave in older epics versions and channel access gateways. Does it use then the maximum amount of elements ? Anton __________________________________________ |