Chris,
Can you be more specific about what you are running:
- Are the motors the "motor" record from the APS BCDA group?
- What do you mean by "virtual motors". Do you mean the soft motor device support for the "motor" record?
- If so, then what software is providing the logic to connect the real motors to the virtual motors? Is the logic done purely in the database, or is there an SNL program or other code involved?
There are debugging flags you can turn on in the motor record (if it was compiled with that support). Depending how the virtual to real logic is implemented you can probably turn on some debugging there as well.
Mark
________________________________
From: [email protected] on behalf of Dropp, Christopher
Sent: Fri 6/8/2007 10:15 PM
To: [email protected]
Subject: Unexplained .db performance issues
Greetings,
We are having strange performance issues, and after spending SOME time trying to track it down (with no luck) I am hoping that discussing it here might shed some light.
We are currently working to complete the x25-beamline upgrade and I have an EPICS question.
Has anyone experienced or heard of a situation where, a db worked and then without any major software/hardware changes (known to me) it quits working?
We have a db that was originally put together by Bill Nolan to control the tripodic gonio head in the hutch that was working, quirky, but working prior the last shutdown, that now does not work.
The weird thing about it is that it loads with no complaints from the IOC and the real/virtual motor records all populate their medm screens, but it appears that two of the virtual motors are not functioning properly (i.e. VAL field = 0.0).
We took everything non-essential out of the Gonio.db database, except the three real motors and three virtual motors with no luck.
Next we tried the real motors with just one virtual motor at a time and the individual virtual motors work fine. I am clueless at this point why they will not work together.
Next we renamed the virtuals , from xtx,xty,xtz to gxtx,gxty,gxtz , and this seemed to fix the problem... however a rename to zxtx,zxty,zxtz did not fix the problem. (it was not just the name change but maybe an alphabetical ordering issue)
During the next beam alignment (with the renamed working virtuals gxtx..etc.loaded) a different virtual motor, table height (x25a:tz), no longer functioned. Removing the gonio db from the st.cmd fixed the table problem.
We next wrote a new (simplified) gonio routine from scratch to no avail.
I traced all cables, and made an accurate inventory of all motor records and assignments and found no conflicts. X25 has 46 real motors, 22 virtual motors, and uses 190 CA/CP Links in its db's. The IOC is running EPICS 13.4.6 with RTEMS 4.6.2 on a MVME-23xx .
Further experimentation revealed that removing any 3-4 virtual motors from the IOC allowed the new (simplified) gonio routine (and the original gonio routine) to work, as well as all the original records, except of course the removed set.
How would you suggest I go about troubleshooting this?
Any thoughts would be greatly appreciated.
Regards,
Chris Dropp
Christopher Dropp
Brookhaven National Laboratory
Biology Department Upton, NY 11973
Phone: 631-344-3421
Pager:7408
Fax: 631-344-2741
E-Mail: [email protected]
- References:
- Unexplained .db performance issues Dropp, Christopher
- Navigate by Date:
- Prev:
Unexplained .db performance issues Dropp, Christopher
- Next:
Re: Unexplained .db performance issues Geoff Savage
- 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:
Unexplained .db performance issues Dropp, Christopher
- Next:
Re: Unexplained .db performance issues Geoff Savage
- 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
|