В документе "Крейтовая система LTR. Руководство программиста"
в разделе

3. Дополнительная информация о взаимодействии крейт – LTRSERVER

написано:

При чтении данных из LTR крейта
...
3. Прием данных ltrserver – задержка не более 10 мс. ( в зависимости от версии сервера задержка может или увеличиваться или уменьшаться, для сервера начиная с 1.4.5.8 время задержки уменьшено до 7 мс).

Пож. поясните: о какой задержке идет речь?

Означает ли наличие задержки, что при выполнении команды
LTR**_recv() в приемный буфер поступят данные, измеренные 7-10 мс назад?

Данные приведены для версии ltrserver 1.4.5.8

Сейчас версия ltrd-сервера 2.0.0.7.

Где можно прочитать изменения, проводимые в достаточно часто обновляемом  архиве
https://bitbucket.org/lcard/ltr_cross_s … dk_src.zip ?

спасибо

Пакет

Леонид, по программным вопросам ответят коллеги, я поясню только по поводу архитектуры устройств.
1. В контексте названия темы "Задержки при чтении данных из LTR-крейта"  - задержка в отдельно взятый момент времени также зависит от задержки ОС, а также от количества не откаченных данных в буфере крейта LTR, если пропускной способности интерфейса не хватает (по тем или иным причинам), чтобы всегда по максимуму откачивать данные из буфера, минимизируя эту составляющую задержки от крейта LTR.  Если с крейтами  LTR-U-8/16, LTR-EU-2/8/16 работаете,  то в их буфере ведь мегабайты данных могут скопиться, если интерфейс тормозит (даже при самом совершенном LTR-сервере).
http://www.lcard.ru/forums/img/members/ … a_path.png
2. Леонид, я рекомендую Вам сформулировать для рассмотрения конкретные временнЫе требования Вашей задачи по синхронизации (подробно указав состав системы, тип интерфейса, необходимые скорости  передачи от каждого модуля).
В частности, если задача состоит в том, чтобы привязать отсчёты собираемых данных к реальной шкале времени, то можно, например, использовать механизм синхрометок в LTR c запуском меток от того или иного события...

При виброизмерениях с высокой частотой дискретизации ( более 1 кГц ) удобно получать данные из буфера, считывая из порциями.

При более медленных измерениях 100 ( 50, 10) Гц мне нужно 100 (50, 10) раз в секунду вызывать ф-цию чтения LTR**_Recv() и получать данные, измеренные в момент вызова ф-ции чтения или как можно более близкий к этому событию момент времени.

При этом соответствующее LTR** АЦП я программирую на ту же частоту измерения 100 (50, 10 ) Гц.

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

Точное выполнение вызова  LTR**_Recv() 100 раз в секунду мне гарантирует ОС реального времени.

Каким образом мне равномерно вычитывать последние измеренные данные:
- вызывать чтение большого буфера данных с 0-вой задержкой и забирать из буфера только последние данные ( контролируя код возврата ф-ции чтения )?

- могу ли я уменьшить до минимума длину буфера соответствующего LTR-модуля c тем, чтобы данные в буфере не накапливались а только обновлялись?

Где можно прочитать про принципы буферизации данных в LTR-системе?

1. С каким типом крейтов и модулей работаете?
2. Через USB или Ethernet?
3. Какой требуется максимальный трафик передачи данных  по интерфейсу? Или, другими словами, от каких (и в каком количестве) модулей LTR нужно собирать столько-то отсчётов в секунду?..

- В руководстве пользователя  http://lcard.ru/download/ltr.pdf (глава 4) - это руководство по аппаратуре
- Программный аспект - в руководстве программиста  http://lcard.ru/download/ltr_sw.zip

- Какая ОС?

- Да, при наличии программы верхнего уровня, которая будет оптимально откачивать данные всех LTR-модулей в отдельных потоках (обеспечивая минимальную длину очереди в буферах LTR всех уровней). А контроль получившихся физических задержек отсчётов в локальном буфере этой программы может быть сделан, например,  по секундным  LTR-меткам. Тогда, данные этого локального буфера сможете не копить, а только обновлять. В любом случае, нельзя не откачивать данные LTR-модуля на верхнем программном уровне.
Метки нужны, например, для того, чтобы выровнять по времени данные от разных модулей.

ОС реального времени QNX4/QNX6, время гарантированного программного тика 500мкс в QNX4, в QNX6 меньше. Частота сбора данных в режиме "реального времени" не более 100Гц, в отдельных случаях возможно 1000Гц по ограниченному числу каналов (в пределах одного LTR-модуля) .

