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

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

Теория и практика показывает, что Ethernet будет иметь минимальную задержку при идеальных условиях физической среды: связь должна быть не через общую сеть, а от сетевой карты напрямую к LTR (от точки к точке), качественным кабелем. Но гарантий максимальных задержек TCP/IP Вам никто не даст - только опытным путём,  в вероятностном смысле, при данных физических условиях, в данном комплекте реализации сетевого оборудования, в данной реализации программных стеков TCP/IP с обеих сторон.

- Поскольку речь шла о LTR-модуле, то надеюсь, что Вы поняли, что ориентировочно 1 мс занимает время передачи сырого отсчета LTR27 в интерфейс между LTR-модулем и LTR-крейтом, т.е. ещё до постановки в очередь на передачу в Ethernet.

Замечу, что физический уровень Ethernet имеет достаточно малый разброс задержек, а вышеупомянутые задержки вносят транспортный и интернет уровни протоколов. Но поверх Ethernet даже в купленном оборудовании LTR-EU можно в Blackfin реализовать и протокол с гарантированном временем доставки, например, поверх UDP (только я сомневаюсь, что это будет проще, чем просто перейти на USB под QNX).

Cпасибо за поддержку и разъяснения.

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

Работа с LTR-крейтом через USB в QNX - тоже интересная тема, наверное нужно выделить ее в отдельное обсуждение?

В каком разделе: "Техническая поддержка" или "Подбор оборудования"?

"Не к ночи упомянутый" коммутатор ведь и в составе материнских плат встречается... - это к вопросу о сетевом оборудовании.
Работа с LTR через USB в QNX - лучше в отдельную тему, а вообще, - как в анекдоте: "Где тут у вас...? Вам - везде"  .

Вообще обычно задачи, с real-time ставятся примерно так: "при таком-то событие (изменении сигнала на входе АЦП ) нужно выполнить такое-то действие с задержкой не менее такой-то от самого события". Если у Вас модуль уже работает с частотой 50 Гц (т.е. усредняет за 20 мс!) не очень понятно зачем требование к времени передачи в 1 мс. И Ваш метод с засечкой времени за n-ое кол-во операций скорее больше оценивает равномерность этой задержки, чем саму задержку (все же это несколько разные вещи и вопрос что именно нужно). А так, если оборудование у Вас все равно уже есть, то нужно проводить испытания исходя из конечной задачи и требований и исходить из полученных результатов. С 16-местным скорее всего разницы быть не должно, если только не попадете на влияние на эту задержку алгоритмов управления потоком в TCP-стеке, но предсказать это несколько сложно...

LTR27 - это модуль, предназначенный для измерения статических физических величин (температура, давление, напряжение постоянного тока, величина постоянного тока и т.п...). Основной режим работы - с частотой сбора данных 5 Гц! Именно на 5 Гц этот модуль поверяется как Средство Измерения. Это означает, что LTR27 целесообразно использовать в контурах управления с временем реакции порядка 1 с и более.  -  Это всё к вопросу противоречивости постановки рассматриваемой задачи...

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

Пожалуйста подскажите: какой другой LTR-модуль Вы рекомендуете для измерения сигнала с датчика давления 4-20мА с частотой опроса 50Гц?

LTR11 или LTR114 с резистором-шунтом 100 Ом, запаянным на кабельной части разъёма модуля. LTR114 дороже, но достижимая  точность измерений и разрешение будет больше, чем в случае LTR11.
Если датчиков 4-20мА нужно подключать более одного, то их схема включения должна предполагать соединение цепей общих проводов датчиков в точке подключения AGND модуля LTR.  Понятие "Датчик   4-20мА" связано также с тем, что где-то должен быть внешний источник питания  (вероятно, сетевой), цепь заземления которого должна быть грамотно увязана с заземлением LTR и других приборов в Вашей системе. Параметры резистора-шунта зависят от требуемой  точности. Возможна комплектация  шунтом при заказе, если согласуем его параметры. Приведу схему подключения, если ответите на вопросы:
1. Тип датчика и источника питания с ссылками на документацию?
2. Требуемое максимальное количество каналов измерения?
3. Максимальная длина кабеля от датчиков до  LTR?
4. Цепи датчика и источника питания изолированные? Если нет, то какая цепь с чем контактирует?
5. Какие параметры точности хотите достичь, в каком температурном диапазоне LTR-EU?

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

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

