I realize I forgot an argument to seqChanShow. It should be
seqChanShow seqProg -
where seqProg is the name of your seq program.
This assumes you are using the iocsh shell. With the vxWorks shell the syntax is different.
Mark
________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Mark Rivers [rivers@cars.uchicago.edu]
Sent: Tuesday, January 22, 2013 4:08 PM
To: 'Paul Nord'; Jiro Fujita
Cc: EPICS tech talk
Subject: RE: sequencer programs in an IOC
Do “seqChanShow –“ to see only the disconnect channels (notes the minus sign after seqChanShow).
Mark
From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Paul Nord
Sent: Tuesday, January 22, 2013 3:21 PM
To: Jiro Fujita
Cc: EPICS tech talk
Subject: Re: sequencer programs in an IOC
Or one could go through the PV's and try a "caget" from the IOC machine to see if they can be found.
On Jan 22, 2013, at 3:03 PM, Jiro Fujita <jiro@creighton.edu<mailto:jiro@creighton.edu>> wrote:
Hi Tim,
Thanks for that. I was actually suggesting to James more or less to do the same in a private e-mail (I figured that it wasn't worth bothering the rest of the world with STAR experiment specific suggestions).
James, as Tim suggests, I suspect the problem is from the missing PVs. This is also consistent with what we have discussed based upon Dilan's (our former colleague) e-mail from last year. Go through the PVs used, and comment them out if necessary for the debug purpose. As I suggested earlier in the private e-mail, if necessary, you can also put printf statement here and there so that you can trace the progress in the IOC shell.
On Jan 22, 2013, at 2:56 PM, Tim Mooney wrote:
James,
Here's one possibility:
By default, a sequencer program won't actually start running for real until every PV it connects to has connected. (See compiler option "+c".) You won't get an error message in this case. You can check the status of PV connections with the "seqChanShow" command. (See http://www-csr.bessy.de/control/SoftDist/sequencer/Using.html#examining-the-program)
Tim
________________________________
From: "James F Ross" <james.falconer.ross@gmail.com<mailto:james.falconer.ross@gmail.com>>
To: "Mark Rivers" <rivers@cars.uchicago.edu<mailto:rivers@cars.uchicago.edu>>
Cc: "Jiro Fujita" <jiro@creighton.edu<mailto:jiro@creighton.edu>>, "EPICS Tech Talk" <Tech-talk@aps.anl.gov<mailto:Tech-talk@aps.anl.gov>>
Sent: Tuesday, January 22, 2013 2:31:02 PM
Subject: Re: sequencer programs in an IOC
Thanks guys,
Yes, the c code is not the problem. There was a communication issue that I knew was causing problems. That is fixed now, and I am getting a few of the desired html files written, but for some reason the main file is not being written. It seems to be going running the program relating to the eemc (one of the early ones called by a seq command in the st.cmd file) but never moves on to the program after it. There is no indication of error, but I'm looking at both the eemc source code and the bemc code (the next program called in the st.cmd file).
James
On Tue, Jan 22, 2013 at 3:19 PM, Mark Rivers <rivers@cars.uchicago.edu<mailto:rivers@cars.uchicago.edu>> wrote:
I would go a step further and say that the C code should be "transparent". It is created in the O.$(ARCH) directory from the .stt code, and is then immediately compiler to an object file to be linked into your application.
The startup script calls a function that is defined in a dbd file via an entry like:
registrar(dxpMEDRegistrar)
That accesses the SNL program, dxpMED.st, whose definition is like the following:
program dxpMED("P=13GE2:med:,DXP=dxp,MCA=mca,N_DETECTORS=16,N_SCAS=16")
The O.linux-x86 directory for that module contains the following files:
corvette:dxp/dxpApp/src>ls -l O.linux-x86
total 19552
...
-rw-rw-r-- 1 epics epics 2043540 Dec 14 19:00 dxpMED.c
-rw-rw-r-- 1 epics epics 1004 Dec 14 19:00 dxpMED.d
-rw-rw-r-- 1 epics epics 97303 Dec 14 19:00 dxpMED.i
-rw-rw-r-- 1 epics epics 1805352 Dec 14 19:00 dxpMED.o
Mark
-----Original Message-----
From: tech-talk-bounces@aps.anl.gov<mailto:tech-talk-bounces@aps.anl.gov> [mailto:tech-talk-bounces@aps.anl.gov<mailto:tech-talk-bounces@aps.anl.gov>] On Behalf Of Jiro Fujita
Sent: Tuesday, January 22, 2013 2:10 PM
To: James F Ross
Cc: EPICS Tech Talk
Subject: Re: sequencer programs in an IOC
James,
In short, when you write a program in state notation language (that you use for EPICS sequencer) and make the IOC, it first gets covered to C code via SNC (SNL to C compiler). Then, the resulting C code get compiled by GCC. In general, you should not have to do much with the C code; certainly, anything we use at STAR soft IOC, we should not have to do much with it.
On Jan 22, 2013, at 9:56 AM, James F Ross wrote:
> Hello everyone,
> I'm trying to understand an IOC that generates a controls monitoring webpage at STAR. For whatever reason, the IOC is not writing the html file that it should be (it has worked in the past).
>
> The source code is a number of .stt files, each of which handles variables for a different subsystem. Ultimately all of these variables are brought together using a file called overall.stt, and the webpage is written by a file called overallhtml.stt.
>
> When the IOC is compiled, these .stt files produce .c files of the same name. What I'm wondering is, how are these c files used? Do they become binary files when the IOC is compiled? What generally happens in an IOC between these c files and a sequencer program being called in the start up script for the IOC?
>
> The sequencer programs are loaded as follows in the IOC startup file:
> seq mot_gas
> seq trig
> seq eemc
> seq bemc
> seq tofm
> seq overall
> seq overallhtml
>
> Are these binary executable files that are being called, or does the startup script read the c code directly? I can't find any binary files by these names on the computer, but I see no errors while compiling either. If anyone has any insight I could use a hand. I know you won't know specifics on my setup, but any help with sequencer programs in general would be nice.
>
> Thanks very much!
> James Ross
>