search

KLMTestBench / KLMTestBenchStatus

Tracking the Status of the KLM Test Bench at Hawaii
0 stars 0 forks source link

FTSW was encountering a BUSY #16

Open RPeschke opened 6 years ago

RPeschke commented 6 years ago

I was able to regain access to the KEK VPN and try to reproduce the test. I think what might be happening is that some number of triggers are being sent successfully, but the FTSW quickly detects an error and stops sending new triggers. With the KEK system I see the registers update as Brandon describes for some period, but then stops after an "FTSW BUSY" error appears in the VME terminal control.

To reset the FTSW to allow more data to be sent I suggest reprogramming the SCROD firmware and resetting the FTSW ie in the VME terminal type: resetft -<FTSW #> This should allow the DC registers to increment as expected until the next BUSY error.

Quick question: are you doing this test with the dummy SCROD firmware? It will not work with default firmware without running slow control initialization. This is the next step after verifying the FTSW trigger distribution is working.

Isar, Bradon, for reference the Belle2 link has already been verified working and @cketter + @rpeschke are reading out the registers you suggested. In particular we observed last week the expected behaviour for SCROD register 0 when using the default fimrware.

RPeschke commented 6 years ago

Were you able to confirm if FTSW was encountering a BUSY error while sending triggers? I'm also wondering if you were able to confirm if you were using the dummy firmware for this initial test.

On the KEK side I've produced a simplified version of the slow control initialization script based on Isar's scripts that works for a single board and allows data-taking to proceed normally. I think this script can be used with the UH setup and the default firmware with only minor modification for this initial trigger distribution and data flow test.