Такие задачи решают в обратной последовательности: чтобы прийти к новому решению, нужно новое решение хотя бы рассмотреть. А чтобы рассмотреть, нужны ответы на вопросы выше. Например, если датчиков несколько и их цепи измерения заземлены на разные (далёкие) точки заземления, то предложенное решение (с одним LTR11 или с одним LTR114), возможно, не годится - потребуются другие уточнения.

Поскольку Вы упомянули о том, что будете мигрировать на LTR-EU-16, то ответы на вышезаданные вопросы сразу формулируйте для  LTR-EU-16 с описанием физической задачи измерения и описанием характера  входящей аппаратуры в Вашу установку, от чего будут питаться эти устройства, как заземляться. Эти вопросы относятся к электросовместимости устройств . Общие вопросы электросовместимости  рассмотрены в статье:
http://www.lcard.ru/articles/11
Все эти вопросы должны решать инженеры-системные интеграторы на этапе выбора оборудования самостоятельно.  Детальность возможной консультации в конференции соответствует детальности предоставленных данных.  Леонид, от Вас детальность в части физического описания задачи - почти нулевая!... Но даже то, что есть -  противоречиво (в части времени реакции). - Делайте вывод.
Кстати, о точности LTR27 Вы задавали вопрос?:
http://lcard.ru/forums/viewtopic.php?pid=56006#p56006
Эта точность соответствует Вашей задаче измерения?

Мы пришли к варианту дополнительного заказа LTR11.

Ответы на Ваши вопросы от нашего специалиста-электронщика:

1. Тип датчика и источника питания с ссылками на документацию?

Датчик давления ADZ-SML-10.0
Источник питания PHOENIX CONTACT 2938581; QUINT-PS-100-240AC/24DC/5

2. Требуемое максимальное количество каналов измерения?

Три

3. Максимальная длина кабеля от датчиков до  LTR?

Требует измерения по планировке.

Не более 50-ти метров. Если требуется более точное значение - уточним.

4. Цепи датчика и источника питания изолированные? Если нет, то какая цепь с чем контактирует?

К датчику могут быть подключены цепь +24 В или цепь 0 В источника питания в зависимости от схемы подключения к модулю АЦП, соответственно вторая цепь источника питания подключается через нагрузочное сопротивление для организации токовой петли.

5. Какие параметры точности хотите достичь, в каком температурном диапазоне LTR-EU?

±1.0 % от ВПНЗ

LTR-EU будет размещен в кабине наблюдения с перепадами температур 10-30 градС максимум.

Буду признателен за рекомендуемую схему подключения.
Спасибо.

Придётся уточнить задачу.
Есть несколько схем подключения этих датчиков, см.
http://www.centeradc.ru/ftpgetfile.php?id=14 , стр.9
- там как 2-х проводные, так и 3-х проводные подключения.
Вопросы:
1. Для Вашей задачи принципиально, сколько проводное будет   подключение?
2. На тип кабеля ограничения накладываются?
3. Источник питания должен располагаться на стороне датчика или на стороне LTR?
4. Требуется  применить один источник питания для нескольких датчиков или допустим свой источник питания для каждого датчика?
5. Искробарьер будете применять? Если да, то какого типа?

