Форум: Техническая поддержка

Подскажите пожалуйста.
Есть задача реального времени для LTR-EU - управлять температурным полем печи.
Для ее решения требуется изменить встраиваемое программное обеспечение.
Конкретно - во встраиваемое ПО вставить четыре терморегулятора.
Для решения задачи необходимо иметь:
1) Иметь внутреннее прерывание от таймера для синхронизации процессов регулирования.
2) Иметь возможность передавать из хоста в тело программы дополнительную информацию.
(т.е. возможность первоначальной настройки терморегуляторов и возможность изменения режимов в процессе
  работы терморегуляторов).

В Вашем документе "Особенности разработки встраиваемого ПО для крейта LRT" -
я не нашел ответа на мои вопросы.
Функций put_host_data и put_module_data недостаточно для решения задачи.

Есть ли незадействованное прерывание и незадействованный таймер в крейте.
Есть ли готовые функции для настройки таймера и контроллера прерывания.
И есть ли готовая функция для передачи параметров в тело программы пользователя из хоста по USB.

Владимир, для оценки самой задачи реального времени дополните свой вопрос следующей информацией:
- состав LTR модулей, работающих на ввод (для измерения) и на вывод (для управления); 
- количество каналов измерения и управления;
- требуемое время реакции от входов измерения до выходов управления;
- скорость сбора данных по каналам измерения;
- скорость вывода данных по каналам управления;
- LTR-EU должен работать автономно без ПК или с постоянной связью с ПК? Если последнее, то через какой интерфейс (USB или Ethernet), и какова здесь должна быть роль ПК?

Гарманов Александр >>
Владимир, для оценки самой задачи реального времени дополните свой вопрос следующей информацией:
- состав LTR модулей, работающих на ввод (для измерения) и на вывод (для управления); 
   измерение  LTR11
   измерение  LTR27
   управление LTR34-8
   вспомогательные функции опроса  LTR41 .
   вспомогательные функции управления LTR42.
-  количество каналов измерения и управления;
    Измерение   LTR11 до 16 каналов  (возможно 32 при двух LTR11)
    измерение  LTR27 (термометры сопротивления от 6 до 8 )
    Управление LTR34    от 4 до (пока не определено, но не более 6)
-  требуемое время реакции от входов измерения до выходов управления;
    В соответствии с циклограммой работы.
    Каждому каналу управления будет соответствовать
    от 2 до 4 каналов измерения LTR11.
    В зависимости от требуемой скорости вывода от 20гц до 300 гц.
    Каждому такту вывода будет соответствовать 10 тактов ввода.
    При наступлении такта вывода вся собранная информация должна обрабатываться и
    вычисляться управляющие воздействия на каждый канал и выдаваться в этом же такте.
    Задержка равна времени вычисления управляющего сигнала.
           
- скорость сбора данных по каналам измерения;
    Измерение LTR11 до 3 кГц.

- скорость вывода данных по каналам управления;
    Выходы от 20гц до 300 гц.

- LTR-EU должен работать автономно без ПК или с постоянной связью с ПК? Если последнее, то через какой интерфейс (USB или Ethernet), и какова здесь должна быть роль ПК?
   Соединение с ПК постоянно через USB (но возможно и через Ethernet при удалении компьютера).
   Роль компьютера:
   1) сбор статистики(протокол) 2 раза в секунду по всем каналам измерения и управления.
   2)
      a) Изменение параметров регулирования - задание температур.
         (не чаще чем 1 раз в секунду из файла заданий).
      b) Изменение коэффициентов в зависимости от диапазона температур
         и параметров экспериментального образца.
         (не чаще чем 1 раз в секунду из файла заданий).
     
   3) Настройка регуляторов на конкретные образцы (подбор коэффициентов)
      на этапе первичных испытаний и корректировка заданий и коэффициентов
      в процессе работы.

Владимир, Вы не дали принципиального ответа на вопрос о требуемом времени реакции (задержки) конкретных выходов относительно конкретных входов.
Дело в том, что в LTR-EU на ввод данных - глубокая буферизация (буфер FIFO, см. описание архитектуры в руководстве пользователя),
в LTR34 - глубокая буферизация на вывод (буфер FIFO) - см
см. описание LTR34 в руководстве пользователя).
- В этих условиях, если требуется  время реакции, сравнимое с несколькими периодами дискретизации, то требуется работа с постоянным опустошением буферов FIFO - это особые жесткие условия к ПО низкого уровня.
Кроме того, LTR27 - это медленный модуль (типично частота сбора данных F= 5 Гц) с относительно большим временем задержки  из-за  глубокого усреднения отсчётов при обработке.
Всё это требует осмысления с Вашей стороны физического требуемого времени реакции от входов до выходов, иначе непонятно ради чего накладывать крайне жесткие условия работы низкоуровневого ПО в условиях, когда Блэкфину ещё понадобится обрабатывать запросы от USB или Ethernet и поддерживать логику (ресурсы) этих стеков.

