Хотим узнать Ваше мнение.
Разрабатываем свободно программируемый LON - контроллер , который позволит использовать 62 переменных фиксированных типов. Предпологаем использовать 30 input (15 int переменных, 15 float переменных) и 30 output (15 int переменных, 15 float переменных). Эти переменные можно будет использовать в FBD проекте (по типу IsaGraf).
Удовлетворит ли Вас данный набор переменных?
Могли бы Вы предложить свой вариант набора переменных?

Если это Лон контроллер, то необходимо использовать SNVT.
По количеству. Для каких целей будет использоваться этот контроллер, количество I/O?

Основное направление: вентиляция и кондиционирование
Количество I/O:
DI -6
D0 -3
AI -6
AO -2

А если области применения будут различными, то как подобрать SNVT, или для каждого клиента придется создавать свой набор переменных?
Существует ли универсальный подход?

Пишите плагин для привязки внутренних переменных контроллера к внешним. ИМХО snvt - лишнее.

Некоторые производители свободно программируемых LON контроллеров при производстве зашивают все переменные как UNVT. А поставляемый ими плагин позволяет менять UNVT на любой SNVT. Очень удобно.

А где можно найти информацию по этим контроллерам?

Из Neuron C Programmer’s Guide узнал, что
если переменную сделать со свойством Changeable Type и размером 31 байт то в Lonmaker ee можно будет заменить на любую SNVT.

А в FBD проекте ее придется соответсвующим образом кодировать - декодировать..

Мы используем контроллеры ELKA. Там есть возможность выбора любого типа SNVT. Плагин качается с их сайта бесплатно.

nvo должно быть больше, чем nvi.
42 nvo, 20 nvi, а может и 10 хватит.

Посмотрите, как это сделано у Wago, www.wagotoplon.com
Там есть штук 15 типов профайлов для контроллера с различным числом переменных (NVI/NVO), пользователь выбирает нужный и сам задает типы SNVT/SCPT через LNS-плагин Toplon-prio. Только производителем судя по всему был проделан большой объем программирования для достижения этих возможностей.

Спасибо, посмотрел.
Надо последовать примеру, но объем программирования большой...


Насколько будет востребовано решение с фиксированными перемменными?

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



P.S.
С кем-нибудь можно посоветоваться по поводу использования changeable type переменных в ShortStack API?

Посмотрите еще плагин для свободнопрограммируемых контроллеров от Distech тут Дистрибутив довольно большой порядка 11 метров и на сайте его вроде нет.

В контроллерах TAC Xenta 280/300 все nvi/nvo создаются при программировании. Типы могут быть любыми, действует только общее ограничение на число снивитов -- 15/30. На мой взгляд, самый удобный вариант.

Ну получите Вы стандартный контроллер, можете да же для него стандартный профиль разработать. Будет некий аналог ОВЕН ТРМ133 (и клонов) с интерфейсом LonWorks.
Я не куплю 100% из-за нестандартных задач, кто-то возьмет. Если сможете сделать вариант аля Сегнетикс по цене и внешнему виду (PLC+HMI) с нормальной средой программирования (CoDeSys например), отбоя ИМХО не будет от клиентов. А так скорее всгео получите очередную погремушку в корпусе на DIN рейку

И тогда получим навороченную систему с хост-процессором, который собственно будет программироваться КодеСисом, а нейрон чип будет использоваться лишь для коммуникации с Lon’ом. В общем, выйдет Wago по-русски. Только какими преимуществами перед Wago будет обладать контроллер для автоматизации зданий по такой схеме? Если таки идти по этому пути, то могу предложить увеличить число сетевых переменных до 4096 (возможно, делая систему не на привычном Neuron chip, а на L-Chip от Loytec), а также сделать модификацию с Lon over IP, благо в L-Chip помимо LonTalk организован стек TCP/IP. Реализация всего этого непроста, но в случае успеха такой девайс займет достойное место на рынке.