По поводу источника питания
http://www.soyuz24.net/express/2938581/2938581.pdf
у меня возникает серьёзное сомнение в его качестве: на его блок-схеме отсутствует сетевой фильтр, а это значит, что, в случае отсутствия экранирования вторичной обмотки его трансформатора, на выходе источника питания будет большая импульсная помеха относительно земли (PE).  А LTR11 ведь широкополосный, в отличие от LTR27, и этот фактор придётся серьёзно учитывать при подключении...

Извините, я понял что плохо описал временнЫе проблемы приема данных из LTR, позвольте это сделать снова:

У нас производятся испытания авиадвигателей.

Измеряемые параметры разделяются на параметры установившихся режимов ( примерно 300 параметров, частота опроса обычно 10Гц ) и параметры
переходных режимов ( примерно 50 параметров, частота опроса 50Гц ).

Мне нужно с данной частотой получать из LTR-сервера результаты преобразований, отправлять их в свой программный
сервер_данных  receiver ( не путать с LTR-сервером), в котором электрические единицы пересчитываются в физические.
Остальные прикладные программы ( их одновременно работает пару десятков ) забирают значения из receiver и выполняют с
ними свою работу.

В действующих у нас сегодня  системах на каждую плату универсального AЦП  напущена своя программа, которая по таймеру  ОС реального времени
опрашивает каналы АЦП и отправляет коды АЦП в receiver. Здесь я уверен, что коды АЦП отправляются в receiver с заданной частотой.

При применении LTR-крейта вместо прямого управления АЦП я могу только  вычитывать готовые данные из ltr-сервера ( программы ltrd ).

Для этого для каждой платы в LTR-крейте я запускаю прикладную программу, в которой с той же частотой, на которую запрограммирована
LTR-плата, делаю вызов функции LTR**_Recv().

Мне важно, чтобы ltrd-сервер мне отдавал результат преобразования именно с этой частотой, а не порциями по несколько преобразований в порции.

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

К сож. пока мне не удается найти ответ на этот вопрос.

Леонид, из LTR-cервера можно считать данные всех модулей и, например, секундные метки, вставленные в этот поток. Эта информация даёт возможность программно восстановить относительное положение по времени всех отсчётов данных LTR c точностью до 1-го периода преобразования самого скоростного LTR-модуля, участвующего в этом процессе сбора данных. Но после такого программного восстановления Вы будете иметь задержанный поток  данных, (относительно их физического рождения на входах АЦП) на некое (не нулевое!) время буферизации в системе, с нужной Вам частотой следования (50 Гц), привязанной к частоте  LTR (но не к частоте 50 Гц по системным часам Вашего компьютера!) .

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

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

Ну в том, что Вы описываете больше идет речь о равномерности приема данных. И насколько я понимаю, полученные на 2-х местном крейте результаты Вас устраивают (?).

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

Не очень понятно как работает это "универсальное АЦП" , Вы получается считываете по таймеру, а не по факту завершения преобразования самим АЦП?

И если задача стоит в привязке отчетов разных АЦП (времен на входе АЦП, которому соответствуют эти отсчеты, а не времен получения их в ПК), то это уже другой вопрос и нужно знать какие тут Вам нужны точности...

Вы правы, Алексей! Моя задача - обеспечить равномерный и максимально быстрый прием преобразований от LTR-модулей по мере их "рождения".

Подмешивать секундную метку и постфактум привызывать отсчеты ко времени - это не мой случай.

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

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

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

Тестирую прием одновременно от 2-х LTR-27 c частотой преобразования 1000Гц в 2-х ОС : QNX4 и QNX6.

В QNX4 результаты удовлетворительные. Разброс в последовательном получении данных преобразований не превышает 1-1.5 мс.

В QNX6 результаты не удовлетворительные. По вызову LTR27_Recv() в непрерывном цикле подряд приходит много пакетов с 0-й задержкой между ними, потом значительная пауза, и потом опять много пакетов подряд.

Собираю ltrd из одних и тех же исходников ( апрель 2014) . Могут ли к-то параметры config.h влиять на подобное поведение ltrd или причины в разных реализациях стека TCP/IP?

