Форум: Выбор оборудования

Здравствуйте!
Так как на письмо на адрес support@lcard.ru в течение обещанных 2 дней ответа не поступило то размещу вопрос в форуме:

Во вновь проектируемой измерительной системе необходимо организовать измерение:
- 64 каналов 4-20мА,
- 3 каналов – частотных (до 3,5 кГц),
- 19 каналов измерения вибрации,
- 10 каналов измерения напряжения 0…10В,
- 16 каналов измерения термосопротивлений,
Также требуется предусмотреть обслуживание 10 каналов дискретного ввода типа «сухой контакт»

В качестве средства измерения планируем использовать крейтовую систему LTR на базе LTR-EU-16-1:
- для организации  64 измерительных каналов 4-20 мА планируется использовать модуль LTR27 в количестве 4 штук с установленными в них субмодулями Н-27I-20 (частота опроса 10 Гц);
- для каналов измерения частоты планируется использование модуль LTR51 с установленными в нем субмодулями H-51FL (частота опроса 10 Гц);
- для 19-ти каналов измерения вибрации планируется использование 6-ти модулей LTR22. Каналы измерения вибрации будут подразделяться на «медленные» 10 каналов  (50-250Гц) - настройка LTR22 на частоту дискретизации до 4кГц и быстрые 9 каналов (0-20кГц) -  настройка LTR22 на частоту дискретизации 78 кГц;
- для каналов измерения напряжения 0…10В (частота опроса 10 Гц) планируется использование универсального прецизионного АЦП -  LTR114 в количестве 1шт.;
- для каналов измерения термосопротивлений (частота опроса 10 Гц) планируется использование универсального прецизионного АЦП -  LTR114 в количестве 2 шт.;
- для организации 10 каналов дискретного ввода типа «сухой контакт» (частота опроса 10 Гц) планируется использование модуля цифрового ввода LTR41 в количестве 1 шт.
Итого получается занято 15 позиций в 16-ти позиционном крейте.

В процессе проектирования возникли следующие вопросы:

Целесообразно ли разделить подсистемы измерения вибрации и остальных измерительных каналов в разные LTRкрейты? Или же есть возможность разместить все вышеперечисленные модули в количестве 15 штук в одном 16-ти позиционном крейте LTR-EU-16-1?

Хватит ли, при описанной выше конфигурации LTRкрейта, пропускной способности Ethernetинтерфейса LTR-EU-16-1 для передачи данных? Не получится ли ситуация что Ethernetинтерфейс не сможет обеспечить требуемый поток данных.

Допускается ли совмещать в одном LTR22 «быстрые» каналы вибрации и «медленные» каналы вибрации?

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

- Пропускной способности хватит - в вышеописанной конфигурации, c сетью Ethernnet 100 Mb/s, свободной от стороннего трафика.

- 4 канала LTR22 могут работать только с одной настроенной частотой преобразования АЦП. Для экономии трафика, для оптимальной полосы частот пропускания, а также для обеспечения идентичных времён задержки преобразования,  "медленные"  каналы  желательно реализовывать в рамках одной группы LTR22, а "быстрые" - в рамках другой группы LTR22.

Замечания:
Для реализации "сухого контакта" в LTR41 понадобится либо внешний источник питания, либо напряжение можно снять с 16-го модуля LTR00.

Вопросы:
1. Какие номинальные сопротивления у термосопротивлений? Какая планируется максимальная длина кабеля от них? Термосопротивления - изолированные?
2. Какая величина напряжения частотного сигнала? Какое выходное сопротивление выхода частотного сигнала? 
3. Какая максимальная длина кабеля до LTR114?
4. Источники напряжения 0…10В - "с общей землёй" или изолированные ?
5. Источники напряжения каналов вибрации "с общей землёй" или изолированные ?

Извините, еще раз "заострю" вопрос:

Как бы посоветовали разработчики LTR:

- вариант 1
разместить модулиLTR-22 c частотой опроса 4 и 40 кГц в один крейт "быстрых измерений", а остальные модули с частотой опроса 10Гц во второй крейт "медленных измерений";