Первая модель будет с фиксированными переменными, PLC на DIN рейку.
Потом появится плагин для конфигурирования переменных.
Когда-нибудь дело дойдет и до L-chip(в России пока ненашел продавца) с 4096 переменными, BACNet и TCP/IP...

Чем так хорош Codesys?

P.S. Для иностранных разработчиков нормально купить исходники готовых Stack'ов (BACNet, TCP/IP) за 30т. у.е, портивать на свою аппаратную часть и в результате быстро выпустить продукт.
Наши разрабочики ищут бесплатные варианты и пишут сами...



Добавлено - 09:35

Ценой изделия.

на Sourceforge.net лежит много бесплатных стеков....

Не мешайте мух с котлетами. Речь идет о моноблочном контроллере с фиксированным количеством входов - выходов. Его преимущество - цена. Решаемый класс задач - ограниченный. Процессор там можно какой-нибудь с уже встроенными АЦП и ЦАП впихнуть.

Добавлено - 14:03


Тем что это полноценная среда разработки.

Относительно интерфейса:
Какую сетевую информацию хотелось бы видеть на дисплее (Neuron ID, Program ID, State и т.д. )?
Какие сетевые параметры настраивать с клавиатуры(Send update rate, receive update rate) ?
Реакцию на Wink сделать доступной при проектировании или чисто аппаратной?

Наиболее полезно будет видеть State контроллера. Хотя часто состояние контроллера отображается при помощи специального светодиода на морде контроллера.

У Echelon есть пример на сайте интеграции Lontalk в мотороловский процессор Со всеми исходниками на С++ и подробными комментариями. Но это не для средних умов. Идея примера - показать возможность крутить Lontalk на любом хост процессоре.

В меню отображение
State и Neuron ID , больше никаких натроек.
Все остальные настройки через FBD проект.

Соединил переменные через Lonmaker и пытаюсь Browser посмотреть значения на контроллере включив Monitor All, получаю ошибки коммуникации и ? в ячейках где должны быть значения. Между контроллерами обмен переменными есть.

Может не хватает производительности сети для Browser или я неправильно настроил обмен?

Производительности для сети из 2х контроллеров???? Ошибки в браузере иногда появляются из-за проблем с сетью, помех. Один раз был контроллер, который периодически вываливался из сети целиком, помогало отключение питания, ну и потом замена контроллера.

Какая правильная концепция использования переменных

SndHrtBt,RcvHrtBt

SndHrtBt
1.Контроллер обновляет свои переменные при изменение значений, но не быстрее чем SndHrtBt
2.Контроллер обновляет свои переменные независимо от изменений значений, только в соответсвии с SndHrtBt
например SndHrtBt = 1с,
а)30 переменных раз в 33мс Propagate 1 переменной
б) раз в 1с Propagate всех переменных без задержки
в) раз в 1с обновление одной переменной(30 переменных за 30с)
3.Контроллер обновляет свои переменные только при изменение значений (получилось из эксперимента с Corrigo Regin C10: перестал менять значение nvo у С10, отключил контроллер на который приходила переменная, после включения питания nvi переменная была 0, подождал время SndHrtBt значение не обновилось)
4. Контроллер обновляет переменные при изменение значений и по истечению времени SndHrtBt

С SndHrtBt и RcvHrtBt все просто.

LonWorks - событийная сеть равноправных устройств, т.о. получатели информации непрерывно ожидают изменение входных переменных, а отправители могут осуществить передачу в произвольный (и для получателя и для отправителя) момент времени. Если, руководствуясь этим принципом, отправитель и получатель находятся в какой-либо цепи регулирования, то возникает проблема для получателя в достоверности отсутствия данных в интервале времени, а именно, неопределенность причины отсутствия изменения контролируемых величин (входной(ых) переменной(ых)), то ли они действительно не изменяются, то ли отправитель физически отсутствует (выключился).
Так вот, для таких ситуаций и введено понятие HeartBeat. Таймеры HeartBeat'ов помогают выше сказанную неопределенность разрешить.

