This page shows the basics of setting up a PV with BSA. More details and documents are in Sharepoint. 

The main aspects of using BSA are configuring BSA PVs in an IOC, setting up and running event definitions (edefs) to acquire data, and using BSA data e.g. in Matlab programs.

Configuring a BSA PV in Your IOC

Within the IOC, a Data Source PV, e.g. an ai record from an IP330, is configured to provide specially time stamped scalar values to the BSA support within the same IOC.

Data Source

Your data source PV may be any scalar type. It may get its value directly from a hardware driver, or it can be a soft record. The keys to making a PV work with BSA are a High priority, a forward link to the Data Receptor PV, a SCAN setting appropriate to the triggering used, and TSE setting appropriate to getting the right Pulse ID in the Time Stamp.

The priority must be high so that processing is completed before the next trigger, and the correct Pulse ID is read. Depending on the TSE setting, a later Pulse ID may be put into the time stamp if processing takes longer than 8.33 ms.

The appropriate TSE setting depends on how the Data Source PV is processed:

• TSE = -1 for a fast and simple PV, e.g. an IP330 analog input using I/O Intr and an external EVR trigger. The most recent beam code is used, so processing must complete in 8.33 ms
• TSE = -2 if device support will handle the time stamp. For example, device support code may call evrTimeGet at the beginning of processing, so it has the time stamp corresponding to when data was read even if processing that data takes longer than 8.33 ms
• TSE = an event code #. The time stamp for the most recent trigger for that event code will be used, even if processing takes longer than 8.33 ms. This can be used if data is not synchronized with the beam, but you want the time stamp to correlate with other data. If SCAN is also using an event code, make sure EVNT and TSE match.
• TSEL field set to the .TIME field of another BSA PV. This causes the PV to use the PV named in its TSEL field as the source of the timestamp.
• TSEL field set to the $(DEV)LSUB_EVSEL associated with the EVR trigger output going to your device. The LSUB_EVSEL PV contains the active event code for a trigger. When TSEL is set to the LSUB_EVSEL PV (NOTE: NOT the .TIME field) its value is written to the TSE field of your PV. The time stamp used is then the one associated with the time stamp, just like setting "TSE = event code #" directly, but it automatically changes if a different event code is selected.

Data Receptor

When you create the BSA records, e.g.

dbLoadRecords("db/Bsa.db","DEVICE=TRIG:B34:EV05, ATRB=COUNTER")

the BSA database defines a PV for feeding data from your Data Source to the rest of the BSA system. When configuring the BSA database, be sure the name matches the Data Source PV. The BSA internals depend on the PV names being composed of the same $(DEVICE) and $(ATRB) parts. It would cause confusion if the history buffers had a name that didn't correspond to the data in them.

The BSA database can be defined by using Bsa.db or one of the following templates:

bsaATTREdef.db

bsaBPMSEdef.db

bsaBPMSCavityEdef.db

bsaTOROEdef.db

bsaFARCEdef.db

bsaBLENEdef.db

bsaPMTEdef.db

bsaWIREEdef.db

bsaAMPLEdef.db

bsaPHASEdef.db

bsaPWREdef.db

bsaEnergyEdef.db

The only difference in these two approaches is in macros.  Bsa.db is meant to be used in st.cmd, where the device is passed as macro and you need one line for each device.

Our recommendation is to use substitutions files in Db so that syntax is checked while executing make vs during ioc startup.  This will prevent possible run time problem about macros while rebooting the IOC.

 example:   In your application you need to create the substitutions file such as:

 evrLabApp/Db/bsaTrainerAll.substitutions

In the substitution file, it has to import the the *.db file that you choose, for example Bsa.db:

file Bsa.db

{

# Device type used for the test.

 pattern { DEVICE     , ATRB  }

         { LEPTON:1   , COUNTER }

…..

}