EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: CAC problem between RTEMS and vxWorks
From: Benjamin Franksen <[email protected]>
To: <[email protected]>
Date: Fri, 28 Sep 2012 23:05:53 +0200
Am Freitag, 28. September 2012, 20:17:01 schrieb Wesley Moore:
> Back to try to wrap this up...  Just added a timeout loop to watch
> pvConnected() and it shows I only needed a small delay after pvAssign().

Good. However...

I strongly discourage using delays in such cases. This is unreliable, network-
related problems could cause the connect to take longer than what you
measured, even if you add a sizeable margin to account for such variations. It
is much better to break up the action into more states, i.e. after pvAssign
transition to another state and use

        when(pvConnected(var)) {
                pvPut(var);
                ... more actions...
        } state ...

If you are concerned about this covering up problems such as over-long
connection times, add a timeout clause

        when(delay(connectShouldNotTakeLongerThanThis)) {
                printf("connect timeout for variable x\n");
        } state ...

Cheers
--
Ben Franksen
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

> Haven't seen any adverse effects on the RTEMS client using this dynamic
> reconnection scheme.  By doing this, I've reduced the number of monitored
> PVs in the legacy sequencers from 8032 to 36.
>
> When rebooting the RTEMS client (running the sequencers), reconnection to
> the VxWorks server has taken as long as 4min.  I've added a stringout to
> give me the status of the connections.  VxWorks cleans up the dead sockets
> eventually, so this shouldn't be an issue during normal operations.
>
> Thanks for all the time you have put into sorting out the various issues.
> Let me know if there's anything further you want to test.
>
> Wesley
>
> ----- Original Message -----
>
> > From: "Benjamin Franksen" <[email protected]>
> > To: [email protected]
> > Sent: Thursday, September 27, 2012 3:34:10 PM
> > Subject: Re: CAC problem between RTEMS and vxWorks
> >
> > Am Dienstag, 25. September 2012, 23:10:28 schrieb Benjamin Franksen:
> > > I think we are closing in. I should have looked at the program Wes
> > > sent to
> > > me, which I did not at first. I did now and it is obvious (to me)
> > > now that
> > > it cannot work as expected. Specifically, doing
> > >
> > >         pvAssign(vidOutputStat, pvName);
> > >         ...
> > >         pvPut(vidOutputSel);
> >
> > Sorry, cut'n'paste error. I mean this part of your program (quoted
> >
> > literally):
> >                         printf("pvAssign Status:  %d\n",
> >
> >                                 pvAssign(vidOutputStat, pvName));
> >
> >                         pvGet(vwrName[ii]);
> >
> > /*                        strcpy(vidOutputStat, vwrName[ii]);*/
> >
> >                         sprintf(vidOutputStat, "%s", vwrName[ii]);
> >                         printf("pvPut Status:     %d\n",
> >
> >                                 pvPut(vidOutputStat));
> >
> > where you first
> >
> >         pvAssign(vidOutputStat, pvName)
> >
> > and then almost immediately afterwards (i.e. w/o waiting for the PV
> > to be
> > connected)
> >
> >         pvPut(vidOutputStat)
> >
> > Cheers
> > --
> > Ben Franksen
> > ()  ascii ribbon campaign - against html e-mail
> > /\  www.asciiribbon.org   - against proprietary attachments
> >
> > ________________________________
> >
> > Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
> >
> > Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher
> > Forschungszentren e.V.
> >
> > Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch,
> > stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
> > Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas
> > Frederking
> >
> > Sitz Berlin, AG Charlottenburg, 89 HRB 5583
> >
> > Postadresse:
> > Hahn-Meitner-Platz 1
> > D-14109 Berlin
> >
> > http://www.helmholtz-berlin.de

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de


References:
Re: CAC problem between RTEMS and vxWorks Wesley Moore

Navigate by Date:
Prev: RE: modbus 2.4 Mark Rivers
Next: Re: Loading modbus waveform record from acalcout record (or caput) jon
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: CAC problem between RTEMS and vxWorks Wesley Moore
Next: RE: CAC problem between RTEMS and vxWorks Hill, Jeff
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·