Предполагаю на каждый LTR-модуль иметь свою программу (врехнего уровня) или нить, работающие на повышенном приоритете, так что другие программы прикладной системы не смогут помешать "вовремя откачивать".

Предполагается работа только по Ethernet интерфейсу, работа с максимальным числом модулей - 16.

Т.о. программы верхнего уровня смогут гарантировать "откачку" данных вовремя.

Как убедиться в гарантиях LTR-крейта  и ltrd-сервера в отсутствии задержек при наполнении "откачиваемых" буферов?

Достаточно ли посчитать максимальный трафик?

15 * 16 * 4 * 100 + 1 * 16 * 4 * 1000 =  160 000 байт в секунду. Такой объем данных вроде бы по документации "прокачивается" по Ethernet c большим запасом

- Задержка данных от входа АЦП до верхнего программного уровня не может быть нулевой по чисто физическим причинам. А при ошибках в канале передачи Ethernet будет перезапрос передачи по TCP/IP, который добавит задержку данных.  Я правильно понимаю, что Вы спрашиваете про то, как убедиться, что  в буферах не наступило событие переполнения? Или про то, как оценить количество накопленных в буферах отсчётов в данных момент времени?

Правильно ли я понял, что буферирование данных измерений внутри LTR-крейта происходит при использовании USB-интерфейса, а при использовании Ethernet -интерфейса буферированием данных занимается LTR-сервер ( ltrd ) ?

Я не смог найти программных функций, управляющих длиной буфера внутри программного ltrd-сервера индивидуально для каждой платы АЦП внутри LTR-крейта.

Хотелось бы получить ответы на оба вопроcа:
- как убедиться, что  в буферах не наступило событие переполнения?

- как оценить количество накопленных в буферах отсчётов в данных момент времени?

Это понятно.

Вопрос в том, какое максимальное гарантированное время подобные задержки не могут превысить? 

Если временной параметр "реального времени" при получении данных из LTR-крейта пока не определен, каким образом оценить время возможных задержек?

Один из простых способов: Во время t1 по системным часам дать команду LTR-крейту на выдачу одиночной метки. Принять эту метку функцией приёма данного LTR-модуля. Засечь время приёма метки t2 по системным часам. Оценка задержки будет T= t2-t1. Это именно оценка времени с избытком ("не более, чем..."), поскольку она не учитывает время приёма команды запуска метки LTR-крейтом и время задержки самого LTR-модуля.   Поскольку частота сбора данных данного LTR-модуля известна F (отчсётов в секунду), то оценка количества отсчётов данных этого модуля, стоящих в очереди в буферах всех уровней -  не более, чем: N= F*T.

К сож. не понял про команду "выдачи одиночной метки" LTR-крейту, прошу пояснить.

Но м.б. я делаю что-то похожее на Ваше предложение?

В моем распоряжении сейчас 2-х местный крейт LTR-EU-2 и установленные в него 2 платы LTR-27. Работаю по Ethernet-интерфейсу.

В ссылке http://yadi.sk/d/mTNtr6K3PvPEW

привожу исходный текст теста ltr27_test.c, которым пытаюсь оценить наличие-отсутствие задержек при чтении данных.

-программирую LTR-27 на измерение 50Гц
-в бесконечном цикле
  - засекаю время начала
  - делаю 5 раз
     - чтение данных из LTR-27
     - пересчет в физические величины
  -  засекаю время конца
  - вывожу строку с оценкой времени на один цикл в мсек и результатах измерения

На картинке ltrd.bmp - запуск ltrd-сервера в ОС QNX4
LTR27-1.bmp - работа теста с 1-й LTR-27
LTR27-2.bmp - работа теста с 2-й LTR-27

Второй столбик - оценка времени одного цикла опроса-обработки данных
19.68 ... 20.08 мс

Третий столбик в тесте LTR27-1.bmp - поданные на 1-й канал калибратором эталонный ток 16.8 мА

Оба теста работают одновременно, каждый со своим интерфейсом, и никак не загружают работой процессор.

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

Хочется предположить, что так же и работал бы 16-ти позиционный LTR-крейт, заполненный 16-тью LTR-27 интерфейсами.

Хотел бы услышать комментарии к приложенным картинкам и тексту теста, а так же получить ответы на вопросы из предыдущих отрезков обсуждения.

Спасибо.

Здравствуйте.

