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: weird behaviour of SNL test program running on Soft IOC on LINUX |
From: | Sergey Stepanov <[email protected]> |
To: | [email protected] |
Cc: | EPICS tech-talk <[email protected]> |
Date: | Mon, 16 Mar 2009 17:37:06 -0500 |
Pete and Mark, thanks for timely response. A tarball might be difficult to produce because in addition to the soft IOC with SNL, it would also need some DB in another IOC relating the strcmd strrsp PVs (in our case they are linked via the PMAC driver sending strcmd content to PMAC and posting response into strrsp). In any case the problem has been resolved by adding either pvFlush() or using pvPut(str_cmd, SYNC) per Lewis' suggestion (thanks Lewis!). The weird thing is that such actions are not required with the same code compiled under VxWorks: looks like the VxWorks and Linux defaults are opposite. Thanks everyone for help, -- Sergey and Oleg. Pete Jemian wrote:
Oleg:I'd like the tarball as well to test. I see Sergey's Support Request Case HD12639 on this topic.Pete J. Lewis Muir wrote:On 3/16/09 4:08 PM, Oleg Makarov wrote:Hi Mark,I tried the test with this fix. The problem is not resolved byepicsThreadSleep code change in the osdThread.c.CA requests are not being send out as they arise, some buffering of therequests occurs to make network communication more efficient. If you look at the camonitor output, it shows a 3-second period, exactly as expected.Are there way to force CA requests to go out as they arise, with nobuffering?Hi, Oleg. pvFlush() will flush the SEQ PV layer, but maybe that's not what you're asking about. You can also do a synchronous put: pvPut(str_cmd, SYNC); But still, I don't understand why str_rsp would ever contain one of the commands from str_cmd (e.g. "I522") like your output shows, unless something is messed up with what's happening in and beyond "{dev}StrCmd" and "{dev}StrRsp". Lewis