- вариант 2
разместить все модули в один крейт "смешанных" измерений.

Вариант 2 дешевле и займет меньше места в шкафу.

Есть ли преимущества у варианта 1 с учетом того, что суммарного превышения трафика 100 мбайт/сек не предполагается.

Спасибо.

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

Размещая все модули измерительной системы в одном крейте, Вы имеете важное свойство когерентности частот преобразования всех модулей и когерентности частот импульсного питания всех модулей.  Если речь идёт об одной измерительной системе, то наличие такой когерентности довольно важно, см.:
http://www.lcard.ru/lexicon/incoherent_ … ies_factor
Кроме того, в одном крейте проще устроить синхронизацию по меткам синхронизации.

C другой стороны, если измерительные каналы разных крейтов  никак друг с другом не взаимодействуют (например, через взаимовлияние кабелей от датчиков), эти измерения относятся к разным физическим процессам или к разным объектам измерений, эти процессы измерений не нужно точно синхронизировать по времени, то, вероятно, вышеупомянутое свойство когерентности не будет иметь значения.
Замечу также, что между двумя крейтами LTR, работающими по Ethernet, может в какой-то момент возникнуть очень большая разница задержек получения отсчётов из-за глубокой буферизации данных в каждом из этих крейтов из-за особенностей работы протокола TCP/IP.
http://www.lcard.ru/support/faq/usb_or_ethernet

Я так понял, что подразумевали  10 Мбайт/c. Для обеспечения этого почти максимальнрого возможного для Fast Ethernet трафика, как правило, используют выделенную сеть "точка-точка" от отдельной сетевой карты ПК.

Разделение каналов на "медленные" и "быстрые" по разным крейтам может иметь смысл, если:

• связь по Ethernet неважная;

• организация задачи измерения такова, что поток данных от медленных каналов должен быть независимым (допустим, с возможностью независимого рестарта сбора данных);

• разные крейты выполняют какие-то функции измерения как дублирующие, что повышает общую надёжность системы;

• процессор в крейте выполняет какие-то специализированные  функции обработки сигнала (применено специальное встроенное ПО или такое ПО запланировано);

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

Извините за опечатку, я должен был написать 100 мбит/сек.

Могу ли я сделать вывод, что при "смешанном" наборе модулей крейта данные из модулей "медленных" измерений (10Гц) будут приходить клиенту в ПК с бОльшей задержкой, в связи с большИм объемом данных "быстрых" (4-40кГц) измерений?

И наоборот, при наборе в крейте модулей только "медленных" измерений (10Гц) данные измерений будут приходить клиенту в ПК с минимальной задержкой.

---

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

Судя по описанию, синхронизация может быть выполнена внутренними возможностями крейта ( привязка к метке "Старт").

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

Тогда это абсурд, поскольку 100 Мбит/с - это предельная физически достижимая скорость 100BASE-TX, включая служебную информацию TCP/IP.
У нас успешно тестировался LTR-EU на  10 Мбайт/с (это 80 Мбит/c) полезной информации при хорошей связи "точка-точка".

Наверное, можете, при прочих равных условиях, в среднестатистическом смысле, поскольку при большем трафике очередь на передачу может быть больше. Но в TCP/IP этих "прочих" условий, влияющих на задержку получения данных, очень много.

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

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

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

Допустимую задержку я бы оценил в половину периода измерений, т.е. в 50 и 10 миллисекунд соответственно.

Можно ли рассчитывать на задержку не более 10 миллисекунд для вариантов "смешанного" и "раздельного"  набора модулей в крейтовой системе?

Спасибо.

P.S. крейты подключаются к ПК через быстродействующий коммутатор.

