On Wed, 2009-03-18 at 11:42 +1100, Andrew C. Starritt wrote:
Hi all,
On a couple of IOCs, in the st.cmd file I start a number (7 or 9) SNL
programs (well actually each IOC it is the same SNL program – with
option +r
and parameterised).
Sometimes one or more random-ish instance fails to connect to
all the PVs and essentially hangs. If I seqStop and restart the
hung sequence program it runs as expected okay.
In your initialization state, you should check for PV connections:
ss turnOnOffStateSet {
state turnOnOffInitializationState {
entry{
seqLog("--> turnOnOffInitializationState\n");
p_deviceName=macValueGet("deviceName");
seqLog("deviceName=%s\n", p_deviceName);
}
when (pvConnectCount() == pvChannelCount()) {
seqLog("All channels connected\n");
delay(5);
seqLog("Reseting communication\n");
} state resetState
exit {
seqLog("<-- initializationState\n");
/* Buttons are intialized */
resetRqstdBO=0;pvPut(resetRqstdBO);
turnOffRqstdBO=0;pvPut(turnOffRqstdBO);
stndbyRqstdBO=0;pvPut(stndbyRqstdBO);
highVltgOnRqstdBO=0;pvPut(highVltgOnRqstdBO);
}
}
[....]
}
I have some questions which I hope can get help with.
The output from seqShow is:
Program Name Thread ID Thread Name SS Name
sncControl_Selection 0x32a75a0 sncControl_Selection cycle_magnets
sncControl_Selection 0x32a2d70 sncControl_Selection cycle_magnets
sncControl_Selection 0x32a4580 sncControl_Selection cycle_magnets
sncControl_Selection 0x32a5d90 sncControl_Selection cycle_magnets
sncControl_Selection 0x32aa5c0 sncControl_Selection cycle_magnets
sncControl_Selection 0x32abfe0 sncControl_Selection cycle_magnets
sncControl_Selection 0x32a8a30 sncControl_Selection cycle_magnets
Is there an easy way to tell which instance is which?
That's an interesting question...
I am not sure you can do this through seqShow.
You can do this with the log file (seqLog) but it may be a little
tedious.
Can I some how parameterise the program name, thread name or SS Name?
I tried:
program sncControl_Selection{NAME}
and
ss cycle_magnets{NAME}
in the .stt file but neither would even compile.
In stt file:
program snovaTurnOnOff ("deviceName=(null)")
In ioc startup file:
seq snovaTurnOnOff,"deviceName=${SNOVA_DEVN},logfile=
${LOG_DIR}/${SNOVA_DEVN}-snovaTurnOnOff.log,debug=1"
I also observed that the initial hang-up can is avoided by adding some
sort of delay between the seq calls, e.g.:
seq (sncControl_Selection,"NAME=SR03ID01, ILK_NAME=SR03II01")
dbl * > /tmp/xx
seq (sncControl_Selection,"NAME=SR04ID01, ILK_NAME=SR04II01")
dbl * > /tmp/xx
seq (sncControl_Selection,"NAME=SR05ID01, ILK_NAME=SR05II01")
dbl * > /tmp/xx
I have seen this on both epics base 3.14.8.2 with seq-2.0.11 on 4 year
old
redhawk Linux system and using epics base 3.14.9 with seq-2.0.11 on a
newish
CentOs 5.1 system. Any thoughts as to what is happening?
If the only solution is a small delay, is there a standard IOC shell
sleep
command I could use instead?
In iocsh Try:
help
help epicsThreadSleep
epicsThreadSleep(5)
Regards
Andy
Andrew Starritt, Principal Controls Engineer, Australian Synchrotron
800 Blackburn Road, Clayton, Victoria 3168
ph: (03) 8540 4164 , fax: (03) 8540 4200
mailto:[email protected],
http://www.synchrotron.org.au
This message and any attachments may contain proprietary or
confidential information. If you are not the intended recipient or you
received the message in error, you must not use, copy or distribute
the message. Please notify the sender immediately and destroy the
original message. Thank you.