Something went wrong on our end
-
Alexander Ivanov authored
git-svn-id: https://redoubt.ligo-wa.caltech.edu/svn/advLigoRTS/trunk@2941 6dcd42c9-f523-4c6d-aada-af552506706e
Alexander Ivanov authoredgit-svn-id: https://redoubt.ligo-wa.caltech.edu/svn/advLigoRTS/trunk@2941 6dcd42c9-f523-4c6d-aada-af552506706e
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
TODO 6.18 KiB
Implement frme builder configuratio check and restart, as follows:
Hi Dave,
I think you are correct in 99 percent of the cases. But what Keith is
worried about could happen I, think. NDS daqd could restart/start when DC
daqd is down. In this case NDS daqd would wait until it starts getting the
broadcast, but its channel config would not be changed, it would still
be whatever was configured on its startup. For example:
1. DC daqd is stopped
2. NDS daqd is restarted, so it picks up channel config at time (2)
3. Keith goes ahead and edits channel config
4. DC daqd is restarted with the new configuration valid at time (4)
5. NDS daqd starts getting broadcasts using config (2) even though the
data has the config from time (4).
I propose the following: NDS/FW daqd would check the configuration CRC for
each DCU against its own configuration CRC (see src/daqd/BROADCAST file
for reference). If NDS/FW daqd detects a broadcast where the two CRCs are
different or there is a new DCU appearing or the number of DCUs is
different, then it simply quits and restarts, picking up the new running
configuration. Would this work?
Alex
***
Date: Fri, 01 Jun 2012 12:11:46 -0700
From: Jameson Graef Rollins <jrollins@ligo.caltech.edu>
Reply-To: cds-software@ligo.org
To: CDS Software <cds-software@ligo.org>
Subject: missing bits in filter control
Parts/Attachments:
1 Shown 21 lines Text
2 851 bytes Application
----------------------------------------
Hey, folks. I discovered yesterday, much to my dismay, that the control
input on the cdsFiltCtrl part only allows for turning on and off the
filter banks, and does not allow for controlling any of the other
switches in the module. This is very unfortunate, since it severely
limits the usefulness of the control input and makes the control input
word format inconsistent with the already well-defined format of the
32-bit internal switch state word, which is also used on the control
output.
I strongly request that we make the control input be a 32-bit word whose
format is consistent with internal state word, thereby allowing control
access to all the switches in the module. We already have need to
access these switches in the 40m LSC model, and the need to access them
will likely continue to increase.
Unfortunately making this change will break existing usages of the
FiltCtrl part. It will be a slightly painful transition, but I think
it's a change we need to make, so the sooner we make the change the
better. We'll obviously need to make the mask input be 32-bits as well.
jamie.
***
When the front-end is loaded into the kernel, need to make sure
it is nto trying to load itself on the CPU code which is taken by another
model's front-end. Jamie had c1lsc locking up when loading c1cal on the cpu 4
when c1oaf was already running there.
***
Need to integrate iniChk.pl script into the Epics sequencer C code.
***Jamie reported a bug in file nameing which needs to be fixed:
Date: Tue, 08 May 2012 17:15:33 -0700
From: Jameson Graef Rollins <jrollins@ligo.caltech.edu>
To: Alex Ivanov <aivanov@ligo.caltech.edu>, CDS Software <cds-software@ligo.org>
Subject: Re: bug in RCG MEDM generation?
Parts/Attachments:
1 Shown 21 lines Text
2 851 bytes Application
----------------------------------------
On Tue, May 08 2012, Alex Ivanov <aivanov@ligo.caltech.edu> wrote:
> I looked at the code and the MEDM file naming is done differently
> for the matrices compared to the scheme done for the filter modules. A
> filter module MEDM .adl file gets named based on the whole model file
> name, i.e. h1iscey.adl gives it H2ISCEY_<FILTER_NAME>.adl. A matrix .adl
> file the code truncates to the five characters, so it ends up looking like
> H2ISC_<MATRIX_NAME>.adl. I can't figure out which way is right.
Investigations seem to indicate that the situation has been like this
for a long time. I thought we had decided that we would always just use
the first five characters of model names in all circumstances, but I
guess that never got put in place (although I'm still puzzled why there
would be references to screens that never would have existed). The most
important thing at this point is to just be consistent, and since most
things seem to be assuming full model name, we should just settle on
that.
Alex, if you can modify feCodeGen to consistently generate all screen
names based on the full model name that would be great. Thanks.
jamie.
***
Another request from Jamie:
Date: Tue, 22 May 2012 11:02:56 -0700
From: Jameson Graef Rollins <jrollins@ligo.caltech.edu>
Reply-To: cds-announce@ligo.org
To: CDS users mailing list <cds-announce@ligo.org>
Subject: [cds-announce] EPICS records for cdsIPCx errors
Parts/Attachments:
1 Shown 25 lines Text
2 851 bytes Application
----------------------------------------
Hi, all. I have an RCG feature request:
I would like to request that the cdsIPCx receivers auto-generate an
EPICS record that records transmission errors. This would make it much
easier for us to add MEDM indicators that report the state of specific
IPCx channels.
I notice that the RCG developers guide doesn't actually explain how the
Err output behaves (it would be nice if it did), but the IPC document
[T1000587] does: the Err output apparently reports the number of errors
per second. I assume that means that at every EPICS sample the output
is the number of errors in the last second. I think that's ok for
front-end models, since anything non-zero indicates current loss of
integrity. I think it would be nice to have something a little
different for the EPICS record, though. I would suggest they keep a
running tally of the number of errors since the last "DIAGNOSTICS
RESET". That way it won't clear automatically if the error rate returns
to zero.
I think it would also be nice if the GDS_TP screens included a section
with indicators for these EPICS records for all of the IPCx receivers in
the model. That seems like a logical place to have them automatically
called out.
jamie.
***