Present: Jorg Wenninger, Ralph Steinhagen, Lars Jensen, Rhodri Jones, Mike Lamont, Michel Jonker, Thijs Wijnands, Stephen Page, Quentin King, Jens Andersson (minutes), Kris Kostro
Mike wondered about acquisition, to which Lars replied that the BPMs are as before (that is, 4), and will remain like that until June-July.
Lars also pointed out that the triggering is not connected to the BST: the 10 Hz sampling might be on slightly different time offsets from cycle to cycle (but the actual cycle time is, as before, delivered together with the data). Jorg said that this would probably be no problem unless some very accurate comparison between cycles needs to be done.
Jorg showed some slides about his plans. Ralph has recently arrived and will also work with the controller. Jorg is looking into the modelling, which is easy for the magnets but more complicated for the power converters. Thijs wondered if he had looked at noise, which he hadn't yet.
MD time has been requested, and it will probably also be possible to do some tests when other people (RF) are using the machine.
Jorg was interested in making the loop faster, or at least the acquisition, to see how fast it can be done.
7-8 correctors are planned to be used, all in the same Mugef crate. (Possibly ~10 needed, Jorg adds.)
For displaying the BPM values, Serguei's program will be used as before. Some modifications required to add more BPMs than the current 4.
Jorg would like some simple way of tweaking the controller while running, and will discuss this with Jens. A "hot-swap" of the config file was sufficient for the coming May run. In the future a GUI application could be used for this. Displaying the applied corrections was not urgent, logging them (together with the BPM data) should be enough for now.
When speaking of correctors, it was decided that Jens should, together with Michel, send a couple of corrections (UDP packets of a certain format) to a Mugef crate and verify that it accepts and applies it.
For the scrubbing run starting on the 4th of May, there are no requirements either to collect any measurements or to do any corrections. However, it should be attempted on a best-effort basis to try out that things work like they should.
More or less any decent computer with a TG8 card should do for the first tests. It was decided that Jens should check out locba5 and qlsba3 which have been used earlier, and see if they have TG8 card (and have not been removed). Michel suggested that one of the ROCS machines could be used to send data to one of the others, if there were problems finding a suitable computer. (Update:
Mike took up the subject of the Multipole factory, which had been discussed in Chamonix. This is feed-forward corrections calculated from reference magnets, and they will compete with the orbit correctors for the same power converters. Some sort of system needs to be constructed to handle this, or at least to take it into consideration now.
Thijs added a third actor: operators which manually want to apply corrections.
Quentin was open to either a reserving system, or if it was really requested, any system that merged these corrections according to some method. However, he preferred if this was handled outside the power converter "front door", so that it could restrict its work to allowing users to reserve correctors and then send corrections. It was agreed it should be handled in this way.
Quentin also informed about the framework Stephen already have made, which has features like XML description of device/properties, CMW, TCP and UDP communication support and diagnostics/monitoring. If anyone was interested they might be willing to share it, but did not promote it as a solution.
Thijs mentioned tune as another problem, but this was regarded as more easily handled, since it is just a few input values and not as coupled as the orbit.
// Figure: three users talking to one question-marked box, this box merging their wishes and talking to the power converters //
Quentin emphasized that the return data flow from the power converters must be handled. They can indicate clamped voltage and/or current, and users should take this into account to avoid control systems which flip out when the power converter gets saturated.
Michel suggested that specified limits should be put on the user's controller so it never causes the power converter to clamp.
Kris asked for some sort of reliability figures. Jorg mentioned 1 correction lost per 100 would be alright. Regarding lost BPMs or power converters: Jorg had an idea about a background task detecting this and calculating a new matrix using SVD, and then switching to that as soon as possible. What to do while BPM values are missing remains to be decided.
Quentin requested information when available from Jens and Kris on the coming system for reserving power converters, sending commands to them and returning error conditions. Stephen will move on to this area soon.
Mike encouraged people to think about what's required until next meeting.