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
<2012>
2013
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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|