Честно говоря, я не нашел, в каком документе Вы нашли про 7 и 10 мс, в ltrapi.pdf с сайта я этого не увидел. Возможно это было в какой-то старой версии документа...

Сам ltrd не задерживает данные (в нем нет явных задержек, которые могут быть в ltrserver), принятые от крейта он пересылает "сразу" в сокеты клиентов. Естественно какое-то время на обработку уходит, но это слишком зависит от ОС/железа и т.п. Про буферезацию Вы не правы, она не зависит от интерфейса, в любом случае есть буфер внутри крейта и внутри ltrd/ltrserver. Данные от модулей попадают внутрь буфера в процессоре blackfin крейта. Из этого буфера они с максимально возможной скоростью откачиваются ltrd/ltrserver'ом и уже передаются в буфер сокета соответствующего клиента, откуда забираются уже с помощью LTR_Recv(). Сами по себе буфера не вносят задержки, если данные откачиваются своевременно.

Основные задержки будут как-раз при передаче по Ethernet. При этом они сильно зависят от реализации TCP/IP стека конкретной ОС. Следует однако учитывать, что строго говоря, по Ethernet нет гарантированно времени доставки пакета, как уже писал выше Александр, пакет может быть и потерян, тогда будет перезапросы по таймаутам и т.д.

В общем-то указанный Вами разброс времени в десятые мс выглядит вполне адекватным, и по идее не должен особо зависеть от кол-ва модулей. Единственное что у Вас не учитывается время вывода на консоль (от stop предыдущего цикла до start следующего) - в это время ведь тоже собираются данные (этим может объясняться "чуть быстрее").

Тем не менее, по-хорошему Вы должны учитывать, что задержки могут быть. Честно говоря, не очень понятен смысл привязки к таймеру реального времени ОС. Если у Вас как Вы говорите по потоку на модуль, то Вы знаете, сколько отсчетов должно прийти за нужный Вам интервал, соответственно ничто не мешает сделать LTRXXX_Recv на нужное кол-во отсчетов с таймаутом равным заданному времени с запасом на время передачи, после обработать и т.д.

По поводу изменений, то ltr_cross_sdk состоит из набора проектов, для каждого есть репозиторий на bitbucket.org, где все изменения фиксируются и все изменения можно посмотреть на сайте. Для ltrd: https://bitbucket.org/lcard/ltrd/commits/all, для ltrapi: https://bitbucket.org/lcard/ltrapi/commits/all и т.д.

Документ имеет имя файла book.pdf, на вс. сл. сделал ссылку
http://yadi.sk/d/DXNpjtrIPvpkM

Вы абсолютно правы насчет времени вывода строк в графическом окне.

Я в тесте увеличил число повторов цикла HM_TEST до 500, т.е. в 100 раз снизил "удельный вес" времени вывода строки на экран и получил "железные" 20.00 мс на каждый цикл опроса, т.е. как и был запрограммирован LTR27.

Т.е. задержки в буферах внутри LTR-крейта и ltrd - TCP socket практически не заметны. Это очень радует!

Кстати в последней реализации ltrd в файле ltrsrv_cfg.h я вынужден уменьшить длину буферов сокетов на прием и передачу данных:
#define LTRSRV_ETH_CRATE_SOCK_SEND_BUF_ZISE c 1024*1024 до 128*1024
и
#define LTRSRV_ETH CRATE_SOCK_RECV_BUF_SIZE c 4*1024*1024 до 128*1024

иначе ltrd не запускался ( видимо особенность реализации TCP v 5.1 в ОС QNX4 )

Спасибо за поддержку.

И все же хотелось бы получить ответы на прозвучавшие в обсуждении вопросы или же получить подтверждение, что ф-ций определения переполнения буфера или определения количества скопившихся отсчетов в буфере  в API не существует.

Про одиночную метку, если решите ее использовать, то для ее генерации Вам нужно установить соединение с самим крейтом LTR-EU и вызывать функцию LTR_StartSecondMark() (есть например в ltrapi в examples/c/ltr-eu), при этом в LTRXXX_Recv нужно принимать и массив tmark с размером равным размеру массива принимаемых данных и смотреть, когда слово в нем изменится (там старшая часть слова - кол-во меток "СТАРТ", а младшая - кол-во меток "СЕКУНДА").

Т.е. если будете использовать тест с помощью метки, то он должен выглядеть так:
1. установить соединение с крейтом
2. установить соединение с каким-либо модулем, настрить его и запустить сбор
3. засечь время старта
4. вызвать  для крейта LTR_StartSecondMark()
5. принимать данные с метками от модуля с помощью LTRXXX_Recv() (можно без обработки) с минимальной задержкой. Как только изменилась старшая половина слов в принятом tmark - засечь время.

