Pixel + Lon

[lau]

Набор сетевых переменных LON-карточки для контроллера PIXEL строго фиксированный.
НО, на одном из форумов увидел сообщение, что Segnetics может зашить в карточку необходимый заказчику набор перменных.
Так ли это?

Вопрос актуальный, особенно если использовать модули расширения, то передать в LON состояния всех дискретных входов/выходов переменными типа SNVT_Switch не получится (т.е. запаковать состояни DI|DO побитно в перменную любого типа LON-PIXEL можно, но при условии, что принимающая сторона может их распаковать, а это сможет сделать либо контроллер типа PIXEL, либо SCADA. А что делать, если принимать данные должны устройства с жестко заданными профилями-наборами переменных?).

Класно было бы получить возможность менять типы LON перменных PIXEL хотябы в рамках уже предложенных типов. А также менять типы пермененных nvi и nvo.

[lau]

Идеальным был бы вариант, когда пользователь сам решает какого типа LON-переменные ему необходимы.
Понятно, что кол-во переменных ограничено чипом трансивера 64.

Именно такой подход существует на контроллерах JohnsonControls серии FX. Где задается набор переменных необходимых типов SNVT и в пределах суммарно 64 штук эти переменные могут быть nvi|nvo. Если решите изучать их подход - мой опыт к Вашим услугам.

Просто несколько обидно, когда вся мощь PIXEL как вычислительная, так и измерительная (входы-выходы) не может быть задействована и ограничивается набором перменных и их типов. Особенно это заметно при применении их в проектах по освещению наряду с устройствами мировых производителей LON-автоматики по освещению, где SNVT_sceene SNVT_switch основные переменные.

[AMD]

Цитата

Сообщение от lau

Набор сетевых переменных LON-карточки для контроллера PIXEL строго фиксированный.
НО, на одном из форумов увидел сообщение, что Segnetics может зашить в карточку необходимый заказчику набор перменных.
Так ли это?

Да, можем зашить набор переменных под заказчика. А самому можно поменять тип переменный не изменяя ее представления в сетевой карте:
например входную 2-байтовую переменную целочисленного типа SNVT_switch можно изменить на другую 2-байтовую переменную целочисленного типа, например SNVT_scene. Для этого надо подредактировать xif файл Pixel. C переменными с плавающей точкой такой же подход. Нельзя менять входную на выходную переменную, нельзя менять формат числа.

Цитата

Сообщение от lau

Идеальным был бы вариант, когда пользователь сам решает какого типа LON-переменные ему необходимы.
Понятно, что кол-во переменных ограничено чипом трансивера 64.

Вариант идеальный, но пока не реализованный.

[lau]

Необходимо, чтобы сверхважные переменные отправлялись в сеть LON незамедлительно.
Может ли значение переменной NVUpdateRate (определяет временной интервал отправки изменившихся переменных) быть меньше 1секунды, а в идеале равной нулю (при = 0 вообще отправка не происходит)?

[Arsie]

Насколько мне позволяют мои знания LON, то приоритетов переменных в LON'е не существует. А скорость сети на основе FTT-10 не настолько велика, чтобы ставить быстрые периоды обновления - так можно и канал связи завалить.

По поводу нуля секунд в NVUpdateRate ничего подсказать не могу, это сделает другой наш сотрудник.

[AMD]

При NVUpdateRate = 0 переменные обновляться не будут (извините, в документации не сказано). При малом интервале обновления NVUpdateRate возможны ошибки связи. NVUpdateRate переменная типа SNVT_time_sec : значению единица соответствует 100мс

[lau]

Тем не менее LON-устройства, например для освещения, реализуют незамедлительную отправку данных. Например, есть модуль дискретного ввода (выключтель садим не него) и модуль релейного вывода (актюатор; лампочка к нему подключена). Так вот при связи этих модулей через переменные SNVT_Switch передача данных моментальная (300мсек максимум при очень нагруженной сети).

Цитата

Сообщение от AMD

При NVUpdateRate = 0 переменные обновляться не будут (извините, в документации не сказано). При малом интервале обновления NVUpdateRate возможны ошибки связи. NVUpdateRate переменная типа SNVT_time_sec : значению единица соответствует 100мс