На какие параметры настройки стека Вы посоветуете обратить внимание?

Внутри LTR-крейта  используется TCP/IP стек версии 4 или 6?

P.S. В действующей системе по таймеру ОС реального времени я стартую работу по обслуживанию АЦП ( через каждые 20 мсек). На каждом цикле программа уже знает : какие каналы и сколько раз нужно опросить, как отбросить первое преобразование и осреднить полученные коды АЦП. Т.о. запускается серия преобразований АЦП, с использованием аппаратного прерывания по завершению преобразования АЦП. Таймер ОС реального времени обеспечивает запуск каждого цикла обслуживания АЦП с точностью до 0.5мсек.

С большой вероятностью можно сказать, что разница в самом стеке TCP/ОС в этих ОС, а не в ltrd.
То, что Вы описываете в QNX6 - это похоже на одновременное взаимодействие алгоритмов Нагла и delayed ack в TCP (при желании об этой проблеме можно почитать http://stuartcheshire.org/papers/NagleDelayedAck/).

Можно попробовать либо отключить delayed ack в QNX6 (тут есть например обсуждение http://community.qnx.com/sf/discussion/ … _pagenum=1, правда там с какой-то версии только есть возможность).
Либо можно попробовать использовать более старую прошивку крейта (версия 1.0.0.1), в ней насколько я помню алгоритм Нагла отключен, из-за чего таких задержек не будет, но и максимальной скорости в крейте тоже нельзя будет достичь (хотя если у Вас LTR27, то это совсем не критично). Прошивку и программу обновления под Windows можно взять: для 2-местного - http://www.lcard.ru/download/ltr_eu_2_fw.zip, для 8/16 - http://www.lcard.ru/download/ltr_eu_8_16_fw.zip. Есть программа обновления и под linux - ltreu-firm-update - она работает через ltrd (при желании ее можно собрать и под QNX вместе с ltr030api)

Чтобы не отвлекаться от "Задержек" вопрос о правилах подключения датчиков давления к LTR11 перенес в форум " Подбор оборудования "

Леонид, проверьте, что физическое соединение по Ethernet возникает - 100 Mb/s  - full duplex. Если, например, по какой-то причине устанавливается half-duplex, то это может быть причиной  дополнительной неравномерности и дополнительных задержек.
Кроме того скажу, что равномерность передачи по сетям управляется обычно специальным протоколом Flow Control. Можно ли здесь его в каком-то виде задействовать - это вопрос к программистам.
За железо внутри LTR-EU скажу, что ПЛИС льёт данные в порт PPI процессора Blackfin c идеально постоянной скоростью. Далее, по DMA эти данные попадают в SDRAM  -  ОЗУ  Blackfin. А далее, начинается сплошная программная реализация того или иного протокола передачи, т.е. "железо" равномерно передавать может (не теряя время на буферизацию данных), в всё остальное (в LTR-EU и на уровне ПК) - во власти  программистов...

Спасибо Алексею за указание правильного направления.

После команды в QNX6
#sysctl -w net.inet.tcp.ack_on_push=1

cитуация выправилась и стала сопоставима с результатами в QNX4:

при приеме пакетов преобразований от двух плат с частотой преобразования 1000Гц каждая неравномерность прихода пакетов не превышает 3мс. Такой результат приемлемый.

Просьба пояснить: каким образом работает ltrd в Linux с USB-портом ( если переключить LTR-крейт на работу по USB)?

Сейчас при сборке ltrd я исключаю из плана сборки файлы ltrsrv_usb_lcomp.c, ltrsrv_usb_libusb.c, ltrsrv_usb.c, но проблем при сборке не возникает.

Для работы с USB под linux используется библиотека libusb-1.0 (http://www.libusb.org/)
Сам код для работы с USB включается только при наличии #define LTRD_USB_ENABLED в config.h, без него соответственно все собирается и без файлов поддержки usb (как раз и сделано для сборки под системы без поддержки USB).

В ltrsrv_usb.c содержится общий код для работы, который используется и в windows, и в linux. ltrsrv_usb_libusb - реализация через libusb под linux, ltrsrv_usb_lcomp - реализация через драйвер lcomp под Windows.

Если совсем кратко, то сначала вызывается ltrsrv_usb_init() для соответствующей реализации, в ней запускается в частности проверка наличия новых устройств. При их нахождении вызывается общая функция p_usb_add_new_dev в которую в частности передается структура t_usb_port_intf с указателями на функции, специфичные для данной реализации. В начале инициализация крейта идет через управляющие запросы по control-pipe, а затем работа с модулями идет через конечную точку типа bulk.

Что касается QNX, то для него насколько я знаю нет порта libusb, соответственно нужно делать свою специфичную реализацию, что конечно может быть не так просто. В linux-версии также используется факт, что в linux все представляется в виде файлов для которых можно использовать в частности общий системный вызов select (чтобы не создавать отдельно потоки). В QNX вроде тоже все представляется в виде файлов, но про USB-устройства я не в курсе, можно ли получить дескрипторы файлов этих устройств.

Ну и априори очень сложно сказать даст ли (и если даст, то какой) выигрыш использование USB в Вашем вопросе.

В самом крейте к слову насколько я знаю, программа blackfin опрашивает раз в n-мс, сколько данных пришло из модулей и передает их либо по TCP, либо по USB. Возможно уменьшение этого времени может дать уменьшение задержки, но я сам с исходными кодами самой штатной прошивки не работал.

Спасибо за разъяснения.

Ранее в этой теме звучало:

Кажется Александр Е знает через сколько n-мс программа blackfin передает данные по TCP.

Мне кажется что n не более 1 мс.

Попытался что-то понять по исходным кодам прошивки из доступного на сайте L-Card архива

ltr_source_1_0_0_1.zip    4 065 566    28.12.10    Исходные тексты для Blackfin крейт-контроллера.

Вроде на blackfin работает FreeRtos, и в нем - нить ethernet_datarecv_task(), которая занимается чтением команд и отправкой данных из/в ethernet-порт в непрерывном цикле без явных задержек, но с заложенным временем ожидания готовности порта на чтение или запись в 2 миллисекунды в select()-вызове.

Т.е. задержек более 2 мс быть не должно?

Остается только надеяться на FreeRtos: как быстро будет передаваться управление на данную нить, если назначен приоритет 8.

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

Где можно посмотреть "рабочий" файл datahook.c, прошитый в LTR-крейт?

В приведенном в архиве datahook.c ожидается MAX_DATA_SIZE накопление данных в буферы LTR-слотов, которое имеет большую величину
#define MAX_DATA_SIZE (16384)

Это не понятно.

Общая логика потока ethernet_datarecv_task следующая.
1. Выполняется проверка, есть ли данные от модулей для передачи по TCP.
2. Ожидание готовности сокета на прием и, при наличии данных, на передачу. Максимальное время ожидания - 2мс.
3. При готовности сокета на передачу - запись данных в TCP-сокет (это еще не ethrnet - дальнейшая задержка зависит от стека). При наличии принятых данных - буферизация их для дальнейшей передачи в модули. Выход из функции select по тайм-ауту означает, что сокет не готов к передаче (еще не переданы предыдущие данные) и ничего не принято. Поэтому строго говоря гарантии в 2мс дать нельзя, т.к. время передачи по TCP не лимитировано. Этот тайм-аут сделан больше для следующего пункта.
4. Передача принятых ранее по TCP данных в модули.

Как следует из вышенаписанного передача данных в TCP происходит сразу при их обнаружении. Разбор по модулям внутри крейта не производится - это делается в ltrd или ltrserver.
datahook в поставляемую с крейтами прошивку не включается. В исходниках он приведен для тех, кто будет писать свое ПО для blackfin.