Ответы на вопросы в отношении к системе карботрона

Ответы на вопросы в отношении к системе карботрона.
1. Какие операции там предусмотрены: запрос 1 числа из АЦП, запись 1 числа в ЦАП,
а еще?
Совершенно верно, эти оба и еще кое-что. Далее перечислю все запросы. Предварительно в
табличке привожу раскладку по управляющим и диагностическим машинам.
Число
Назначение
Особенности
машин
1. Управление инжектором: источники ионов, тандем, канал между 1
Обычная PC с
ионными источниками и тандемом и канал между тандемом и
cPCI крейтом
бустером
2. Управления бустером, инжекцией в и выпуском из бустера и 1
Обычная PC с
каналом между бустером и синхротроном, впуском в синхротрон
cPCI крейтом
3. Управление основным синхротроном, кулером и выпуском из 1
Обычная PC с
синхротрона
cPCI крейтом
4. Управление каналами облучения, развертками и гантри
1
Обычная PC с
cPCI крейтом
5. Диагностика пучка в инжекторе и бустере
1-2
Контроллер
VME
6. Диагностика пучка в синхротроне, каналах между бустером и 5-6
Контроллер
синхротроном и каналах облучения
VME
7. Диагностика вакуума и температуры на всем комплексе
1
Обычная PC с
cPCI крейтом
Любопытно, что контроллеров VME будет больше, чем писишек. Поэтому выбирать контроллер (с
точки зрения установки Linuxа) надо очень аккуратно.







1. Типы запросов, которые должны быть реализованы для всех серверных программ.
(1.1) чтение 1 числа из АЦП (или иного измерительного модуля) с вещественным
представлением в сервере в физических единицах. Вещественное представление в сервере
избавит многие клиентские программы от извлечения пересчетных коэффициентов и работы с
ними. Все серверные программы синхронизируют обращения к аппаратуре с работой
установки. Т.о., для инжектора и бустера частота обслуживания запросов составляет 10 Гц.
(1.2) чтение 1 числа из АЦП и передача числа клиенту в непрерывном установленном режиме
(по подписке) с проверкой, существует ли приложение, заказавшее данное чтение. Такой
режим необходим для наблюдения за стабильностью работы устройств. Возможно, при этом
другие запросы на чтение данного канала потребуется блокировать.
(1.3) запись 1 числа в ЦАП. Клиентская программа заказывает запись величины, сервер делает
проверку на максимум (и минимум?), своевременно (синхронно с работой установки) заносит
в ЦАП код и, если требуется, инициирует отработку кода. После этого клиенту отдается
сообщение об отработке.
(1.4) чтение 1 числа из ЦАПа с вещественным представлением в сервере в физических
единицах. Запрос требуется для восстановления режима работы установки и настроек
различных модулей из самих устройств (ЦАПов).
(1.5) чтение бита или комбинации битов из цифрового канала ввода или вывода. Это каналы
включения/выключения, отображения состояния контактов, блокировок.
(1.6) запись бита или комбинации битов в цифровой канал вывода (каналы
включения/выключения)
2. Типы запросов, специфичные для программ управления инжектором и бустером с циклом
работы в 100 мс):
(2.1) чтение N значений из АЦП с вещественным представлением в физических единицах. N –
число циклов работы инжектора (бустера) в одном сеансе накопления в синхротроне. N может
меняться от сеанса к сеансу. Команду об окончании сеанса накопления серверные программы
инжектора и бустера получают извне от системы проверки накопленного тока. Число циклов



N, информация о которых хранится и обрабатывается в серверах, должно быть ограничено.
При длительной настройке инжекции и превышения этого ограничения в сервере должны
храниться, соответственно, последние N значений.
(2.2) чтение 1 усредненного по N значения из АЦП с вещественным представлением в
физических единицах. Требуется для отображения информации о сеансе накопления на
дисплеях, а также для фиксации режимов работы установок.
3. Типы запросов, специфичные для управления ВЧ системами (для серверов управления
бустером и основным синхротроном).
(3.1) загрузить таблицу для отработки в канал DDS (разработки Селиванова)
(3.2) прочитать таблицу отработки из канала DDS
4. Типы запросов, специфичные для программ управления бустером, основным
синхротроном, каналами облучения, кулером и гантри:


(4.1) загрузить таблицу для отработки в канал ЦАПа-интерполятора Козака
(4.2) прочитать таблицу отработки из канала ЦАПа-интерполятора Козака
5. Типы запросов, специфичные для программ управления основным синхротроном,
каналами облучения, кулером и гантри:



(5.1) запустить отработку таблицы ЦАПа-интерполятора Козака
(5.2) остановить отработку таблицы ЦАПа-интерполятора Козака
(5.3) продолжить отработку таблицы ЦАПа-интерполятора Козака. Два последних запроса
нужны для настройки режимов ускорения пучка и режимов снижения по энергии в
синхротроне
2. Как делается считывание быстрых АЦП, CCD?
Для чтения «быстрых» АЦП – имеется в виду АЦП с памятью (типа осциллограф) предусмотрены два режима работы с данными. Первый режим – просто чтение АЦП и передача
данных в ответ на запрос с такого-то адреса по такой-то. Такой режим используется, например,
для отображения графика изменения значения параметра во времени. Второй режим – некая
обработка прочитанных измерений и передача в ответе на запрос результата этих вычислений
(например, усредненного по нескольким точкам значения, разности между какими-либо точками и
т.п.). Пкркметр, являющийся результатом измерений описывается как измерительный канал.
Поскольку обработка данных, как правило, несложная и всегда предваряется чтением, то в
драйвере АЦП нужно сразу совместить и чтение АЦП и обработку. Настройка драйвера
осциллографических измерений записывается в конфиг в виде текстовых строк, в них указывается
с какого адреса по какой читать осциллограф и какие операции выполнять с прочитанными
данными. Старт АЦП делается аппаратно внешним импульсом.
Чтение CCD нужно выделить в отдельный процесс, в который закладываются соответствующие
обработки, если из изображения нужно извлекать какие-то параметры пучка. Эти параметры пучка
должны быть описаны, как измерительные каналы. В случае запроса значений этих параметров
сервер должен извлечь их из сисидишного приложения. Соответственно, в случае запроса на
настройку чтения CCD сервер должен настроечные параметры передать в сисидишную
программу.
3. Работа с внешними запусками, синхронизация нескольких устройств/драйверов,
«команды» – типа управления ШД?
Для синхронизации сервера предусмотрен модуль типа «регистра прерываний». Виталий сейчас
подобрал модуль TPMC680. Драйверы могут также быть привязаны к прерываниям, поступающим
от модуля, либо сервер, дождавшись соответствующего прерывания, должен «подтолкнуть»
нужные драйверы. Можно также устроить синхронизацию сервера по сработавшему АЦП (если
оно в формате PCI), но тут меньше возможностей по «раскладке» во времени, т.к. в модуле
прерываний мы можем использовать несколько разнесенных по времени прерываний.
Управление шаговыми двигателями выполняется отдельными процессами. Эти процессы
выполняют операции по отработке заказанного числа шагов с запоминанием текущего суммарного
значения сделанных шагов. Число шагов для отработки заказывается клиентской программой
серверному приложению в физических единицах (мм, градусы) как уставка в канал управления.
Сервер передает запрос на отработку уже в выражении числа шагов соответствующему процессу
от которого после отработки получает значение суммарного числа сделанных шагов как
измеренное значение, которое в сервере пересчитывается в физические единицы. Т.е. для
управления шаговым двигателем предусмотрено два основных канала: управляющий канал, в
который для отработки задается разовое перемещение механизма, и «измерительный» канал, в
который после отработки попадает суммарное перемещение механизма. При рестарте процессов
управления шаговыми двигателями необходимо предусмотреть процедуру определения текущего
положения механизмов подстроек относительно концевых выключателей. Также должны быть
предусмотрены дополнительные каналы управления для настройки режимов работы шаговых
двигателей (частота, разгон, торможение).
4. Как устроена «временнАя» диаграмма – данные отдаются сразу по готовности, в
конце некоего цикла, с некоей частотой (указываемой где – в конфиге сервера или
в запросе клиента?), по изменению, еще как-то?
В системах с циклом работы в 100 мс (инжектор и бустер) данные из всех АЦП должны
вычитываться по синхропрерываниям каждый цикл и обрабатываться сервером (складываться в
массивы, усредняются по числу циклов). В случае появления запросов, данные просто отдаются в
ответ на запрос. Алгоритм опроса измерительных каналов закладывается в сам сервер. В конфиге
указывается, по какому прерыванию какие типы каналов нужно обслуживать. Если клиентской
программе понадобится «непрерывный» контроль, то она должна сформировать запрос (1.2). В
этом случае сервер обеспечит непрерывность измерений данного канала.
В системах с неопределенным по времени циклом работы (основной синхротрон, каналы выпуска,
гантри, кулер) чтение измерительных каналов выполняется по появлению запроса.
Наверно, не стоит заниматься непрерывным чтением всех каналов, чтобы заменять в сервере
значение каждого канала по его изменению.
5. Какие типы данных поддерживаются (целые, вещественные, …)?
Кажется, что правильно в сервере хранить числа в физических величинах, чтобы клиентские
программы не занимались какими-либо преобразованиями код <-> физическое значение. В этом
случае все равно остается и целочисленный формат, например, для каналов ввода/вывода.
6. Как там сделана работа с нескалярными типами – массивы, структуры?
Это вопрос нужно обсудить и разобрать на примерах.
Массивы предполагаются в нескольких случаях: чтение осциллографов (тогда они в двумерном
виде «храняться» в драйвере), чтение/запись табличных массивов для отработки в ЦАПы (массив
тоже передается и хранится в драйвере).
Про структуры не понял, что имеется в виду.
7. Протокол клиент-сервер – на основе чего (локальный, TCP, UDP, …), для каких
языков есть реализации, насколько они встраиваемы в «сторонние» клиентские
программы, есть ли встраиваемая в «сторонние» программы реализация сервера?
Сервера нужно разрабатывать под нашу систему, протокол клиент-сервер тоже надо
разрабатывать. Наверно, на основе TCP. Наша система не должна получиться громоздкой, чтобы
могли возникать большие задержки при передачах. Конечно, было бы хорошо разобраться, как
устроен протокол, например, для TANGO, чтобы понять, можно ли устроить понимание запросов
клиентов от TANGO, чтобы была возможность воспользоваться их клиентами и нашими
серверами.