Александр, к скорости работы LTR27 претензий нет.
Он используются для измерения температуры холодных концов термопар.

Стеки можно опустошать в каждом следующем периоде дискретизации, переписывая их в свой буфер для дальнейшей обработки.
Через каждые 10 периодов дискретизации (допустимо с задержкой на один период дискретизации) будет производиться вычисление управляющих сигналов.

Эти 10 периодов дискретизации используются для снижения влияния случайных помех, дополнительная фильтрация показаний (это для термопар опрашиваемых с периодом 200Гц).
Про дискретизацию 3000гц это три дополнительных входных канала, к термопарам отношения не имеют ,
это вычисление дополнительного коэффициента, который будет использоваться при
выработке управляющего сигнала с частотой 300Гц.(опрос термопар будет прежним 200гц)

Обмена по USB , будет немного.
Постоянный обмен это статистика(протокол работы) до 32 показаний два раза в секунду.
Вмешательства в работу исследователя-экспериментатора не так часты.
Файл заданий может быть сразу переписан в память LTR-EU для снижения критичности обмена по USB.

Отсутствует ответ на принципиальный вопрос о требуемом времени реакции конкретных выходов LTR относительно конкретных входов LTR для данной задачи реального времени. Без этой информации, всё равно, невозможно дать оценку возможности сделать это средствами LTR. А без этой оценки вопросы по низкоуровневому программированию LTR выглядят бессмысленными...

Александр

Описание задачи:
Объект нужно неравномерно нагревать и охлаждать в заданных временных рамках.
Причем четыре точки одного объекта должны иметь различную температуру, меняющуюся  во времени.
Изменение температуры в различных точках должно производиться согласно задания и очень точно поддерживаться в динамически изменяющемся температурном поле.
Изменение температуры каждого нагревателя по разному влияет на изменение в различных точка объекта. Нагреватели оказывают взаимовлияние на различные точки объекта ( оказывают паразитные возмущающие воздействия на различные точки объекта, через тепловые потоки внутри самого объекта).

Описание работы(упрощенный взгляд):
В пределах одного такта 5мс осуществляется сбор информации с 12 термопар(по 3(три) на каждый выход расположенных непосредственно в зоне нагрева + 9 термопар смежных нагревателей) и эта информация записывается в отдельные циклические буферы и и это повторяется в течении 10 тактов.

После это происходит вычисление управляющих сигналов  с задержкой в 1 такт 5мс.

Задача работает по циклограмме сначала идет сбор информации в течении 10 тактов с частотой 200 гц. (5мс)
По прошествии 10 тактов (50 мс), производится вычисление управляющего сигнала.
Каждый из четырех нагревателей производит вычисление на основе показаний 12 термопар.
(три своих + девять смежных) + математическая модель поведения температурного поля объекта изменяющегося во времени рассчитываемая на основе прогнозирования поведения объекта от воздействия управляющих сигналов.
Математическая модель рассчитывается не на основе задержек конкретного выхода от конкретного входа, а на основе циклограмм расчетов реального времени.
К моменту наступления момента расчетов и выдачи управляющих сигналов вся информация собрана.

Считайте максимальная задержка выработки управляющего сигнала, 1 такт = 5 мс, считая от последнего такта сбора информации.

Например, при времени преобразования  200 мс (5 Гц) в LTR27  как уложиться в 5 мс?

Александр.
Скорость изменения температуры холодных концов термопар изменяется очень медленно, они далеки от точек объекта управления. И необходимы только для поправок влияющих на точность измерения. Один раз в секунду запишутся, в виде показаний и будут использоваться без изменения до следующего считывания.

Александр если Вы решили устроить мне экзамен, то сообщу Вам следующее.
Я инженер электроник, программист с некоторыми познаниями в теплотехнике.

