DiamondLightSource
User memory traj buffer
Currently PowerPMAC trajectory is using global variables (P-variables), that has a restricted number of elements and, in Diamond context, is shared by other applications - e.g. PLCs.
On PowerBrick, by default 1 MB allocated for User Shared-Memory (USHM), being possible to extend that up to 64MB.
Looks good overall. I just suggest a few extra comments to explain the data structure. Thanks
On the G13 powerbrick, run a 400Hz scan with the P variable approach and measure CPU usage, then do the same with this approach and measure CPU usage, then if the user memory is no worse then merge this
On the G13 powerbrick, run a 400Hz scan with the P variable approach and measure CPU usage, then do the same with this approach and measure CPU usage, then if the user memory is no worse then merge this
@coretl, is malcolm enough for that tests, or are you considering something else, like ruckig?
Using ophyd-async, it was used 0.0004s per frame, which results in a trajectory of 5 kHz. For both scenarios (P-variables and user shared-memory), the tests were done using a buffer of 1000 points, for a single simulated motor, and a few conditions were considered: Disable ppSaveSync Python script, which occupies the background thread Disable the segmentation Disable the look-ahead Disable Encoder-Conversion-Tables from, including the EncTable[9] - that reduces the computational load on servo thread, by disabling unused encoders
The following configuration were used for each task clock: Phase: 20 kHz Servo: 10 kHz RT Interruption: 5 kHz
P-Variables: Sys.RtIntBusyCtr = 6 Sys.RtIntError = 0 Sys.MaxBgTime = 129.92 us Sys.RtIntTime = 284.08 us Sys.MaxServoTime = 44.40 us Sys.MaxPhaseTime = 10.40 us
User Shared-Memory: Sys.RtIntBusyCtr = 1 Sys.RtIntError = 0 Sys.MaxBgTime = 86.23 us Sys.RtIntTime = 225.92 us Sys.MaxServoTime = 34.00 us Sys.MaxPhaseTime = 6.32 us