lnls-sirius/dev-packages

Development Packages for Sirius Control Systems

Dev-packages

Python packages useful for the development of the Sirius control system.

Packages	Description
siriuspy	Sirius control system classes and utility functions used in HLA and IOC applications.

---

siriuspy

Subpackages and modules

• siriuspy.bsmp - BSMP functionalities.
• siriuspy.clientarch - Retrieve data from epics archiver.
• siriuspy.clientconfigdb - Client-side library to interact with Sirius configuration server.
• siriuspy.servweb - Functions to retrieve data from the static table server.
• siriuspy.currinfo - Classes for Sirius current information.
• siriuspy.cycle - Classes for magnet cycling.
• siriuspy.devices - Classes that implement epics devices.
• siriuspy.diagbeam - Classes for Beam diagnostics
• siriuspy.epics - Auxiliary classes for epics functionalities.
• siriuspy.machshift - Machine shift classes.
• siriuspy.magnet - Classes and structures useful to represent magnet properties.
• siriuspy.meas - Beam measurements classes.
• siriuspy.namesys - Functionalities to deal with names for Sirius naming system.
• siriuspy.optics - Constants, functions and data related to Sirius beam optics.
• siriuspy.opticscorr - Optical corrections.
• siriuspy.posang - Position and Angle corrections.
• siriuspy.ramp - Library used to perform booster ramp operations.
• siriuspy.search - Search methods for various data structures retrieved from the static tables of the control system constants server.
• siriuspy.sofb - Classes for Slow Orbit Feedback system.
• siriuspy.timesys - Functionalities related to Sirius timing subsystem.
• siriuspy.callbacks.py - (module) Implementation of general function callback mechanism similar to Epics PV callbacks.
• siriuspy.csdev.py - (module) General control system device funcstion adn data structures.
• siriuspy.envars.py - (module) Configuration of environment variables.
• siriuspy.thread.py - (module) Thread classes.
• siriuspy.util.py - General useful functions and constants

Prerequisites

See the repository's requirements.txt file.

Installation

cd siriuspy
./setup.py install

Unittests

Before making pull-requests to master branch, unittests can be run.

• To run all integration unittests, issue the following commands

  cd sirius 
  pytest tests/

• To run unittests for specific subpackages or modules, for example, issue

  cd siriuspy
  pytest tests/devices/
  pytest tests/pwrsupply/test_csdev.py

---

dev-packages's Issues

PVDataSet doesn't deal well with PVs that aren't archived

When using PVDataSet to fetch a PV that doesn't exist, the update() method returns None, which is the same thing it does when it succeeds. When using a list of PVs which exist and which don't, it does the same thing, but there is no data for the PVs which do exist (the .value and .timestamp members are None), and then one has to figure out which specific PV wasn't archived, which is an information that should have been reported in failure information.

Delete branch PR-from-bottom-up

Branch PR-from-bottom-up had been deleted but I guess it was pushed back to origin by mistake

AS_PS with real mode breaks in some situations

AS-PS of branch PR-new-bbb breaks in two situations:

• when BBB is not connected to the PS controllers through the serial line and the IOC is started.
• when IOC is running and connected and suddenly the PS controller is turned off.

PS IOCs of bsmp-test-merge branch is bogus with real device

Generalize PS and MA classes to deal with types othe than FBP

At this point all control-system classes for power supplies were implemented with the FBP type as archetype. At some points the code is ready for generalizations wheres in other places, bigger changes are in order. we should start the effort of generalizing these classes as soon as possible. the problem is that easily accesable doc on these other types of power supplies is scarce at this moment. we should elect one other type and interact with the ELP staff in order to add it to our code.

IOC MA is apparently not updating strength anymore!

BSMP execute_function with inverted tuple order in its return value

@gu1lhermelp , take a look at this at branch PR-bbb-from-bottom-up at line 188:

dev-packages/siriuspy/siriuspy/bsmp/commands.py

