Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Mon, 16 Mar 2009 18:06:20 -0500

Sergey,

I think it is important to get to the bottom of this.  You have a workaround, but I don't think you should need to modify your SNL code when moving it from vxWorks to Linux.  I have definitely not needed to do that in the past, and Lewis did not find a problem on the Mac.

Can you generate a simple test case that will reproduce the problem on your end without any real device support?  Couldn't the SNL code itself be writing to the input string PV?

Mark

________________________________

From: Sergey Stepanov [mailto:[email protected]]
Sent: Mon 3/16/2009 5:37 PM
To: [email protected]
Cc: Oleg Makarov; J. Lewis Muir; EPICS tech-talk; Mark Rivers
Subject: Re: weird behaviour of SNL test program running on Soft IOC on LINUX

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 by
>>> epicsThreadSleep code change in the osdThread.c.
>>> 
>>> CA requests are not being send out  as they arise, some buffering of the
>>> requests 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 no
>>> buffering?
>>>    
>>
>> 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
>>  
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System