Семь лет назад я дорабатывал программу для крейта прошлого тысячелетия.
Старый крейт выпущен Вашей фирмой.
Этот крейт управлялся(ется) через параллельный порт(внешнее управление), программой работающей под DOS-6.22
И долгое время программа удовлетворяла людей.
В старой печи всего три нагревателя.
При 10 разрядных ЦАП-ах.
Качество регулирования (заметьте не измерения) удовлетворяло заказчика.

Но время движется, выставляются новые требования к задачам и качеству регулирования.
Придется полностью перерабатывать проект, под новый крейт.

Новый проект должен учитывать кучу возмущающих факторов, о чем я Вам писал.
Иначе не удержать термический процесс в заданных рамках.
Идеологию управления и математическую модель придется разрабатывать самому.

Так вот, прежде чем взяться за новый проект, а я уже достаточно долго готовлюсь к нему.
В том числе почитываю документацию по BlackFin.
Я должен быть на 100% уверен, что проект состоятелен.

Если Вы дадите намеки на подводные камни с которыми я могу столкнуться то это будет использовано.
Но внешнее управление крейтом тут не подойдет.

Не думайте, что получив от Вас дополнительную информацию я тут же сломя голову кинусь создавать проект.
Я человек неспешных решений и прежде чем начать писать 1000 раз взвешу, правильно ли я построил модель.

Сейчас идет продолжение подготовительного процесса накопления информации и осмысления с чем придется столкнуться.

Просто не хочется наделать ошибок.

Владимир, у меня нет намерения устраивать Вам экзамен.
Во-первых, я действительно не могу понять допустимую задержку реакции управляющего воздействия, которую требует Ваша физическая задача. 
Во-вторых, я вижу, что Вы явно не учитываете архитектуру LTR-EU (см. руководство, глава 4), в которой вся периферия (модули ввода-вывода) связаны с Blackfin через FIFO буфера (очереди - одна на ввод и одна на вывод - с задержками буферизации), а не через "общую шину".  Я думаю, что под DOS 6.22 можно получить существенно меньшее время реакции (через регистры устройств на шине ISA), чем при работе в LTR-EU с  Blackfin через FIFO-буфера и механизм потокового DMA. Кроме того, у самих модулей LTR есть время преобразования и свои задержки буферизации (например, LTR34 имеет свой буфер FIFO для осуществления синхронного вывода).
C одной стороны, LTR-EU не проектировался для жесткого Real-Time. C другой стороны, о чём я писал выше, я не понимаю какие реакции вход-выход требует Ваша теплотехника.
По моим понятиям (не теплотехника) реакция системы управления 0,2 с для тепловых процессов - более, чем достаточна, если Вы, конечно, не занимаетесь скоростной динамикой взрыва или чем-то в этом роде...
Кроме того, неясно  какой LTR-модуль для какого канала измерения-управления будете применять.  LTR11 без предусилителя для термопар не может быть применён. LTR34 может быть применён, в том числе, и для асинхронного вывода, если не копить в его буфере отсчёты. LTR42 может работать только асинхронно (рекомендуемый режим - с ожиданием подтверждения на каждое управляющее слово).

Александр
Про асинхронный режим вывода я прочитал и хотя он не описан в самом LTR34 там только упоминается о нем. Его работу можно понять из описания LTR35 (стр.250)

Как я понял.
Время реакции в асинхронном режиме(при пустом FIFO) зависит только от того как запрограммирован модуль. Эти задержки исчисляются в микросекундах при большой частоте опустошения буфера.

Функция put_module_data помещает данные в выходной буфер крейта FIFO для указанного модуля(LTR34).
Из буфера крейта эти данные  с частотой синхронного вывода модуля LTR34 переписываются в сам модуль LTR34.

Если каждые 50мс в буфер вывода LTR34 помещать по 4 отсчета(по одному на каждый выход) то этот буфер будет постоянно пуст т.к. скорость опустошения(переписывания данных в сам  модуль) будет выбрана значительно выше. Этим и будет обеспечено отсутствие критичных задержек.

По поводу 0,2 сек, это может быть и достаточно для процессов некритичных к качеству регулирования. Просто 0,05 сек позволяет более точно дозировать тепловые порции энергии и легче реализовать механизм дифференцирования регулятора, не ломая при этом накопленный интеграл.

- При пустой очереди FIFO на вывод - именно так.
А если, допустим, забить очередь на вывод словами  для медленного модуля LTR42, то вставшие следом в очередь слова для LTR34 дойдут до него тогда, когда очередь освободится.
Аналогично, с очередью на ввод. Если Blackfin её не откачивает, то отсчёты АЦП будут задерживаться (очевидно).