Что-то здесь не так. Т.к. в программе с циклом 100мсек реализована лишь запаковка в переменную SNVT_Switch состояния дискретного входа (без фильтрации) и при NVUpdateRate=1 время появления этого значения на nvo_SNVT_Switch составляет 1секунду, а не 0.1 секунду (как заявлено).
при NVUpdateRate=5 время составляет 5 секунд.
Возможно кратность единиц NVUpdateRate равная 100мсек была только задумана, а на практике реализована все-таки 1:1 ?

[AMD]

Извините, не расписал :
В Lon сети переменная NVupdateRate равная 1 = 1 секунда, 1,1 = 1сек 100мс, а в Лоджике ее целочисленное представление, т.е. если поставить переменную NVupdateRate на поляну получиться 10(1 сек), 11(1сек 100мс).

[lau]

Выставил NVUpdateRate равным "0.1" при помощи LonMaker. Что для ПИКСЕЛЯ, по Вашим словам, составляет 100мсек.
Так вот отправка SNVT_Switch происходит не со скоростью 100мсек (как ожидалось), а с 500-1000мсек.

Подтверждает это простой пример:
В ПИКСЕЛе реализована выдача на релейный выход состояния пришедшего по переменной nviSNVT_Switch, а на nvoSNVT_Switch идет сотояние кнопки F1. В LonMaker обе эти переменные связаны между собой (т.е. ПИКСЕЛЬ сам себе шлет данные). Так вот клацанье релюхи проиходит только через 500-1000мсек. (цикл PIXEL 100мсек).

Причем, что интересно, связка nvoSNVT_Switch от PIXEL с nviSNVT_Switch LON-реле другого производителя срабатывает быстрее.

[AMD]

Pixel передает данные сетевой карте, сетевая карта с задержкой в NVUpdateRate отдает их трансиверу. Через какое время трансивер выдаст в сеть переменную сказать не могу. Между Pixel и сетевой картой интервал обмена ~100 мс.
Сделал проект который сам себе через Lon передает значение кнопки, при помощи счетчика замерял интервал, получил значения от 100мс до 600мс. Тик был 10мс.

[lau]

Скажем так, что Тик=10мс слишком мал для любой среднестатистической программы.
При Тик=100мс см. предыдущее мое сообщение.

Давайте разбираться, почему так происходит?

Ведь даже в вашем примере, при заданном интервале обмена между ПИКСЕЛЬ и сетевой картой в 100мс, реальный интервал срабатывания (записи в ЛОН переменную) был в 6(шесть) раз больше заданного.

Может что-то не так в протоколе обмена между ПИКСЕЛЬ и ЛОН-картой?

[AMD]

Для какой задачи планируете применять? Какая требуется скорость? Сколько переменных будете использовать?

[lau]

Например, использоавание ПИКСЕЛя для расширения кол-ва бинарных входов в ЛОН сетке управления светом. А непосредственно управлять группой освещения будет актюатор любого производителя. Обхение между устройствами по сети ЛОН, поэтому вышеописанные задержки актуальны. Тем более видно, что данный момент в сетевухе или в самом ПИКСЕЛ, скорее всего поддается доработке.

[lau]

Цитата

Сообщение от AMD

Для какой задачи планируете применять? Какая требуется скорость? Сколько переменных будете использовать?

Задачеу описал выше. Скорость - да хотя бы заявленная (время тика). Либо не более 2-х тиков.

Кол-во переменных - все SNVT_switch.

А самое важное, что тормоза с обновлением данных происходит и по переменным типа nvi самого ПИКСЕЛь.

Для примера "1" определил в качестве источника nvo_SNVT_switch дискретный вход стороннего производителя.
В качестве получателя (через LonMaker) определил 3 устройства:
- само устройство источник
- iLon100 от Echelon
- PIXEL

Скорость с которой устройства "увидкли" измененные данные составила: - само устройство источник - менее 100мсек
- iLon100 от Echelon - менее 200мсек
- PIXEL - от 500-1000мсек.

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

[AMD]

ОК, попробую ускорить обмен. Через недельку напишу

[lau]

