Меню
+7 (495) 785-95-25
sale@lcard.ru
sale@lcard.ru
Страницы 1
|
||||
|
Крейтовая система LTRЗдравствуйте! Во вновь проектируемой измерительной системе необходимо организовать измерение: В качестве средства измерения планируем использовать крейтовую систему LTR на базе LTR-EU-16-1: В процессе проектирования возникли следующие вопросы: Целесообразно ли разделить подсистемы измерения вибрации и остальных измерительных каналов в разные LTRкрейты? Или же есть возможность разместить все вышеперечисленные модули в количестве 15 штук в одном 16-ти позиционном крейте LTR-EU-16-1? Хватит ли, при описанной выше конфигурации LTRкрейта, пропускной способности Ethernetинтерфейса LTR-EU-16-1 для передачи данных? Не получится ли ситуация что Ethernetинтерфейс не сможет обеспечить требуемый поток данных. Допускается ли совмещать в одном LTR22 «быстрые» каналы вибрации и «медленные» каналы вибрации? |
|||
|
||||
|
Re: Крейтовая система LTRЗдравствуйте. Александр 1985 пишет:
- Пропускной способности хватит - в вышеописанной конфигурации, c сетью Ethernnet 100 Mb/s, свободной от стороннего трафика. Александр 1985 пишет:
- 4 канала LTR22 могут работать только с одной настроенной частотой преобразования АЦП. Для экономии трафика, для оптимальной полосы частот пропускания, а также для обеспечения идентичных времён задержки преобразования, "медленные" каналы желательно реализовывать в рамках одной группы LTR22, а "быстрые" - в рамках другой группы LTR22. Замечания: Вопросы: |
|||
|
||||
|
Re: Крейтовая система LTRИзвините, еще раз "заострю" вопрос: Как бы посоветовали разработчики LTR: - вариант 1 - вариант 2 Вариант 2 дешевле и займет меньше места в шкафу. Есть ли преимущества у варианта 1 с учетом того, что суммарного превышения трафика 100 мбайт/сек не предполагается. Спасибо. |
|||
|
||||
|
Re: Крейтовая система LTRЛеонид. Ваши вопросы относятся к важным вопросам системной интеграции, и, соответственно, решение здесь должен принимать системный интегратор. Некоторые аргументы привожу ниже. Размещая все модули измерительной системы в одном крейте, Вы имеете важное свойство когерентности частот преобразования всех модулей и когерентности частот импульсного питания всех модулей. Если речь идёт об одной измерительной системе, то наличие такой когерентности довольно важно, см.: C другой стороны, если измерительные каналы разных крейтов никак друг с другом не взаимодействуют (например, через взаимовлияние кабелей от датчиков), эти измерения относятся к разным физическим процессам или к разным объектам измерений, эти процессы измерений не нужно точно синхронизировать по времени, то, вероятно, вышеупомянутое свойство когерентности не будет иметь значения. Леонид пишет:
Я так понял, что подразумевали 10 Мбайт/c. Для обеспечения этого почти максимальнрого возможного для Fast Ethernet трафика, как правило, используют выделенную сеть "точка-точка" от отдельной сетевой карты ПК. Разделение каналов на "медленные" и "быстрые" по разным крейтам может иметь смысл, если:
|
|||
|
||||
|
Re: Крейтовая система LTRИзвините за опечатку, я должен был написать 100 мбит/сек. Могу ли я сделать вывод, что при "смешанном" наборе модулей крейта данные из модулей "медленных" измерений (10Гц) будут приходить клиенту в ПК с бОльшей задержкой, в связи с большИм объемом данных "быстрых" (4-40кГц) измерений? И наоборот, при наборе в крейте модулей только "медленных" измерений (10Гц) данные измерений будут приходить клиенту в ПК с минимальной задержкой. --- Дополнительным преимуществом раздельных измерений в разных крейтах была бы синхронизация опроса разными модулями в крейте "медренных" измерений, т.е. режим опроса, при котором начало преобразований каждым модулем выполняется в один момент времени. Судя по описанию, синхронизация может быть выполнена внутренними возможностями крейта ( привязка к метке "Старт"). С другой стороны, крейты LTR не привязываются к источнику сигналов точного времени по GPS, и получить точное абсолютное время каждого преобразования по-видимому не возможно... |
|||
|
||||
|
Re: Крейтовая система LTRЛеонид пишет:
Тогда это абсурд, поскольку 100 Мбит/с - это предельная физически достижимая скорость 100BASE-TX, включая служебную информацию TCP/IP. Леонид пишет:
Наверное, можете, при прочих равных условиях, в среднестатистическом смысле, поскольку при большем трафике очередь на передачу может быть больше. Но в TCP/IP этих "прочих" условий, влияющих на задержку получения данных, очень много. Леонид пишет:
- Лично я не понял: это всё утверждения или вопросы? В любом случае, задачи синхронизации невозможно рассматривать без численных требований и точного описания физического смысла тех задержек, к которым прядъявляются требования в конкретной физической задаче пользователя. |
|||
|
||||
|
Re: Крейтовая система LTRДля "медленных" измерений (10Гц в одном проекте, 10Гц и 50Гц в другом проекте) моментом измерения признается время поступления данных из LTR-cервера в программу-клиент выполнения измерений. Т.к. в данных из LTR-крейта отсутствутет привязка к точному времени по GPS, требуется минимальная задержка поступления данных в программу-клиент. Допустимую задержку я бы оценил в половину периода измерений, т.е. в 50 и 10 миллисекунд соответственно. Можно ли рассчитывать на задержку не более 10 миллисекунд для вариантов "смешанного" и "раздельного" набора модулей в крейтовой системе? Спасибо. P.S. крейты подключаются к ПК через быстродействующий коммутатор. |
|||
|
||||
|
Re: Крейтовая система LTRЛеонид, прочтите |
|||
|
||||
|
Re: Крейтовая система LTRОтвечаю на поставленные вопросы: Гарманов Александр пишет:
|
|||
|
||||
|
Re: Крейтовая система LTRС точки зрения времени поступления данных из крейта в ПК я не вижу явных аргументов за или против "раздельного" или "смешанного" набора модулей. Если скорость ниже максимальной с некоторым запасом, то при штатной работе без потерь данных и переповторов данные из крейта в любом случае будут постоянно откачиваться со скоростью их поступления и не будут накапливаться в крейте. А в случае наличия потерь в любом варианте нельзя гарантировать время передачи. В разных случаях будет несколько разный поток данных и на время передачи будут несколько по разному влиять алгоритмы управления потоком самого TCP, но это сильно зависит от конкретных условий и реализации стека TCP, поэтому тут мы не можем давать какие-либо явные гарантии. Если я не ошибаюсь, то Вы уже имеете опыт использования LTR под QNX, если в данном случае речь идет о использовании той же системы в качестве ПК, то Вы лучше нас можете сказать о применимости LTR с точки зрения задержек в конкретно вашей системе, т.к. это в любом случае требует тестирования на конкретной системе. |
|||
|
||||
|
Re: Крейтовая система LTRАлександр 1985 пишет:
- Всё правильно. Можно взять питание от LTR41. Александр 1985 пишет:
- Рекомендую использовать витые пары в общем экране . 4-х проводная схема обязательна. Александр 1985 пишет:
- Напомню, что LTR51 сможет корректно измерять тот сигнал, для которого можно установить фиксированный порог селекции по уровню. Александр 1985 пишет:
- При таких длинах LTR114 будет корректно измерять только на малых частотах коммутации. Я так понял, Вы хотите 100 Гц (для 10 каналов). Больше ставить не стоит. Александр 1985 пишет:
- До них тяните дифференциальные пары. Общий провод- отдельно. Общий экран обязателен. Александр 1985 пишет:
- Подключайте их дифференциальными парами. Общий провод- отдельно. Общий экран обязателен. |
|||
|
||||
|
Re: Крейтовая система LTRАлексею: Действительно, мы планируем использовать LTR-крейты, подключенные к ПК с ОС QNX (реального времени). К сож. пока мы имеем небольшой опыт тестирования и внедрения модулей LTR-27 и LTR-22 в 2-х позиционных крейтах с обменом по Ethernet. И только сейчас прорабатываем несколько "полноразмерных" проектов с использованием большого числа модулей. В связи с этим вопросы о задержках и об оптимальном распределении модулей в крейтах весьма актуальны. |
|||
|
||||
|
Re: Крейтовая система LTRПо поводу собственной задержки преобразования в LTR22: см. http://www.lcard.ru/download/ltr.pdf , п.11.3.1 По поводу собственной задержки преобразования в LTR27: поскольку там происходит простое усреднение за время, равное периоду преобразования, то время задержки такого фильтра равно половине от периода преобразования. По поводу аппаратной задержки крейта LTR-EU: там совсем неглубокие аппаратные буфера FIFO в FPGA. Вся остальная буферизация и логика стека TCP/IP делается программо в Blackfin. Поэтому, если нужно гарантированное время доставки, то нужно модифицировать ПО Blackfin, применив сетевой протокол с гарантированным временем доставки данных. |
|||
|
||||
|
Re: Крейтовая система LTRПри работе в режиме "AC" - с отсечкой с постоянной составляющей, добавится задержка аналогового ФВЧ с частотой среза 0,7 Гц, если входной сигнал имеет постоянную составляющую или частоты в спектре ниже 10 Гц. |
Страницы 1
Адрес: 117105, Москва, Варшавское шоссе, д. 5, корп. 4, стр. 2
Многоканальный телефон:
+7 (495) 785-95-25
Отдел продаж: sale@lcard.ru
Техническая поддержка: support@lcard.ru
Время работы: с 9-00 до 19-00 мск