Таймер SndHrtBt - таймер отправителя - предписывает временной интервал отправки выходной переменной вне зависимости от её изменений. Т.е. если выходная переменная изменяется, то эти изменения отсылаются незамедлительно, а если она не изменяется, то её данные отсылаются каждые SndHrtBt.
Таймер RcvHrtBt - таймер получателя - предписывает временной интервал получения входной переменной при условии, что эта переменная связана. Если в течении этого интервала времени входная переменная не получила никаких данных, то считать, что отправитель не функционирует, а значит текущее значение входной переменной не действительно. Как правило, в алгоритме получателя предусмтривается такая возможность, как сигнализация о нарушении в цепочке регулирования, или принятие значения некой предустановленной величины, или ... еще что-нибудь.
Типивое условие для HeartBeat'ов следующее
RcvHrtBt >= 4*SndHrtBt

Спасибо за помощь!

Когда контроллер в сети пытается обновить все 30 выходных переменных в немедленном порядке из-за изменения значений - в LonBrowser возникают ошибки коммуникации при мониторинге переменных.
В результате получилось, что LonBrowser нормально работает, только если есть задержка между обновлением переменных около 50мс, т.е 30 переменных обновляется за ~1,5 - 2c.
Аналогичная ситуация при обновлении по SndHrtBt - приходится вводить задержку и в результате min SndHrtBt равен 1,5 - 2c.

Убедитесь, что Ваш сегмент LonWorks корректно терминирован (установлена согласующая нагрузка в линии LonWorks).

По-умолчанию, LonBrowser использует для мониторинга переменных периодические (частые) прямые сетевые запросы (Net Var Fetch) с сервисом "Request-Response". Поэтому при включении монитоинга всех переменных сетевой трафик возрастает - иногда даже критически при большом количестве переменных, которые мониторятся таким образом - и нагрузка на узел тоже.

Для того, чтобы мониторинг переменной в Browser'е был организован связью с этой переменной, необходимо в свойствах переменной на закладке Monitor Options установить флажок "Bind this variable to the browser for ...". При мониторинге, в этом случае, обновление будет происходить именно с обновлением переменной (или приходом HeartBeat'а).

Спасибо!
Установка флажка "Bind this variable to the browser for ...". решила вопрос с NVO переменными, а NVI переменным такой значок не поставишь...

Да, это так. Значения входных можно получить или Fetch'ем, или мониторингом связанных с ними выходных.
А зачем мониторить входные??? В них же можно просто передавать значения, или напрямую из LonBrowser'а, или связав их с созданными выходными переменными функционального блока сетевого интерфейса и устанавливая эти выходные переменные.

Планируем модули расширения для контроллера:
Есть ограничение по числу каналов не более 8, т.е. 8 DI, 8DO и т.д. или сочетания 4 DI, 4DO, возможно сделать универсальные входы-выходы.
Общее количество модулей не более 8.

На сколько востребованы универсальные аналоговые, цифровые IO?
Могли бы Вы предложить варианты сочетаний каналов?

Имеет ли смысл делать на слабом контроллере полевого уровня BACNET , или хватит одного Лона?
В моем понимании на Lon'e автоматизируют этажи, а на BAСNet здания, и районы.

Вопрос о BACNet или LON - вопрос не простой. Это связано с противостоянием и конкуренцией "этих двух". Некоторые считают, что BACNet - это профанация и повод для "обмана трудящихся", другие, что LON - это "закрыто" и для ограниченного набора задач.
Мое личное мнение, - LON'а достаточно и для полевого уровня (этаж, дом, ангар ...) и для зданий, используя переход в IP сеть. Т.о. функционально было бы так: [оконечные устройства]-[LON]-[IP]-[Приложения].
Вход в IP-сеть решает вопрос масштаба, это здание, завод, район, город ...

При разработке систем диспетчеризации на LON соотношение DI/DO примерно 3/1 Модуль 6DI/2DO был бы интересен. Выходы лучше ставить релейные, хотя бы 5А 230В. Еще не помешала бы недорогая железка с хорошим IP, способная считать импульсы и принять 3-4 "сухих" контакта. Так и вижу её применение в водомерных узлах, для контроля положения задвижки и технического учета потребления воды.