Lines 173 to 189 in 6fa9589

	def execute_function(self, func_id, input_val=None):
	"""Execute a function. Command 0x50."""
	function = self.entities.functions[func_id]
	# Load = function id + input data
	load = [chr(func_id)] + function.value_to_load(input_val)
	m = _Message.message(0x50, payload=load)
	response = self.channel.request(m)
	if response.cmd == 0x51:
	# result of the execution
	if len(response.payload) == function.o_size:
	return Response.ok, function.load_to_value(response.payload)
	elif response.cmd == 0x53:
	# function error
	if len(response.payload) == 1:
	# TODO: the tuple order of return seems to be inverted!
	return response.payload, None
	return None, None # reached in case of serial comm error?

Change Version-Cte PVs from string to array of chars

as to circumvent the 40-letter-epics limit for string types.

• uncomment code in BSMPMasterSlave._process_firmware_stream

Delete `siriusdm` package

Functionalities are to be implemented in siriushla package.

IOC PS: OpMode-Sel setpoint is changing PwrState-Sts

• this issue was reported by @anacso17 while using sirius-hla-si-ap-chromcorr.
• this bug was verified setting OpMode-Sel manually and using simulates PS controllers for SI-Fam:MA-SFA1

organize and implement systematic unittest for siriuspy

Unify pulsed ps/ma with ps/ma

Merge PSEpics and MAEpics in pwrsupply/model.py

• should we do it?

Limits in simulation of Low Level Timing modules

The Low Level timing modules provide PVs of type unsigned integer of 32 bits for delays and widths of the trigger pulses. This type of PV is not supported in pcaspy, so I changed the limits of the PVs in simulation from 2**32-1 to 2*31-1.

An issue was created in paulscherrerinstitute/pcaspy#53 to check the possibility of creating this data type in pcaspy.

namesys.Filter does not raise exception when user passes invalid keys

Backslash-character pair that may become a bug in future python versions.

I was running flake8 in a fork I made and encountered these warnings that may cause problems in the future.

https://github.com/lnls-sirius/dev-packages/blob/master/siriuspy/siriuspy/clientconfigdb/configdb_document.py#L148
https://github.com/lnls-sirius/dev-packages/blob/master/siriuspy/siriuspy/namesys/implementation.py#L365
https://github.com/lnls-sirius/dev-packages/blob/master/siriuspy/siriuspy/namesys/implementation.py#L440
https://github.com/lnls-sirius/dev-packages/blob/master/siriuspy/siriuspy/magnet/util.py#L176

The problem is that some scape sequences such as '\d' and '\w' will no longer be valid when using simple strings. The sulution would be to use raw string literals r"\d" and r"\w". However this may break something e. g. "\\n" passed to a regex must become r"\n".

The corresponding flake8 warning was W605

The flake8 settings I used were:

[flake8]
max-complexity = 18
select = B,C,E,F,W,T4,B9
ignore = E203, E266, E501, W503, E722

Create unittest for PSSearch.get_bbbname_dict

Check phase syncing of BPMs' decimators

We recently exposed a feature for BPMs to generate synthetic data based on internal counters. These counters increment at their respective rate and can be synced (reset) across all BPMs by pulsing an external trigger. This can then be used for checking the phase syncing of BPMs' decimators.

Things left to decide:

• Which physical trigger should we use? Lines 3 and 6 aren't being used, but we can use reuse another line too.
  Lets say we picked PT_n.
• Which high-level event should we use? FAC group can better decide this.
  Lets say they picked HLE.

Configurations:

• Route logical trigger 3 to physical trigger PT_n.
• Set event HLE to pulse PT_n in all AFCs Timing.

After phase syncing BPMs' decimators, the following steps should be done

1. Reset internal counters.
2. Enable synthetic data generation.
   caput $(P)$(R)TestDataEn-Sel enable
3. For each acquisition rate in {TbTAmp, FOFBAmp, FAcqAmp},
   acquire all BPMs [*];
   pick any antenna (counters are replicated in {A, B, C, D}) and check if data across all BPMs is equal.
   If data isn't equal, the phase syncing procedure for this acquisition rate should be redone.
4. Disable synthetic data generation.
   caput $(P)$(R)TestDataEn-Sel disable

[*] There's a known bug for acquisitions higher than 2046 samples, so one should use < 2046 for this step.

Check waveform calculation in

implementation of the method below has to be checked:

dev-packages/siriuspy/siriuspy/pwrsupply/siggen.py