Вообще, система с временем реакции 50 мс на LTR-EU вполне может быть реализована, если не допускать значительного накопления вышеупомянутых очередей.

Режим асинхронной  работы с LTR34 с опустошённым буфером многократно обсуждался в этой конференции.

Для организации оптимального трафика на вывод следует учитывать следующие параметры:
Скорость забора данных из приёмной очереди:
- 25 КСлов/c для "медленных" модулей LTR27, LTR4x, LTR212, LTR11, LTR22.
- 500 КСлов/c для "быстрых" модулей LTR34, LTR35, LTR210, LTR24, LTR25.
- Кроме общей очереди на вывод, данные проходят через индивидуальный  буфер FIFO на приём на 10 слов - у каждого модуля.
(Под словом подразумевается 32-х битное слово LTR. Режим "медленной", "быстрой" откачки данных из буферов на передачу должен установить BlackFin для каждого посадочного места крейта, когда он получит отклик на RESET от каждого модуля - MID - и определит какой модуль LTR на каком месте находится).

Исходя из этого, оптимальная организация потока на вывод выглядит примерно так (чтобы иметь наименьшее время ожидания в очереди):
1. Последовательно в любой модуль LTR следует ставить в очередь не более 8-ми слов.
2. В среднем слов к "медленному" модулю должно быть в очереди в 20 меньше, чем слов к "быстрому" модулю.
Таким образом, если BlackFin будет перемешивать данные на вывод разных модулей, исходя из вышесказанных параметров, общая очередь на вывод никогда не будет тормозить, если не превышать средний трафик откачки данных каждого модуля.

Общая задача низкоуровневого программирования LTR-EU с оптимальной реализацией времени отклика алгоритма управления выглядит как "система массового обслуживания", в которой нужно решать 5 основных задач:
1. Вовремя откачивать очередь на ввод.
2. Ставить данные в очередь на вывод с учётом перемешивания (как объяснено выше).
3. При необходимости, осуществлять пост- обработку данных на ввод или пред-обработку данных на вывод, которая делалась бы на верхнем программном уровне в ПК (коррекция данных, в соответствии с калибровочными коэффициентами - в LTR27, LTR11, LTR22, LTR34), если бы обработка осуществлялась в ПК.
4. Осуществлять обработку данных и алгоритм управления, согласно основной задачи.
5. Обрабатывать запросы от интерфейса ПК (USB или Ethernet), если связь с ПК нужно поддерживать на фоне, обслуживать передачи данных по интерфейсу.

Вероятно, при оптимальной организации можно достичь времён реакции - единицы мс, не считая времени преобразования в модулях (оптимистичный прогноз). Считаем, что 50 мс - это реалистичный прогноз.

Если требуется поддерживать синхронный потоковый режим вывода LTR34, то возникает 6-ая задача обработки информации от LTR34 о состоянии его буфера и коррекции трафика  для LTR34 на вывод (эту задачу решал бы LTR-сервер, если работать через ПК).

Александр

1) Уточните пожалуйста в какую очередь ставит отсчеты функция "put_module_data" в общую или посылает отсчеты сразу в индивидуальный  буфер FIFO организованный для каждого модуля ?

Ответ очевиден, поскольку невозможно послать данные "сразу в индивидуальный  буфер FIFO, организованный для каждого модуля", в обход общей очереди. Во всех крейтах сохраняются пути данных, см. руководство , рис. 4-3 (нижний рисунок). Это означает. что очередь на вывод - двухуровевая: первый уровень FIFO - всегда общий, второй уровень (малые FIFO 10 слов) для каждого LTR модуля - индивидуальный.
Замечу, что если LTR проектировался бы для "жесткого реал-тайм", то, как минимум, пути данных ввода и вывода были бы разделены  для каждого модуля...
Статья по буферизации данных:
http://www.lcard.ru/lexicon/buffering

Также могут быть интересны следующие статьи:

• Начиная работать с крейтовой системой LTR. Вопросы по программному обеспечению.

• Какие устройства "Л Кард" сбора данных и управления содержат процессор для Real-Time задач?

• Являются ли изделия "Л Кард" законченными решениями для пользовательских применений?

• Тупиковые реализации "задачи реального времени"— как избежать?

• Можно ли обрабатывать данные от АЦП на ПК в реальном времени, отсчет за отсчетом?