Какая диагностика нужна User'у LON сети?

Надо ли на контроллере отображать данные Lon узла
Transmission Errors: 0
Transaction Timeouts: 0
Receive Transaction Full Errors: 0
Lost Messages: 0
Missed Messages: 0
Reset Cause: Power Up
Node State: Configured, Online
Version Number: 15
Error Log: No error.
Model Number: Neuron 3150 Chip
Или этой информацией, кроме node state никто не пользуется?

Как контроллер может определить наличие сети, если на его входы данные не приходят, а обновление выходов происходит при помощи запросов без потверждения

AMD а Вы не думали о прикручивании LON'a к конечному оборудованию, например датчика перепада давления, термостатам, как это сделано например у Thermokon. Просто LON контроллер это слишком обычно, а вот такие устройства очень востребованны рынку. Я бы например с удовольствием купил бы потолочный датчик, который:
- Меряет температуру [управление фанкойлами]
- Меряет влажность [просто мониторинг]
- Меряет освещенность [управление жалюзи и балластами]
- Меряет содержание диоксида углерода [управление VAV клапанами]
- Определяет движение в комнате [управление включением света и температурой]

Опционально:

- Меряет содержание моноксида углерода [полезно для котельных, каминных залов и т.п.]
- Меряет содержание летучих органических соединений (VOC) [полезно для кухонь, обеденных залов, туалетов и т.п.]

Можно сделать poll() для связанных входных переменных, и если результат отрицательный, значит нет сети или нет источника данных.

А в ситуации, если Пользователь не связал свои входные переменные, не обновляет свои выходные переменные, а просто подключил контроллер к сети, то мог бы Он с контроллера определить наличие сети без дополнительного программного обеспечения или без программ типа LONMAKER не обойтись...

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

Ну, можно, например, делать QueryStatus какого-нибудь другого узла по S/N или по NueronID.

Не забудьте отслюнявить % за идею Я просто сам собирался собрать маленькую команду и сделать такой датчик. Если Вы сделаете - это будет БОМБА - можете спокойно в Европу и США гнать их сотнями - там озабочены вопросами комфорта и энергосбережения. Он как раз охватывает все сферы современных инженерных систем зданий и работает по принципу "одна комната - один датчик". Для больших - несколько. Могу еще пару идей насчет LON датчиков подкинуть За % Так что можем посотрудничать в этом плане - у меня да же ТЗ на некоторые датчики написанны.

А вообще LoN изначально разрабатывался для конечных устройств - слабый процессор, много входов выходов, дешевая цена. Странно что все пытаются создать на его основе "контроллер". Такие устройства делают сотни фирм, и уж поверьете есть из чего выбрать. LON датчики делают два-три производителя. Набор датчиков в HVAC ограничен. Прикрутите к самым распространенным LON - получите инновационный продукт, устойчивые продажи и известность, сделает контроллер - будете тягаться с Sauter, Honeywell, TAC, Wago, JCI, Siemens и т.п.

Действительно, это так, но ничего странного нет. Если Вы посчитаете цену имплементации Neuron чипа в оконечное устройство, то получится дороговато, т.е. существенно дороже узла, обрабатывающего N входов/выходов оконечных устройств.
Кстати, понимая это, Echelon создал новое направление - продукт Pyxos, который, в понимании Echelon'а, и должен решать задачи интеллектуализации оконечных устройств.

Но, безусловно, идея - Neuron в каждый датчик или исполнительное устройство - не плоха даже сама по себе. Весь вопрос в экономике конкретных решений. Если счетчик электроэнергии не сильно удорожится от присутствия Neuron'а в нем, то датчик температуры - удорожится на порядок (если не больше).

Тут несколько другая философия. Да же если устройство встанет в два раза дороже, это будет выгоднее. Поясню. Допустим что бы измерить температуру в одной точке нам нужно [условно]:

Датчик - 1 шт.
Вход контроллера - 1 шт.
Место в шкафу под контроллер и клеммы - 1 шт.
Кабель экранированный - 100 м.
Лоток для поддержания этого кабеля: 100 м.
Трудозатраты на монтаж и прокладку кабеля - 100 единиц.

Если Вы подсчитаете трудозатраты на эти операции, то они встанут гораздо выше чем лишние 40 евро за нейрон чип с АЦП + обвязка + разработка в конечном датчике. Например 1 вход аналогового измерения в современном импортном модульном контроллере Wago обходится в 60 евро (240 евро/4), датчик импортный Pt1000 стоит 40 евро. Кабель и лоток и место в шкафу уже не считаю, т.к. тут все индивидуально, но допустим еще 50 евро. Итого 150 евро. Сделаете датчик с Neuron внутри за 80 евро (что вполне реально) - получите автоматическую выгоду.



Можно идти по пути усложнения этого узла. Например датчик описанный мной выше задействует все входы чипа и заменяет собой 3-4 отдельных датчика.

Вообще-то у Т.А.С. есть кое-что подобное STR-350/351, только стоит это устройство за 200 у.е. Поэтому наверное дешевле простые датчики с контроллером.

Оперативные расчеты таковы:
Neuron FT3120 - 740 р.
Трансивер FT-X1 - 75 р.
Печатная плата - 30 р.
Разъемы - 14 р.
АЦП - 65 р.
Датчик температуры (PT1000) - 1400 р.
Обвес (цепи питания, монитор ресета, кнопка, светодиод, генератор и пр. мелочь) - 70 р.
Монтаж - 90 р.
Корпус - 40 р.
Упаковка - 6 р.
---------------------------
ИТОГО - 2530 р. и это только прямые затраты.

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

Т.о. цена такого устройства будет составлять 5060 р. или около 147 евро.

У меня тут возникла одна задумка, только не знаю возможно ли ее реализовать в железе. На в скидку, сможет ли Neuron:

1. "Щелкать" 5 дискретными выходами (реле).
2. Уметь обрабатывать 8 дискретных входов (сухой контакт).
3. Уметь обрабатывать сигналы как минимум 3-х АЦП (с I2C или SPI на борту) - лучше больше.

Если не может что нужно сделать что бы он смог? Добавить хост процессор? Или как-то можно "размножить" ноги чипа?





Не много ли? Вроде там речь идет о 7-10$. Производства Toshiba или Cypress.



Это очень много!!! Столько тсоит датчики с расстаможкой, проивзеденный в Германии с кучей накруток! 100-400 р. более верная цнеа при массовом производстве (коробка пластиковая + нога с чувствительным элементом).

FT3120 - формально является продукцией Echelon'а, и стоит "там" 19 USD. Плюс доствка, растоможка, НДС ... вот и выходит около 740 р.
7-10 USD будет стоить простой 3150, а к нему нужна внешняя память, некоторая логика, и трансивер FTT-10А (кстати сказать, который стоит 16,50 USD "там").

И датчики температуры разные бывают от 2 до 100 евро. Конечно можно взять, ну просто-просто, самый дешевый. Например ...

Не в плане спора. Возможно дополнения будут полезны.
1. Ни в Европе, ни в США нас с такими продуктами не ждут.
2. LonWorks для распределенных систем...
3. Устройства делают тысячи фирм, есть и российские и со сбытом у них не очень...
4. Устойчивые продажи и известность - это вряд ли. Рынка в России пока нет... Затраты на маркетинг не забудьте включить в стоимость...
5. Sauter не делает Lon-контроллеров, да и остальные конкурируют не контроллерами, а решениями...

Изучаю мнение!

Нужная ли горячая замена модулей расширения?
В контроллере не отключая питания можно заменить модуль расширения, подключить дополнительные входы/ выходы. Устройства подхватятся на лету и начнут работать. Без горячей замены все изменения в системе надо проделывать с отключенным питанием.

Не нужна, не космос.