Нужно создать систему измерения и управления экспериментальной установкой на базе двух крейтов LTR-EU-16(выпуск июль 2009),один,работающий только на ввод через ETHERNET, заполнен модулями LTR27, второй, работающий через USB на ввод/вывод, заполнен LTR51 и LTR43. Для управления дискретными каналами необходимо примерно 10 в секунду снимать данные с обоих крейтов, выполнить расчеты (нелинейные зависимости), анализ данных и сформировать управляющий код для LTR43. Вопросы:
1. С какой периодичностью программный LTR-сервер отбирает данные из крейта.
2. Какова периодичность передачи данных в крейт.
3. Какова максимальная (примерно) задержка при передаче управляющих кодов в LTR43, от вызова соответствующей API-функции с учетом двунаправленности потока данных.
Спасибо

1. По USB - постоянно висят overlapped запросы чтения из драйвера, т.е. по идее зависит от USB
По TCP/IP - используется механизм select(), т.е. опять же как только стек заполнит буферы. Но задержки данных в TCP - это отдельная тема, тут многое зависит от сети и от скорости поступления данных. Надо тестировать в реальных условиях.
2. Передача данных в крейт сделана почти симметрично приему - тоже overlapped по usb и select по TCP/IP.

Когда по TCP/IP нет данных для записи в крейт, а потом они появляются, 10 мс сервер может сидеть в таймауте select на чтение.

3. Задержка от вызова API-функции зависит от взаимодействия процессов через TCP/IP (клиента с сервером), в случае localhost это время обработки tcp-стека системы, плюс реакция сервера на данные, плюс передача в крейт (если по TCP/IP, то еще раз tcp-стек).

Оценить эти времена аналитически я затрудняюсь, но за вычетом обмена по сети ПО ИДЕЕ я бы ориентировался на *порядок* 10 мс.

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

И еще одно. Из LTR-EU в принципе возможно сделать быструю систему управления с обработкой данных внутри крейта - путем переписывания прошивки процессора Blackfin в самом крейт-контроллере. Это *большая* задача в смысле программирования (по сути надо реализовывать протокол высокого уровня, который штатно в ltrserver + приложение, внутри прошивки), но аппаратура позволяет.

Спасибо за ответы!
Понятны тормоза, связанные с Windows, но перенос обработки в Blackfin проблематичен сам по себе, а с учетом того, что алгоритмы обработки иногда меняются от испытания к испытанию, этот вариант нереален по причине ограниченного времени перепрограммирования системы. Будем пытаться реализовать систему на одном управляющем компьютере (возьмем посильнее) с дискретом 100 мс. По крайней мере этот вариант сразу не отвергается исходя из ваших ответов, учитывая что передача данных идет только в USB крейт. Уще раз спасибо.

Передача идёт и туда и обратно, понять что данные действительно вывелись через выходы LTR34 можно только приняв их обратно.
100мс - я неуверен, нужно тестировать, точнее работать-то будет, но Windows очень непредсказуем.

Передача туда-обратно только для LTR34 или для LTR43 тоже? У нас LTR43.

Извиняюсь, Я не в ту ветку написал....

Здравствуйте! Меня заинтересовала обработка данных внутри крейта. Доступны ли исходные тексты прошивки процессора Blackfin или контроллерные функции придется реализовывать заново?

Исходные тексты программы процессора Blackfin предоставляются (по запросу). О низкоуровневом программировании и соглашениях читайте в главе 15 руководства http://www.lcard.ru/download/ltr_hw.zip

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

А если Вам надо серьезную систему управления с логикой, обратными связями и так далее, что задача это немаленькая, но решаемая. Контроллерные функции Вы сможете взять из штатной прошивки.
Но сразу скажу: идеология штатного ПО системы LTR предполагает, что протоколы обмена с модулями реализованы на верхнем уровне (в ltrapi).

Упрощенно говоря, схема такова:

1. Прошивка blackfin не разбирается в командах и форматах данных модулей: она управляет материнской платой крейта, а то, что идет в модули (LTR-xxx, которые установлены в слоты крейта) и из модулей - это для нее как бы сплошной поток информации. Он транслируется как есть в ltrserver.

2. Программа ltrserver занимается в основном (де)мультиплексированием потока данных (то есть сплошной поток разделятся по слотам) и их буферизацией. Плюс там реализована инициализация крейта, идентификация модулей и некоторые команды управления, но только малая часть. По большому счету ltrserver не вникает, что это в слоте: LTR22 или LTR114, и чем они отличаются: модуль и модуль. Этим достигается в значительной степени универсальность крейта и сервера, так что когда появляется новый тип модуля, как правило для него просто пишут ltrXXXapi.

3. И уже на уровне DLL-библиотек ltrapi полноценно реализованы протоколы модулей (например, установка параметров АЦП, пуск и останов сбора данных и т.д.)

Так что без изучения описаний и исходных текстов ltrapi и ltrserver не обойтись.

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

Запоздалое спасибо за пояснения!!

Добрый день!
Хотелось бы добавить, что скорее всего придется дорабатывать еще и ПО модулей, потому что хочется и быстрые компараторы с заданием уставок, и начальное состояние выходов модуля LTR42, и т.д.
Поэтому без конкретного ТЗ вся работа может свестись к переводу времени на эксперименты.

Георгий, если у Вас есть пожелания к ПО модулей LTR, то сформулируйте, пожалуйста, подробнее.

Добрый день, Александр!
Пока сформулированных в виде ТЗ пожеланий к модулям LTR нет.