Обнаружил неприятную для себя штуку - когда задать через Системное меню->Конфигурация->СОМ-порт->Запросы Master = ВЫКЛ
обмен данными по LON прекращается .
Скажите, это так и задумано?
Прошелся поиском по Manual_Pixel_rev3.28 - о такой ситуации ни слова.
Обнаружено на Pixel 2501, Kernel 03.273.008, SMLogix 3.23.0303.

К сведению, при остановке мастера через блок "SlaveX (Link)->stop" такого не происходит.

[Arsie]

Цитата

Сообщение от lau

Обнаружил неприятную для себя штуку - когда задать через Системное меню->Конфигурация->СОМ-порт->Запросы Master = ВЫКЛ
обмен данными по LON прекращается .
Скажите, это так и задумано?
Прошелся поиском по Manual_Pixel_rev3.28 - о такой ситуации ни слова.
Обнаружено на Pixel 2501, Kernel 03.273.008, SMLogix 3.23.0303.

К сведению, при остановке мастера через блок "SlaveX (Link)->stop" такого не происходит.

Позвольте полюбопытствовать, зачем вы их выключаете?

А так-то всё просто и логично: в меню вырубается вся активность по всем портам. SlaveX для конкретного программного модуля.

[Arsie]

Цитата

Сообщение от lau

Выключаю Master-а для того, чтобы:
- залить в любой Slave обновленную программу

Сетевая работа включается обратно через тайм-аут в несколько минут. Если модбас включается, а LON нет, то это баг.

Так как было с LON на самом деле? Выключился и больше не включался или вы не проверяли?

[lau]

Цитата:

Сообщение от Arsie

Сетевая работа включается обратно через тайм-аут в несколько минут. Если модбас включается, а LON нет, то это баг.

Так как было с LON на самом деле? Выключился и больше не включался или вы не проверяли?

Повторю иными словами. Чтобы залить в Слейвы MODBUS ВЫКЛючаю работу Мастера MODBUS на ПЛК Мастер через системное меню ПЛК Мастер. Слейв сразу же после заливки в него программы в своем системном меню, т.е. в меню Слейва, показывает, что "Запросы Мастер ВКЛючен" и обмен данным по LON происходит. А вот Мастер ПЛК как был так и остался с ВЫКЛюченными "Запросы Мастер".

А если Вы имели в виду ВКЛючатся ли "Запросы Мастера" на MODBUS Мастер ПЛК самостоятельно спустя "тайм-аут" после того как через системное меню они были ВЫКЛючены - завтра произведу точный замер времени. Предварительно по ощущениям этого не происходило в течении минут 5, далее посчитал что это "навсегда" и вручную включал "Запрсы Мастера" из сист.меню. В общем отпишусь.

[lau]

Напомню, необходимость отключать "запросы Master" из системного "PLC MODBUS Master" возникает из-за потребности залить программы его слейвам по MODBUS. Оказалось, что отключение "запросы Master" отключет обмен данными и по LON, о чем явно нигде не указано.

Проверка "иайм-аута" (см. выше):

ВЫКЛлючил в системном меню PLC "запросы Master" и вышел из системного меню:
- спустя 5 минут на PLC MODBUS Master "запросы Master" автоматом не включились (судя по меню), LON сеть не видит ПЛК, также как и ПЛК не видит LON
- спустя 14 и 20 минут аналогичная ситуация

"Видит" или нет PLC MODBUS Master сеть LON и сеть LON его определяю по изменению "общей" переменной напрямую как на ПЛК так и из сети LON.

[Arsie]

Цитата

Сообщение от lau

Напомню, необходимость отключать "запросы Master" из системного "PLC MODBUS Master" возникает из-за потребности залить программы его слейвам по MODBUS. Оказалось, что отключение "запросы Master" отключет обмен данными и по LON, о чем явно нигде не указано.

Проверка "иайм-аута" (см. выше):

ВЫКЛлючил в системном меню PLC "запросы Master" и вышел из системного меню:
- спустя 5 минут на PLC MODBUS Master "запросы Master" автоматом не включились (судя по меню), LON сеть не видит ПЛК, также как и ПЛК не видит LON
- спустя 14 и 20 минут аналогичная ситуация

"Видит" или нет PLC MODBUS Master сеть LON и сеть LON его определяю по изменению "общей" переменной напрямую как на ПЛК так и из сети LON.

