Experimental Physics and
Industrial Control System

Regarding the question about having different thread names I use a SNL
program that does not take arguments but I do run multiple instances on
vxWorks with different thread names.

I have in my st.cmd file:
seq &EPS_Faults_V31, "name=FEEPS_Faults_BM, sector=01, beamline=BM"
seq &EPS_Faults_V31, "name=FEEPS_Faults_ID, sector=01, beamline=ID"

When I look on the IOC console:
seqShow
Program Name     Task ID    Task Name        SS Name

EPS_Faults_V31   24390880   FEEPS_Faults_BM  faults

EPS_Faults_V31   23972184   FEEPS_Faults_ID  faults

Marty

Emmanuel Mayssat wrote:

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.

References:

Starting multiple SNL programs Andrew C. Starritt

Re: Starting multiple SNL programs Emmanuel Mayssat

Navigate by Date:

Prev: Alarm Limits Pierrick Hanlet

Next: RE: Alarm Limits Owens, PH (Peter)

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: Starting multiple SNL programs Emmanuel Mayssat

Next: Building Epics 3.14.10 on Linux Sue Witherspoon

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