Правда при таком способе помимо того, что в измеренное время будет входить время передачи команду крейту, это время еще будет округлено в большую сторону до одного периода дискретизации АЦП (т.к. будет привязана к отсчету АЦП).

Сам принцип меток описан в главе "Принципы синхронизации сбора данных в системе LTR" в "Руководстве пользователя" (ltr.pdf)

Но не знаю, насколько Вам такой эксперимент будет полезен....

Функций, чтобы узнать количество скопившихся слов нет. Это к сожалению проблематично из-за того, что по сокетам передается и служебная информация кроме собственно отсчетов.
По поводу переполнения, то сам факт можно узнать:
1. При вызове любого Recv, если в принятом блоке было переполнение буфера сервера, то установится флаг FLAG_RBUF_OVF в поле Channel.flags
2. Большинство LTRXXX_Recv() проверяют этот флаг и возвращают LTR_ERROR_RECV_OVERFLOW если он установлен (например тот же LTR25_Recv() в https://bitbucket.org/lcard/ltrapi/src/ … t=default).

По поводу размера буфера сокета - спасибо за информацию - подумаю как учесть. Видимо там есть ограничение на размер, но в общем то и в ОСРВ размер этого буфера не имеет такого значения по сравнению с ОС общего назначения, где задержки могут быть сильно больше.

Только следует помнить, что это "удчаное стечение обстоятельств" на данной установке в данных условиях, т.е. полагаться на стабильность этих величин надо с оглядкой. Скажем, сойдет для лабораторного эксперимента, если допустимо в случае чего забраковать результат и измерить заново.

Предложенный метод оценки времени задержки данных может рассматриваться как некая дополнительная диагностика (проверка времени реакции LTR), которая, например, выявит резкое увеличение задержек данных в системе  при ухудшении качества связи по Ethernet по тем или иным причинам.

Если же хотите точнее измерять это время задержки, то возможны варианты:

Вариант1: Если есть внешний физический сигнал, время возникновения которого привязано к системным часам ПК, и от этого синхросигнала запускать метку LTR, либо этот синхросигнал подавать на вход АЦП. Тогда по разности соответствующих задержек по системным часам определите требуемое время.

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

Вариант3: Если в системе есть сервер единого времени, то его по протоколу IRIGB006 можно связать с LTR-EU http://www.lcard.ru/node/803

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

Cпасибо за множество полезной информации.

В ОС реального времени я могу подсчитать время между событиями с высокой точностью (как минимум 1 мс ), если подсчитывать средний период между 10, 50, 100 операциями чтения с модуля АЦП, то (на мой взгляд) можно довольно точно судить о задержках передачи данных в прикладную программу, т.к. частота опросов АЦП заранее известна.

Почему Александр Е призывает к осторожности? Что мешает хороший результат на двух-позиционном крейте LTR-EU-2 экстраполировать на 16-ти позиционный крейт? Вроде бы подсчитанный максимальный трафик много меньше допустимого.

Я смотрю с программистской точки зрения: если параметр не нормирован, т.е. если нет известного механизма, обусловливающего его величину, то делать допущения о нем гораздо менее надежно, чем если параметр определяется известным процессом.
Грубо говоря, я могу получить на выходе "черного ящика" последовательность из чисел { 20, 21, 22 } в случайном порядке и сделать вывод, что этот прибор дает всегда 21±1, а потом окажется, что это был термометр

С "черным ящиком" спорить трудно, но LTR-крейт для Вас не черный ящик.

По кр. мере по поводу микропрограммы, работающей на RISK-процессоре крейта должны быть гарантии, что она в к-то моменты не "засыпает" и данные от LTR-модулей исправно направляются в Ethernet-канал с гарантированной максимальной задержкой такой-то величины.

А задачи на ПК верхнего уровня должны так распределить приоритеты, чтобы вычитывание данных из LTR-крейта шло без промедлений.

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

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

Поэтому важно добиться равномерного получения данных от LTR-модулей без задержек...

Леонид, Вы связываетесь с LTR по TCP/IP поверх Ethernet.
Но жестко придерживаясь Вашей логике, нужно в LTR отказываться от TCP/IP и переходить на другой протокол с гарантированным временем доставки. Какие Ваши предложения по поводу другого протокола поверх Ethernet в LTR?  А через USB не хотите работать? - там задержки будут меньше, предполжительно...

- Какое максимально допустимое время принятия решения?

Через USB работать трудно, т.к. нужно разбираться с SDK USB в тех ОС QNX, в которых мы работаем. По TСP/IP , с исходными текстами ltrd и ltrapi и с помощью Вашего специалиста Алексея работа с LTR получилось достаточно быстро.

Речь идет о периоде измерения в 100 мсек, 20 мсек, иногда (по нескольким каналам ) в 1 мсек. Измерения и передача данных должны укладываться в это время без задержек.

Максимальный трафик с большим запасом вроде бы посчитан и он не большой ( не более 160 кбайт/сек ).

Пока в моем распоряжении только один LTR-EU-2 с 2-мя LTR-27, на этом оборудовании мне нужно спрогнозировать работоспособность с указанными частотами измерения крейта на 16 позиций.

Других предложений по протоколам у меня нет, но есть уверенность что должны быть известны максимальные задержки того, что работает внутри LTR или той ОС Linux, которую вроде бы по новостям вы планируете использовать внутри LTR.

Пока на основании сделанных экспериментов мне показалось что LTR легко справится с обозначенными требованиями.

Леонид, у L-Card есть оборудование, которое может работать в системах жесткого реального времени ПК - это модули PCI Express L-502.
http://www.lcard.ru/products/boards/l-502

Простите, но Ваши вопросы о задержках (времени реакции) в системе относятся именно к этапу выбора оборудования. По выбору оборудования мы консультируем всегда не менее тщательно, чем по вопросам техподдержки. 
Максимальное время принятия решения - порядка единиц  миллисекунд - точно можно относить к hard real-time. Такое  время обеспечивают либо на внутренних интерфейсах компьютера (PCI, PCI Express), либо сам уровень  hard real-time выносят в сигнальный процессор (например, на уровень Blackfin LTR-EU).

Кстати, есть еще один ресурс для построения автоматов (с принятием решения в процессе измерений) - это написание собственной прошивки для blackfin внутри крейта. Там данные приходят прямо с внутренней шины по DMA.

С инженерной точки зрения, в такой постановке задачи есть глубокие  физические противоречия. Если LTR27 эксплуатировать с частотой сбора данных 100 Гц на канал (период Т= 10 мс), то теоретическое время задержки самого преобразователя напряжения в частоту (ПНЧ) в субмодулях H-27x будет половина периода сбора данных, поскольку показания LTR27 вычисляется подчсётом количества импульсов с выхода ПНЧ  за время Т. Очевидно, что сигнальная задержка в таком фильтре с временным окном T составит T/2. Т.е теоретическая задержка LTR27 при частоте сбора данных 100 Гц составит 5 мс, при 10 Гц - 50 мс. К теоретической задержке Т добавится несколько миллисекунд задержки входного аналогового фильтра в H-27x и порядка 1 мс время передачи отсчёта LTR27  в интерфейс LTR. Замечу, что сам LTR27 физически усредняет за 1 мс, а усреднение на большем интервале времени происходит средствами верхнего уровня, но это обстоятельство формулы сигнальной задержки не меняет:
- Если хотите получать от LTR27 отсчёты с частотой F (Гц), то задержка будет (0,5/F)+ несколько мс. 
Леонид, это принципиально  не вписывается в Ваш real time, и к выбору оборудования, похоже, вернуться придётся.
С частотой 1 кГц физически  можно собирать отсчёты с LTR27, но этот режим не  является штатным, поскольку из-за большой дисперсии отсчётов, так или иначе, требуется усреднение на большем интервале времени. У ПНЧ  среднеквадратическое отклонение (СКО) показаний уменьшается вдвое при увеличении времени усреднения в 4 раза.
А для измерения какого физического процесса используете LTR27? Это ведь модуль для измерения медленно меняющихся сигналов. Вы  выше упомянули выброметрию. Но LTR27 можно использовать для исследования разве что инфранизких частот (до нескольких единиц Гц)...

Cпасибо за подробные разъяснения.

Мне так же важно было увидеть в Ваших разъяснениях, что примерно 1 мс занимает время передачи отсчета LTR27 в интерфейс LTR.

По поводу выбора оборудования, выбор уже сделан и оборудование приобретено.

В нашей задаче требуется сбор данных с частотой 50Гц, поэтому примем во внимание Ваше разъяснение и будем задавать частоту измерения 100Гц. При этом временными погрешностями от фильтрации и осреднения в LTR27 будем пренебрегать.