Line 132 in 9f33fcf

def get_waveform(self, nr_points=100):

this method generates a waveform that corresponds to the signal generated in the power supply, given definition of the siggen configuration parameters.

siriuspy test_factory does not mock server or PS IOC connections

Create unittest for MASearch.conv_psname_2_maname

How to read Sync computed PVs?

should we take the average of the sync PV values or keep the readout of the first PV, as it is now ?

SiriusPVTimeSerie

dev-packages/siriuspy/siriuspy/epics/pv_time_serie.py

Line 1 in adbe62d

"""SiriusPVTimeSerie Class."""

@anacso17 , while going through siriuspy various modules for clean up code, I noticed that SiriusPVTimeSerie does not implement PV-type functionality, as all the other modules in siriuspy.epics subpackage do. It merely uses one of its attributes of type PV to implement its methods. None of its methods implements PV methods. The class is like any other class that connects to PVs...

I think this module does not belong to this subpackage. What do you think? It looks like it could be implemented as a Device class...

Rename util.check_public_interface_namespace

so as to indicate that the function checks only statically defined symbols, and not those created upon execution of class constructor or other methods.

Power supply controller parameters

• There are a number of power supply parameters that the IOC can read/set through the serial line, such as PS_MODEL, SigGen default parameters, etc. See power supply BSMP spec, table "Parâmetros" for a complete list.
• we should discuss what parameters of this list we want to expose to clients in the control-system.
• we have to create code in siriuspy to manipulate such parameters

initial Epics DB value for strengths

Implement in csdevices correct initialization of strength limits and initial values.

Problems on starting MA services

Some MA services return this error message on start:

   File "/home/fac_files/lnls-sirius/dev-packages/siriuspy/siriuspy/factory.py", line 31, in factory
        return MagnetPowerSupply(maname, use_vaca=True)
   File "/home/fac_files/lnls-sirius/dev-packages/siriuspy/siriuspy/magnet/model.py", line 268, in __init__
       self._strength_obj = create_magnet_normalizer(self)
   File "/home/fac_files/lnls-sirius/dev-packages/siriuspy/siriuspy/magnet/model.py", line 242, in create_magnet_normalizer
      dipole_name=magnet.dipole_name,
AttributeError: 'MagnetPowerSupply' object has no attribute 'dipole_name'

BSMP execute_function does not treat error commands

BSMP execute_function sends a message with command 0x50 and handles message that have command 0x51and 0x53. It does not handle the case when the returned message has and error command (0xE3, 0xE5, ...).

Limit checks on WfmData-SP

at this point we are not performing limit checks on wfmdata at high level classes (MAEpics, PowerSupply, ControllerIOC). we have to implement it! thanks, @fernandohds564 , for pointing this out!

Implement IOCs that communicate with DC-Link PS modules

Discussion FAC(Ximenes)-ELP(Gabriel, Allef)

• Each power supply (PS) needs a module called DC-Link from which it takes a reference DC tension signal to build its current output. Sirius has two types of DC-Links: a) commercial and b) home-made.
• Some PS types have dedicated DC-Links and other PS types share DC-Links amongst the power supplies in the same rack module
• For those PSs with dedicated DC-Link ELP group will develop libraries for the comm between the PS controllers and teh DC-Link which will read/write DC-Link parameters and expose these methods to the IOC as PS controller BSMP variables, be then commercial or home-made DC-Links.
• It is desirable for diagnostics purpose that read/write parameters of DC-Links be available from EPICS control-system, although the PSs can work in normal conditions without exposing these parameters to the control-system.
• For PSs sharing a DC-Link, it will be very awkward to define such communication libraries, according to the ELP group. They have requested that the IOC take the role of communicating with the DC-Link.
• In order to extend the current version of the IOC code to accomplish comm with DC-Links, there are two cases to be considered: 1) for shared home-made DC-Links, the communication can be implemented in such a way that the DC-Link is viewed as an additional BSMP slave. 2) for the commercial version, the comm libraries should use an Ethernet based protocol and be implemented from scratch.
• Commercial DC-Links have Ethernet libraries provided by the vnedor that can be used for diagnostics. Thus the exposition of the DC-Link parameters to the control-system can be implemented in a latter moment.