Леонид, прочтите
http://lcard.ru/support/faq/realtime_on_pc
При этом (если дописывать эту статью)  задержка Ethernet с TCP/IP, может быть больше, чем USB.  На сколько? Какие гарантии? - На эти вопросы точно Вам никто не ответит, поскольку эти вопросы экспериментальные, зависящие от программной среды, и они имеют смысл только в среднестатистическом смысле.  Windows - не среда реального времени, а TCP/IP (как и USB) - не протокол с гарантированным временем доставки!
По поводу "быстродействующего коммутатора": опять же, никаких гарантий на скорости 10 Мбайт/c, поскольку он может дробить пакеты на более мелкие, и это реально ограничит пропускную способность.- С коммутатором тестировать нужно будет на этом трафике, да ещё как-то создавать реальную пиковую ситуацию загрузки всей сети...
Кстати, перевод LTR на реал-тайм программную среду и на реал-тайм протоколы технически вполне возможен. - Вопрос: кто это ПО напишет? Перевод LTR на гигабитный Ethernet тоже возможен. - Эти разработки  нужно финансировать.  Поучаствуете?

Отвечаю на поставленные вопросы:
К "Замечанию": в руководстве на LTR крейт указано наличие 5В источника питания с током нагрузки до 300мА. Исходя из этого планировалось задействовать его для питания сухого контакта.
Пункт 1: Планируется использовать термосопротивления с НСХ 100М, 100П. Длина линии связи не более 30м. Термоспротивления изолированные.
Пункт 2 : Величина частотного сигнала 0-5В, с частотой 0-3500 Гц
Пункт 3: Длина линии связи не более 30м
Пункт 4: Источники напряжения будут с "общей землей"
Пункт 5: Источники напряженияканалов "вибрации" будут с "общей землей"

С точки зрения времени поступления данных из крейта в ПК я не вижу явных аргументов за или против "раздельного" или "смешанного"  набора модулей. Если скорость ниже максимальной с некоторым запасом, то при штатной работе без потерь данных и переповторов данные из крейта в любом случае будут постоянно откачиваться со скоростью их поступления и не будут накапливаться в крейте. А в случае наличия потерь в любом варианте нельзя гарантировать время передачи. В разных случаях будет несколько разный поток данных и на время передачи будут несколько по разному влиять алгоритмы управления потоком самого TCP, но это сильно зависит от конкретных условий и реализации стека TCP, поэтому тут мы не можем давать какие-либо явные гарантии. Если я не ошибаюсь, то Вы уже имеете опыт использования LTR под QNX, если в данном случае речь идет о использовании той же системы в качестве ПК, то Вы лучше нас можете сказать о применимости LTR с точки зрения задержек в конкретно вашей системе, т.к. это в любом случае требует тестирования на конкретной системе.

- Всё правильно. Можно взять питание от LTR41.

- Рекомендую использовать витые пары в общем экране . 4-х проводная схема обязательна.

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

- При таких длинах LTR114 будет корректно измерять только на малых частотах коммутации. Я так понял, Вы хотите 100 Гц (для 10 каналов). Больше ставить не стоит.

- До них тяните дифференциальные пары. Общий провод- отдельно. Общий экран обязателен.

- Подключайте  их дифференциальными парами. Общий провод- отдельно. Общий экран обязателен.

Алексею:

Действительно, мы планируем использовать LTR-крейты, подключенные к ПК с ОС QNX (реального времени).

К сож. пока мы имеем небольшой опыт тестирования и внедрения модулей LTR-27 и LTR-22 в 2-х позиционных крейтах с обменом по Ethernet.

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

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

По поводу собственной задержки преобразования в LTR22:  см. http://www.lcard.ru/download/ltr.pdf , п.11.3.1

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

По поводу аппаратной задержки крейта LTR-EU: там совсем неглубокие  аппаратные буфера FIFO в FPGA. Вся остальная буферизация и логика стека TCP/IP делается программо в Blackfin. Поэтому, если нужно гарантированное время доставки, то нужно модифицировать ПО Blackfin, применив сетевой протокол с гарантированным временем доставки данных.

При работе в режиме "AC" -  с отсечкой с постоянной составляющей, добавится задержка аналогового ФВЧ с частотой среза 0,7 Гц,  если входной сигнал имеет постоянную составляющую или частоты в спектре ниже 10 Гц.