Если вы РУКАМИ что-то выключаете, то система ждёт дальнейшего вашего решения, т.е. включения руками обратно.

Из этого есть два исключения: загрузка программы включает всё обратно. Сброс питания также включает всё обратно.

Баг в том, что это не "описано в описании". спасибо за наводку, поправим.

[Nick]

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

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

[lau]

Цитата:

Сообщение от Nick

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

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

Никто не спорит, все логично.
Но:
- в описании это не написано (касательно LON)
- некорректное название в системном меню контроллера "СОМ-порт -> Запросы Master ВКЛ/ВЫКЛ" по отношению к сети LON (в LON нет ни Мастера, ни СОМ-порта, есть тольео специальная сетевая карта).

ИМХО - дать название этому п.меню, которое бы подсказывало пользоватю что и LON это касается также.

[lau]

Цитата:

Сообщение от Arsie

Сетевая работа включается обратно через тайм-аут в несколько минут. Если модбас включается, а LON нет, то это баг.

Так как было с LON на самом деле? Выключился и больше не включался или вы не проверяли?

Чуть выше Я детально описывал эксперимент, уточнял верно ли Вас понял.

В эксперименте отключив в системном меню "Запросы Master" и далее ничего не делая с PLC, а только вышел из системного меню:
- спустя 5 минут работа по LON не возобновилась
- спустя 14 минут также
- спустя 20 минту также LON не работал

Как только "Запросы Master" через сист.меню включил - обмен данными по LON заработал.

[Nick]

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

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

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

[lau]

Очень часто (не реже 3-х раз в сутки) фиксирую аварию "Сбой сет. модуля" на PIXEL с карточкой LON.
При этом обмен данными по LON происходит и вроде бы никак не влияет на работоспособность системы.

Суммарно в одной сети 10шт. PIXEL с карточкой LON, и на каждом происходит вышеописанная авария, единственное, что периодичность их возникновения иная.

Чем чревато игнорирование данной ситуации?
С чем может быть связано ее возникновение?

Контроллеры как и сами карточки были куплены ~2года назад, а произведены может быть и более.
Привожу часть SN ПЛК: 44701,43640, 42345, 50502.
Версии ядeр 03.267.008

[Arsie]

Цитата

Сообщение от lau

Очень часто (не реже 3-х раз в сутки) фиксирую аварию "Сбой сет. модуля" на PIXEL с карточкой LON.
При этом обмен данными по LON происходит и вроде бы никак не влияет на работоспособность системы.

Суммарно в одной сети 10шт. PIXEL с карточкой LON, и на каждом происходит вышеописанная авария, единственное, что периодичность их возникновения иная.

Чем чревато игнорирование данной ситуации?
С чем может быть связано ее возникновение?

Контроллеры как и сами карточки были куплены ~2года назад, а произведены может быть и более.
Привожу часть SN ПЛК: 44701,43640, 42345, 50502.
Версии ядeр 03.267.008

Посмотрите, с температурой корпуса всё ок? Это появилось недавно или всю жизнь было?

Сбои сами по себе неопасны - модуль автоматически перезапускается и работает дальше.

[yur15t]

Аналогичная проблема с Pixel - "Сбой сет.модуля". Модуль работает, но обмена данными по сети нет (контроллер оффлайн). Верхний уровень - сетевой контроллер Johnson Controls MS-NAE5520-1E.

Корпус греется.

[gradusmax]

Доброго времени суток, хотелось узнать будет ли работать пиксель по LON c модулями Honeywell (xfl821a, xfl822a, xfl823a, xfl824a) и есть ли какие нибудь наработки в этом направлении.

[tvf]

Цитата

будет ли работать пиксель по LON c модулями Honeywell

Работать то может и будет, но есть в этом смысл? LON карта сегнетикса имеет фиксированный набор переменных, так что большим количеством модулей расширения рулить вряд ли получится. Цену модулей вряд ли можно назвать гуманной. Потребуется дополнительное ПО для организации LON-сети, тоже платное. Какой смысл скрещивать ежа с ужом? 2 метра колючей проволоки можно получить гораздо меньшими усилиями - применением аналогичных по назначению модулей ModBus RTU/TCP.