advLigoRTS issueshttps://git.ligo.org/cds/software/advligorts/-/issues2024-03-08T20:41:17Zhttps://git.ligo.org/cds/software/advligorts/-/issues/615System name '#define' breaks librts filter lookup.2024-03-08T20:41:17ZErik von ReisSystem name '#define' breaks librts filter lookup.From Chris Wipf:
| [This change](https://git.ligo.org/cds/software/advligorts/-/merge_requests/613) breaks the filter module detection code in `librts/scripts/buildMapFromHeader.py`From Chris Wipf:
| [This change](https://git.ligo.org/cds/software/advligorts/-/merge_requests/613) breaks the filter module detection code in `librts/scripts/buildMapFromHeader.py`https://git.ligo.org/cds/software/advligorts/-/issues/594DUOTONE_TIME_FLOAT channel shows different trends2024-01-19T07:59:34ZShoichi OshinoDUOTONE_TIME_FLOAT channel shows different trendsI found that DUOTONE_TIME_FLOAT channel shows different trends depending on the ADC card revision.
Our test bench system uses Debian10 and RCG 5.1.4.
I put only one ADC card on IO chassis.
```
root@k1boot:~# uname -a
Linux k1boot 4.1...I found that DUOTONE_TIME_FLOAT channel shows different trends depending on the ADC card revision.
Our test bench system uses Debian10 and RCG 5.1.4.
I put only one ADC card on IO chassis.
```
root@k1boot:~# uname -a
Linux k1boot 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux
root@k1boot:~# rtcds --version
__main__.py, version 6.7.1; RTS_VERSION=5.1.4
```
When we use rev.B ADC card, DUOTONE_TIME_FLOAT shows around 7.
```
[ 58.765065] k1iopimc0: INFO - 1 ADC cards found
[ 58.765194] k1iopimc0: INFO - ADC 0 is a GSC_16AI64SSA module
[ 58.765327] k1iopimc0: INFO - Channels = 32
[ 58.765456] k1iopimc0: INFO - Firmware Rev = 34
```
![adc-revb](/uploads/9715b6b83a0cbc12c8be9fb514c9a7db/adc-revb.png)
However, when we use rev.C ADC card, it shows around 22.
```
[ 58.602420] k1iopimc0: INFO - 1 ADC cards found
[ 58.602549] k1iopimc0: INFO - ADC 0 is a GSC_16AI64SSA module
[ 58.602683] k1iopimc0: INFO - Channels = 32
[ 58.602811] k1iopimc0: INFO - Firmware Rev = 293
```
![adc-revc](/uploads/463e393868f5079df7b92fdaef45221b/adc-revc.png)
Could you please let me know if you have any idea of the cause of this phenomenon?https://git.ligo.org/cds/software/advligorts/-/issues/602Add support for Dolphin MX drivers2023-12-01T17:23:53ZKeith ThorneAdd support for Dolphin MX driversAdd support for using Dolphin MX drivers. Most work has been done - dolphin-mx-debian repository created, DolphinMXSource and DolphinMX builds in Jenkins to create the ligo-dolphin-mx-* packages
Remaining work is to modify build of dol...Add support for using Dolphin MX drivers. Most work has been done - dolphin-mx-debian repository created, DolphinMXSource and DolphinMX builds in Jenkins to create the ligo-dolphin-mx-* packages
Remaining work is to modify build of dolphin-proxy-km to add ligo-dolphin-mx to listKeith ThorneKeith Thorne2023-12-04https://git.ligo.org/cds/software/advligorts/-/issues/388#defines Should not be used in the c code blocks used to generate model code.2023-10-18T17:55:19ZEzekiel Dohmen#defines Should not be used in the c code blocks used to generate model code.One area where this looks like an issue is in the `x2isietmx` model (Probably an issue in other places too).
It uses the `ODC_LATCH` and `ODC_ADD_PARITY_INT` c blocks.
```
/opt/rtcds/userapps/release/cds/common/src/ODC_LATCH.c
/opt/rtc...One area where this looks like an issue is in the `x2isietmx` model (Probably an issue in other places too).
It uses the `ODC_LATCH` and `ODC_ADD_PARITY_INT` c blocks.
```
/opt/rtcds/userapps/release/cds/common/src/ODC_LATCH.c
/opt/rtcds/userapps/release/cds/common/src/ODC_ADD_PARITY_INT.c
```
They both define `MAX_BITS` and `#define`s are not scoped so it gets redefined during x2isietmx's build.https://git.ligo.org/cds/software/advligorts/-/issues/340Update the cmake/ctest so that a model is built as part of the ctest process2023-08-04T17:56:09ZJonathan HanksUpdate the cmake/ctest so that a model is built as part of the ctest processCTest primarily tests daqd, local_dc, and transports.
We should make it easy to test if we have outright broken the rcg by running the rcg in ctest, w/o requiring a specific test stand setup.
We would need to provide a sample model. T...CTest primarily tests daqd, local_dc, and transports.
We should make it easy to test if we have outright broken the rcg by running the rcg in ctest, w/o requiring a specific test stand setup.
We would need to provide a sample model. There are two routes we can go with this (potentially we could do both).
* Provide a model that has all the features/parts we can pack into it to exercise the RCG
* Provide a simple model that tests basic building that could even be run on anything (ie no physical adc/dac/io cards required)
This is not to replace the suite of integration tests that test each RCG part on the large test stand, just to test base functionality of the rcg and make it easier to find when we break it.Erik von ReisErik von Reishttps://git.ligo.org/cds/software/advligorts/-/issues/540general duotone improvements2023-08-04T17:50:29ZErik von Reisgeneral duotone improvementsDaniel writes:
> One more item to add:
>
> We should give the DAC duotone readbacks the same treatment as the ADC, and either repurpose the DT_TIME_DAC channel as a float or add another float channel.
>
> The analysis windows also ne...Daniel writes:
> One more item to add:
>
> We should give the DAC duotone readbacks the same treatment as the ADC, and either repurpose the DT_TIME_DAC channel as a float or add another float channel.
>
> The analysis windows also needs to be shifted. Looks like we have a delay of 4 samples at 64K? If so, we may want to subtract it in the reporting.
>
> Only 2 FE are using DAC duotone as far as I know.
He also wrote
> Here is my list of high priority features for the next RCG release. Not sure if these changes will fit before it gets released. In any case, these should be implemented in the OMC FE as soon as possible.
>
> 1. DuoTone calculation in 512K IOP/ADC uses 5th sample (the one that is aligned to 1PPS) for the zero crossing calculation. This guarantees that DT zero crossings are reported consistently between all IOPs, and represent the true delay or advance of the DAQ timestamps.
>
> 2. DuoTone zero crossing limits that take into account newer timing board firmware with corrected DT signal, i.e., DT signal crosses zero at 1PPS sharp.
>
> 3. Fix the extra 13.4 us IPC delay in the 512K IOP. I assume this is because an 512K IOP writes its IPCs after the first rather than the last sample.
>
> 4. Make an option to start the user models after the IOP has finished with is FE model and written all IPC, in order to eliminate the IOP IPC delays all together. Probably needs a lot of testing to see if the timing works out. (Also, IPCs would need to be written without the 1 IOP cycle advance as it currently is done.)
[daniel_duotime.cpp](/uploads/caf5c258e4a8fe1bc8770ced2f9b33d2/daniel_duotime.cpp)
> Here is the> effect testing data windows of
> ```
> zeroCrossing[dat, 5, 11],
> zeroCrossing[dat, 5, 12],
> zeroCrossing[dat, 5, 13],
> zeroCrossing[dat, 6, 12],
> zeroCrossing[dat, 4, 9],
> zeroCrossing[dat, 6, 13]
> ```
> and compare it to a full fit (blue current algorithm, red new, units usec).
[dt_better.pdf](/uploads/c18f6ef9e8bea60eae34bc0fabab3405/dt_better.pdf)
[DuoTone_compare.pdf](/uploads/f5b66009efcf3f945c29303b0e684fca/DuoTone_compare.pdf)
> Here is a histogram of all duotone zero crossings: There seems to be 2 separate distributions spaced 600ns apart. Strange. Not sure, if this is a timing board thing or not.
>
> Next Tuesday, we should reprogram 1 to 3 timing boards with the new firmware, omc and isc ex/ey maybe. I think we should not replace the boards but reprogram them to make sure they jump exactly the specified difference of 7.1us.
>
> We can also downgrade the firmware for the one in the test stand.
[DuoTone_histogram.pdf](/uploads/c6dc89f507bf75392c00fb329931d64c/DuoTone_histogram.pdf)Erik von ReisErik von Reishttps://git.ligo.org/cds/software/advligorts/-/issues/232Adapt mbuf, gpstime kernel modules to Linux 5.x in Debian bullseye2023-07-13T23:03:28ZKeith ThorneAdapt mbuf, gpstime kernel modules to Linux 5.x in Debian bullseyeThe Linux 5.10 kernel in Debian 11/bullseye has changes from the 4.19 kernel in Debian 10/buster. We need to adapt the mbuf and gpstime modules to handle it.
Known items
HAVE_UNLOCKED_IOCTL removed in kernel 5.9
ioremap_nocache removed...The Linux 5.10 kernel in Debian 11/bullseye has changes from the 4.19 kernel in Debian 10/buster. We need to adapt the mbuf and gpstime modules to handle it.
Known items
HAVE_UNLOCKED_IOCTL removed in kernel 5.9
ioremap_nocache removed in kernel 5.6
timespec, current_kernel_time() removed in kernel 5.6 (new timekeeping routines)
proc_create uses proc_ops as of kernel 5.6Keith ThorneKeith Thornehttps://git.ligo.org/cds/software/advligorts/-/issues/195Out of the box RCG install can't build epics-only models.2023-07-13T23:01:10ZErik von ReisOut of the box RCG install can't build epics-only models.Makefile is looking for IOP and Dolphin symvers even though none are needed for epics only models. Error message produced just says "Error" and a line number with no other information.
Trying to build an IOP model to produce the IOP sy...Makefile is looking for IOP and Dolphin symvers even though none are needed for epics only models. Error message produced just says "Error" and a line number with no other information.
Trying to build an IOP model to produce the IOP symvers also produces an unspecified error and the build fails.https://git.ligo.org/cds/software/advligorts/-/issues/211gpstime module gives old partial-second on change to new second2023-07-13T22:26:31ZKeith Thornegpstime module gives old partial-second on change to new secondThe existing EDCU runs along side the real-time models on a front-end so it can query the IRIG-B receiver. However, this interferes with the real-time model time queries to the same IRIG-B receiver.
We then moved it to a front-end (x2ec...The existing EDCU runs along side the real-time models on a front-end so it can query the IRIG-B receiver. However, this interferes with the real-time model time queries to the same IRIG-B receiver.
We then moved it to a front-end (x2ecatmon1) on the test stand with an IRIG-B receiver but no real-time models. It was found in this case that every few seconds (on continuous polling) the time would show the new second, but with a partial second at 0.99... (see [TST Log 14137](https://alog.ligo-la.caltech.edu/TST/index.php?callRep=14137).
Figure out why this if failing. It may be some issue with the gpstime kernel module code and its read out of the IRIG-B receiverKeith ThorneKeith Thornehttps://git.ligo.org/cds/software/advligorts/-/issues/60RCG check for I/O parts not on top level of model2023-07-13T20:45:55ZDavid BarkerRCG check for I/O parts not on top level of modeltransfer of bugzilla bug 463transfer of bugzilla bug 463Rolf BorkRolf Borkhttps://git.ligo.org/cds/software/advligorts/-/issues/11RCG creating incorrect paths in target/<model>epics/<model>epics<ifo>.cmd, am...2023-07-13T17:27:46ZJameson Rollinsjameson.rollins@ligo.orgRCG creating incorrect paths in target/<model>epics/<model>epics<ifo>.cmd, among other placesfrom the $RTBUILD/x1iop.log:
```
...
for ifo in X1 ; do \
...
echo "epicsEnvSet DAQ_FILE /opt/rtcds/tst//chans/daq/$ucmodel.ini" >> target/x1iopepics/x1iopepics$ifo.cmd; \
...
```
Note that the path is missing a component that sh...from the $RTBUILD/x1iop.log:
```
...
for ifo in X1 ; do \
...
echo "epicsEnvSet DAQ_FILE /opt/rtcds/tst//chans/daq/$ucmodel.ini" >> target/x1iopepics/x1iopepics$ifo.cmd; \
...
```
Note that the path is missing a component that should be filled in by "$ifo", presumably.
I tracked this down to configure/Makefile.linux, which I assume is somehow eventually called by the build script. It has the following lines in the "install" target:
```
...
# Install built epics IOC into target/$(TARGET)
install: $(DB)
...
for ifo in $(IFO) ; do \
...
echo "epicsEnvSet DAQ_FILE /opt/rtcds/$(SITE)/${ifo}/chans/daq/$$ucmodel.ini" >> target/$(TARGET)/$(TARGET)$$ifo.cmd; \
...
```
So I'm guessing all this make shell craziness is supposed to put the value of $(IFO), which from the log above is supposed to be "X1", into "${ifo}". But that's obviously not working. No idea if this is an issue with changes to make, bash, whatever. But clearly something more robust is needed.Rolf BorkRolf Borkhttps://git.ligo.org/cds/software/advligorts/-/issues/10RCG fails to rationalize casing of IFO variable2023-07-13T17:25:56ZJameson Rollinsjameson.rollins@ligo.orgRCG fails to rationalize casing of IFO variableThe cdsParameters block expects the "site" parameter to actually be set to the ifo (e.g. "H1") (see #9). It additionally requires
that the ifo designator be upper case, although this is not explicitly checked.
For example, for model "x...The cdsParameters block expects the "site" parameter to actually be set to the ifo (e.g. "H1") (see #9). It additionally requires
that the ifo designator be upper case, although this is not explicitly checked.
For example, for model "x1iop" with cdsParameter "site=x1", the RCG builds the sequencer db in
```
target/x1iopepics/db/x1
```
However, the Makefile then expects the sequencer db at
```
target/x1iopepics/db/X1
```
which does not exist, so the build fails with the following error:
```
***ERROR: target/x1iopepics/db/X1/x1iop1.db does NOT exist
```
The RCG should rationalize the casing of all variables appropriately, rather than requiring they be set with a particular case.
As an aside, it's unfortunate that the casing is different all over the place.Rolf BorkRolf Borkhttps://git.ligo.org/cds/software/advligorts/-/issues/508move /usr/share/advligorts/calc_gps_offset.py to /sbin and rename, this is du...2023-07-13T07:01:46ZJonathan Hanksmove /usr/share/advligorts/calc_gps_offset.py to /sbin and rename, this is due the occasional need to manually run the process.Sometimes for error conditions the user needs to manually run calc_gps_offset.py.
So rename to something like /sbin/gpstime_module_configSometimes for error conditions the user needs to manually run calc_gps_offset.py.
So rename to something like /sbin/gpstime_module_configJonathan HanksJonathan Hankshttps://git.ligo.org/cds/software/advligorts/-/issues/580Dual use (userspace/kernel) files are not clean enough for kernel inclusing w...2023-07-12T21:24:01ZJonathan HanksDual use (userspace/kernel) files are not clean enough for kernel inclusing when building on Deb 12/gcc 12/linux 6.1When building models on Debian 12 (gcc 12, linux 6.1) the kernel build includes the -nostdinc flag. This means we do not have access to header files like stddef.h, stdalign.h, ...
This causes builds to fail.
ctest -R test-model-build ...When building models on Debian 12 (gcc 12, linux 6.1) the kernel build includes the -nostdinc flag. This means we do not have access to header files like stddef.h, stdalign.h, ...
This causes builds to fail.
ctest -R test-model-build -VV
<pre>
35: make[2]: Entering directory '/usr/src/linux-headers-6.1.0-9-amd64'
35: CC [M] /home/jonathan.hanks/Documents/advLigoRTS/cmake-build-debug/test/build/models/x1iop/kernel_mod/x1iop_core.o
35: make[2]: Leaving directory '/usr/src/linux-headers-6.1.0-9-amd64'
35: make[1]: Leaving directory '/home/jonathan.hanks/Documents/advLigoRTS/cmake-build-debug/test/build/models/x1iop/kernel_mod'
35: In file included from /home/jonathan.hanks/Documents/advLigoRTS/src/include/controller.h:9,
35: from /home/jonathan.hanks/Documents/advLigoRTS/src/include/fe.h:6,
35: from /home/jonathan.hanks/Documents/advLigoRTS/cmake-build-debug/test/build/models/x1iop/kernel_mod/x1iop_core.c:4:
35: /home/jonathan.hanks/Documents/advLigoRTS/src/include/drv/shmem.h:11:10: fatal error: stddef.h: No such file or directory
35: 11 | #include <stddef.h>
</pre>
Running with export KBUILD_VERBOSE=1, shows that -nostdinc is added to the build line by the kernel.https://git.ligo.org/cds/software/advligorts/-/issues/574Revisit the use of `systemName` in the parser, and remove any logic that buil...2023-06-30T15:59:27ZEzekiel DohmenRevisit the use of `systemName` in the parser, and remove any logic that builds models differently based on it if possible.For example we have the line:
```
# Model uses FIR filters
if($::systemName eq "sei" || $::useFIRs)
{
print OUTM "EXTRA_CFLAGS += -DFIR_FILTERS\n";
}
```
However we add FIR filter supported based on the part being present in the model...For example we have the line:
```
# Model uses FIR filters
if($::systemName eq "sei" || $::useFIRs)
{
print OUTM "EXTRA_CFLAGS += -DFIR_FILTERS\n";
}
```
However we add FIR filter supported based on the part being present in the model now.https://git.ligo.org/cds/software/advligorts/-/issues/579librts: excitation channels need unique AWG ids2023-06-22T18:10:40ZChristopher Wipflibrts: excitation channels need unique AWG idsWhen calling `getIndexAWG`, there needs to be a one-to-one mapping between the id number (second argument) and the excitation point channel names. AWG uses this id number to decide whether to allocate a new slot, or return an already exi...When calling `getIndexAWG`, there needs to be a one-to-one mapping between the id number (second argument) and the excitation point channel names. AWG uses this id number to decide whether to allocate a new slot, or return an already existing slot.
Currently [librts always uses `1` as the id number](https://git.ligo.org/cds/software/advligorts/-/blob/f0f8684ce5c40d4a2adfe140b582619307827bb8/src/librts/src/Model.cpp#L1130). Therefore, only one AWG slot can ever be allocated. If you try to drive multiple channels with distinct waveforms, each channel ends up being driven with the same waveform (which is a superposition of all waveforms that were requested).
Here's a short example demonstrating the issue:
```python
import numpy as np
import matplotlib.pyplot as plt
import x1bmp_pybind
mdl = x1bmp_pybind.create_instance(1)
# setting up two simultaneous excitations
slot1 = mdl.get_awg_slot('CTRL_A_EXC')
slot2 = mdl.get_awg_slot('CTRL_B_EXC')
print(f'got slots {slot1} {slot2}') # expect two distinct slot numbers
# waveform 1 (1.1 Hz 1 ct sine wave)
c1 = x1bmp_pybind.AWG_Component()
c1.wtype = c1.wtype.awgSine
c1.start = (mdl.get_gps_time()+1)*int(1e9)
c1.duration = -1
c1.restart = -1
c1.par[0] = 1
c1.par[1] = 1.1
x1bmp_pybind.addWaveformAWG(slot1, [c1,])
# waveform 2 (2.1 Hz 2 ct sine wave)
c2 = x1bmp_pybind.AWG_Component()
c2.wtype = c2.wtype.awgSine
c2.start = (mdl.get_gps_time()+1)*int(1e9)
c2.duration = -1
c2.restart = -1
c2.par[0] = 2
c2.par[1] = 2.1
x1bmp_pybind.addWaveformAWG(slot2, [c2,])
# record results
mdl.record_model_var('CTRL_A_IN2', mdl.get_model_rate_Hz())
mdl.record_model_var('CTRL_B_IN2', mdl.get_model_rate_Hz())
mdl.run_model(mdl.get_model_rate_Hz()*10)
data1 = np.array(mdl.get_recorded_var('CTRL_A_IN2'))
data2 = np.array(mdl.get_recorded_var('CTRL_B_IN2'))
# plot results
plt.plot(np.linspace(0, 10, mdl.get_model_rate_Hz()*10), data1)
plt.plot(np.linspace(0, 10, mdl.get_model_rate_Hz()*10), data2)
plt.savefig('awgissue.png') # expect two distinct sine waveforms
```
And the resulting plot:<br/>
![awgissue](/uploads/8b2f5d8bd5a5d8984dacc172d808a476/awgissue.png)
The [code in the original MR](https://git.ligo.org/cds/software/advligorts/-/blob/abef8decfbe2e516013251bc348211b0de71a4db/src/librts/src/Model.cpp#L1122) incremented the id number while iterating over the excitation points, to provide a unique id for each one.https://git.ligo.org/cds/software/advligorts/-/issues/350Feature request: models need a way to specify their build flags2023-05-30T22:17:31ZChristopher WipfFeature request: models need a way to specify their build flagsOne way this would be used is to provide userspace models with a mechanism for linking to external shared libraries. It could also let models turn on compiler optimization features, etc.
It could be implemented by adding options to the...One way this would be used is to provide userspace models with a mechanism for linking to external shared libraries. It could also let models turn on compiler optimization features, etc.
It could be implemented by adding options to the `cdsParameters` block, or perhaps the text field in the `cdsFunctionCall` block, since this capability would most likely be of interest in models running custom C code.https://git.ligo.org/cds/software/advligorts/-/issues/566Add mux to blocks in CDS_PARTS where it must be present for the model to build.2023-05-25T23:38:06ZEzekiel DohmenAdd mux to blocks in CDS_PARTS where it must be present for the model to build.For example the Fcn part always has a mux on its input, so one should be attached in the CDS_PARTS example part page.
CDS parts comment on cdsIPCx_RFM part is wrong.For example the Fcn part always has a mux on its input, so one should be attached in the CDS_PARTS example part page.
CDS parts comment on cdsIPCx_RFM part is wrong.Ezekiel DohmenEzekiel Dohmenhttps://git.ligo.org/cds/software/advligorts/-/issues/373user model ADC overflow should only be indicated for channels used by the model2023-05-16T23:22:27ZErik von Reisuser model ADC overflow should only be indicated for channels used by the modelUser models will indicate ADC overflow if an ADC used by the model is overflowing in any channel, but should only check channels used by the model.User models will indicate ADC overflow if an ADC used by the model is overflowing in any channel, but should only check channels used by the model.Ezekiel DohmenEzekiel Dohmenhttps://git.ligo.org/cds/software/advligorts/-/issues/569When models have a small amount of filter modules in them, it takes too long ...2023-05-16T23:21:52ZEzekiel DohmenWhen models have a small amount of filter modules in them, it takes too long to load filter coefficients.`checkFiltReset()` is called at a 16Hz rate on each filter module.
When there are only two filter modules you get 32 calls to checkFiltReset(), however work is only partially complete each call to balance the incurred cycle latency. On...`checkFiltReset()` is called at a 16Hz rate on each filter module.
When there are only two filter modules you get 32 calls to checkFiltReset(), however work is only partially complete each call to balance the incurred cycle latency. Only 1 filter stage is loaded each call, and once a filter module starts being reset/loaded checkFiltReset() with a different module ID actually continues work on the module already being reset/loaded.
2 filter modules means you have 2 * 16 -> 32 actions a second. At 1 action to load 1 stage, you have a minimum time of 10(stages)/32 ~.3125 seconds to load one filter module.
If you had 10 filter modules 10 * 16 -> 160 actions a second. 10(stages)/160 = ~ 0.0625 seconds to load a filter module.
Notice: What times out is not the time it takes to load all filters, but the time it takes to load a single filter module.