Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Fri, 30 Jan 2009 14:26:52 -0600

Andrew,

> I'm not sure how proactive we 
> need to be about looking for other places that need fixing though,
presumably 
> Mark and his users will uncover any other major issues while working
with the 
> Prosilica driver and we can fix them as they come up.

One problem is that the IOC application most users will probably use
with the Prosilica only controls the Prosilica cameras, i.e. there are
no serial or TCP devices also being used.  So problems may not show up
running that application.

> Mark, what else do you know about that we need to change?  If I read
your last 
> message on the subject properly we don't have to stop readline from 
> installing signal handlers, which is how I would much prefer to keep
it.

1) I did have to disable the readline signal handlers (or readline would
not behave correctly).  I did this in my driver.  One possibility would
be to make rl_catch_signal a variable accessible from iocsh with
epicsExportAddress.  That way it could be left at its default value of
1, but provide a way to change it easily in a startup script.

2) I had to remove calls to install the EPICS SIGALRM handler in
ca/cac.cpp and rsrv/caservertask.c (or the IOC would crash).

Problem 2 is supposed to be fixed with a new version of the Prosilica
driver.  But much to their surprise the new version of the driver does
not even find the cameras at all, even when using only their example
applications!  Of course this does not happen to them at the factory, so
I spent most of yesterday afternoon installing and running wireshark,
and sending them the packet traffic.  So 2) may not be necessary, it is
too early to tell.  I have not heard back from them today.

Mark

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]] 
Sent: Friday, January 30, 2009 2:10 PM
To: Mark Rivers
Cc: Eric Norum; Core-Talk
Subject: Re: EPICS and interruptable system calls

On Friday 30 January 2009 13:14:27 Mark Rivers wrote:
> But since the POSIX timer API is out there in the real world, and
> manufacturers are now writing their device libraries using it, do we
> have any choice but to be compatible with it?

I think that's probably the real kicker; we can't really bury our heads
in the 
sand about this if we want to remain relevent.  I'm not sure how
proactive we 
need to be about looking for other places that need fixing though,
presumably 
Mark and his users will uncover any other major issues while working
with the 
Prosilica driver and we can fix them as they come up.

I will commit the necessary change to epicsThreadSleep() in os/posix.
Mark, 
what else do you know about that we need to change?  If I read your last

message on the subject properly we don't have to stop readline from 
installing signal handlers, which is how I would much prefer to keep it.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System