Здравствуйте.
Хотелось бы спросить у вас, кто-нибудь занимался разработкой программного обеспечения для мониторинга различных контроллеров? Напишите пожалуйста мне кто писал программы мониторинга.

Я занимаюсь разработкой ПО для мониторинга дизель-электро установок(ДЭУ), то есть программа ведет опрос контроллеров установленных в ДЭУ через COM-порты.
Хотел поинтересоваться различными идеями, алгоритмами таких или подобных проектов, а так же поделится своими мыслями.
Пишите пожалуйста сюда, буду благодарен за отклик.

Здравствуйте.
Хотелось бы спросить у вас, кто-нибудь занимался разработкой программного обеспечения для мониторинга различных контроллеров? Напишите пожалуйста мне кто писал программы мониторинга.

Я занимаюсь разработкой ПО для мониторинга дизель-электро установок(ДЭУ), то есть программа ведет опрос контроллеров установленных в ДЭУ через COM-порты.
Хотел поинтересоваться различными идеями, алгоритмами таких или подобных проектов, а так же поделится своими мыслями.
Пишите пожалуйста сюда, буду благодарен за отклик.

Приходится заниматься регулярно такой писаниной.
СOM порты худшее, что можно придумать для таких дел.
Во первых из-за низкой скорости, во вторых из-за низкой интеграбельности в стандартные системы сбора данных.
Т.е. конечно на COM порт есть море проприетарных(закрытых) протоколов или примитивных открытых (вроде MODBUS) но они создают сильные трудности когда надо действительно много дивайсов контролировать.

Много - это ближе к тысяче и более. Впрочем это могут быть не дивайсы, а отдельные узлы дивайсов или даже отдельные параметры тогда узлов даже при нескольких дивайсах может стать больше тысячи.
Другая проблема это разделение на потоки по интересам или мультиплексирование потоков данных в разные програмные комплексы для анализа.
Это тоже на рудиментарном уровне при использовании COM интерфейса.

Если ориентироваться на открытые решения, то очень удобно использовать протокол SNMP.
SNMP работает поверх UDP, а тот в свою очередь поверх IP.
Протокол IP можно реализовать как на интерфейсе Ethernet, так и на COM порту но придется еще подставить снизу либо протокол SLIP либо протокол PPP. Вернее Direct connect PPP. Такой PPP не требует вспомогательного движка AT команд и вносит оверхед в считанные байты.
Правда заголовки IP, UDP и SNMP под сотню байт могут нагрузить каждый пакет.
Поэтому COM всетаки будет медленоват.

Но зато протокол SNMP понимают большинство SCADA, открытые системы распределенного управления как OpenNMS, море простых програм для управления по SNMP и наконец есть доступные компоненты работы с SNMP для RAD Studio, Visual Studio и т.д. вплоть до ActiveX для Excel-а

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

Другие интересные варианты предлагают пакеты вроде NI LabVIEW Embedded Module и Matlab.
Они хороши тем, что прямо в них можно делать и анализ и визуализацию данных.
Речи о простой организации связи с тысячами устройств там не идет но с десятком можно связь наладить опять же дешево и сердито.
Особенно интересен NI LabVIEW под ARM где они дают исходники эффективного движка на базе RTOS от Keil. Исходники автоматически компилируются и грузятся в микроконтроллер. А на PC LabVIEW одновременно формирует приложение которое те данные принимает (и по COM, и по Ethernet)и может вывести куда надо: на график, в файл, в блок анализа и фильтрации, в Интенет и т.д.


А вообщем мысль такая, есть куча методов не писать программу мониторинга.
Исключение разве что реалтайм мониторинг через малоисследованные каналы передачи данных, как GPRS или ZigBee

Регулярно приходится с микроконтроллерами через RS порт общатся. Ethernet конечно круче, но не всякий микроконтроллер его тянет.

Хочу заметить что под .NET лучше не использовать готовый компонент, а связываться через вызовы API - OpenFile и т.д.
То что предлагает микрософт для .NET слишком тормознутый, да и глучит.

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

Ясно, что реалтайм парсеры транспортных протоколов на нем писать мягко говоря проблематично.
Но когда поверх .NET ставят движок Microsoft Robotics Studio, то этот сибиоз может стать чемпионом по скорости распределенного управления http://msdn.microsoft.com/ru-ru/robotics/aa731536.aspx

Т.е. .NET в этом случае должен стоять на обоих концах. И на микроконтроллерах и на PC.
С недавних пор Windows CE поддерживает .NET так что вариант с Robotics Studio очень реалистичный даже для очень дешевых микроконтроллеров.

У меня в основном пока для начала задействовано до 8 COM-портов, а далее с числом роста ДЭУ, где установленно до 8 контроллеров соответственно и число портов возростет до N-ного числа, а когда это N-ое число будет выше 255(масимальное число COM в Windows), то возникает проблема.

Сейчас я использую в качестве узла связи между контроллерами ДЭУ и ПК порт сервер (8-ми портовый EDG 4508 фирмы Advantech), он работает с компом через Ethrnet, у него свои программное обеспечение для ПК, для одного такого порт-сервера в Windows можно создать 8 виртуальных COM-портов. А когда порт-серверов будет больше сотни, а Windows не даст создать больше 255, вот тут проблема.

Пока при работе с COM-портами не порблем не было. Во сновном сбои с контроллерами, то захлебывались, то обрудование, которое осуществляет связь порт-сервера с ПК(витая пара, RS 485, оптоволокно) работало с маленькой скоростью, полудуплексом и т.д.

Хотелось бы спросить, а вот если вы давно занимались мониторингом контроллеров, можете посоветовать какую-нибудь литературу (книги, сайты, ссылки и т.д.). И вообще узнать есть ли подобные программки по мониторингу ДЭУ.

Дизель-электро установки это так понимаю элементы системы питания.

Я в частности занимаюсь соединением в сеть тоже элементов питания, а именно инвертеров, UPS-ов, конвертеров и проч.
В этой области SNMP стал стандартом дефакто где системы питания обслуживают крупных операторов связи.
Сам стандарт SNMP читать из RFC бесполезно, там все концентрируется на мониторинге коммуникационных сетей.
Из официального SNMP интересует только способ кодирования ASN и принципы использования MIB файлов
Остальная информация ищется на профильных сайтах производителей продвинутых (многокиловатных) UPS-ов.
В частности надо искать отраслевые спецификации на общепринятый состав MIB-ов.
Кстати разрабатываю контроллеры конвертирующие инфу из COM порта в SNMP потоки.

Я так понимаю ты соединяешь и аппаратную часть и пишешь ПО (т.е. программную часть).
В сеть инвертер, UPS-ы соединяются по интерфейсу Eyhernet, я так понимаю.

У меня же контроллеры ДЭУ соединяются через RS-232и каждый тоже имеет свой собственный протокол (или это можно назвать как команды), поэтому протокола как такового ниту но есть команды.
А вот есть еще такой девайс в разработке на добавление в ПО по мониторингу, который имеет протокол MODBUS, ты можешь помочь с литературой по MODBUS-у, буду благодарен за помощь.
А еще, в какой среде ты пишешь ПО?

Занимался похожей задачей, сейчас подключено 360 устройств через RS-422, платы Adaptech, две четырехпортовые, с целью экономии кабеля в неск. местах поставлены разветвители на трёх max1480. Притокол самопальный.

360 устройств работают по обычному COM-порту или другим способом?

Через 8 портов на 2 платах, со стороны ОС выглядят как COM-порты (COM3 - COM10).
RS-422 позволяет поцепить 32 устройства в одном сегменте, кабель - 2 витые пары, 120 ом, в инете можно найти подробную инфу.
У каждого устройства свой адрес, уникальный в своем сегменте, одно работает, остальные молчат.

А что за девайсы мониторишь? В какой области?

Standalone серверы пишу в RAD STUDIO.
Вот есть сервер на 1000 одновременно подключенных дивайсов.
Тестировался с перегрузкой до 3-х тысяч дивайсов.
У каждого дивайса по нескольку сотен параметров.
http://aly.ogmis.lt/OpenProjects/ARMDominator3/ARMD3.htm

Редкие UPS-ы и инверторы имеют встроенный Ethernet. У большинства есть штатные только COM-ы
Ethernet любят продавать отдельно.
Мои адаптеры конвертируют весь зверинец протоколов в единый стандарт SNMP.
Работал и с MODBUS, с тучей других протоколов начиная с электросчетчиков по IEC62056-21 и кончая промышленными весами.
У многих стиль обмена действительно и протоколом назвать нельзя, просто реакции на команды.
Но часто можно инициировать и непрерывные стримы и асинхронные пересылки по событиям.
Полезность спец адаптеров и SNMP в том числе в том, что можно вставить штамп времени и просеивать поток по времени еще до того как он войдет в ближайший концентратор.


Про принцип работы с MODBUS можете посмотреть вот в этом моем открытом проекте:
http://aly.ogmis.lt/OpenProjects/SimpleRFNet/SimpleRFNet.htm

По работе именно этим и занимаюсь - удаленный мониторинг систем бесперебойного электроснабжения. Это не только УПСы и ДГУ, есть и вспомогательные девайсы COC(common output cabinet), CROSS(быстродействующий АВР) и т.п. Не все к сож. поддерживают SNMP даже в линейках одного производителя. Сделади, пожалуй единственную в своем роде универсальную прогу мониторинга SNMP устройств (не путать с NMS типа OpenView). Дема 15 минутная лежит тут http://www.inelt.ru/ru/attach_file/upslook_install.zip описуха http://www.inelt.ru/ru/attach_file/UPSLook_UM_Rus.pdf. Проблема еще в том что очень немногие производители четко следуют стандартному МИБу RFC1628 , почти каждый старается его расширить. В последнее время обратили внимание на Modbus, и не зря. Во-первых этот протокол поддерживается практически всеми производителями (хочеш чтобы тебя покупали для BMS(buildind management system- будь любезен Modbus), во-вторых лекго расширяется и гибко наращивается ну и удобно формализуется - по аналогии с MIB придумали JIB. Щас сделали мониторинг ДГУ и ИБП, на очереди кондиционеры и прочая хрень. Чистый RS232 вещь неудобная и отживающая.





Тоже интересное решение. Сами о таком думали.
Вопрос сколько примерно стоит у вас создание SNMP агента для известного протокола?

Страная склонность к MODBUS, если конечно его спецификацию не модернизировали сильно за прошедшие несколько лет.
MODBUS был исключительно локальным протоклом полевой шины.
SNMP особенно в 3-й версии расчитан на глобальные сети.

Собственно SNMP агент в нашем исполнении - это один из набора аппаратных универсальных модулей, и они вообщем особенно не изменяются от приложения к приложению.
Протоколы обслуживаемых дивайсов проблему не представляют и расходы на их подключение теряются на фоне других сложностей и обычно даже не включаются в себестоимость.
Реальная сложность в интеграции в систему клиента.
Действительно форматы MIB-ов создают большие проблемы.
Каждый производитель, а часто и потребитель хочет по своему закодировать переменные, свободно интерпретирует правила синтаксиса, в первых версиях SNMP явно мало номеров TRAP-ов и производители любят делать динамическое изменение назначений TRAP-ов.
Но такие фокусы плохо переносят серверы SNMP как HP OpenView и т.д.
А изменения логики формирования TRAP-ов приводят к сильным изменениям в софте агента.
Поэтому как бы к каждому приложению приходится делать предварительный анализ ситуации.

Ничего не могу сказать про то что было, т.к. только начали ею заниматься. Склонность потому, что не все наши и чужие девайсы поддерживают SNMP, в то время как все наши и большинство известных нам чужих имеют Modbus, а с появлением Modbus over IP ваще все гламурно.


Звучит очень оптимистично и обнадеживающе. Пугает только навороченность ваших девайсов. Пределом наших мечтаний является самый простенький ethernet-to-serial сервер, в который зашит кастом SNMP agent cо стандартным RFC1628. Такие делают многие конторы(Moxa, Megatec, etc.) но заморачиваться с самостоятельным написанием ПО под малознакомый процессор реально влом.
Трапы нам ваще по барабану(они по большому счету Айтишникам для OpenView нужны), хватает опроса.
Щас умеем мониторить свой Chloride, MGE, APC, Liebert, GE и все что под 1628. Не умеем свои СОС'и и CROSS'ы. :-( Приходица сухими контактами over IP.
ЗЫ,
по деньгам вопрос не принципиальный на фоне стоимости системы.

Про мониторинг APC -- не коммерческая тайна?
Можете информацией поделиться?

Перебрал все доступные мне APC-шные MIB-ы, но, пока не получилось "достать" объективную информацию о состоянии "климата" одновременно с нескольких APC-шных датчиков.
Естественно, все APC-датчики (температура+влажность) и APC-дивайсы (различные Symmetra + железка для "климат-контроля" от APC) настроены идентично.
Сначала через WEB и потом, в качестве "контрольного выстрела", через telnet/ssh.
"Цифирки" одинаковые везде выставлены (с небольшой поправкой на "расстояние до объекта").
"Дельта прогресса схождения/расхождения во времени" тоже везде одинакова.
Все дивайсы синхронизированы по общему NTP.

Задача, в общем-то, с виду, несложная -- пропищать мне на мобилу за 40-60 минут до "сдутия", что в серверной комнате температура гарантированно ушла за пределы допустимой.

Или, к примеру, "кондёры" неуправляемые (к сожалению, что неуправляемые) сдохли или энергетики напругу снизили надолго до 160 В вместо обещанных 220 В и кондиционеры отключились.
После восстановления эл./питания кондиционеры (Hitachi, Gree) включаются, но гонят почему-то тёплый воздух и влагу вместо холода т.п..
Помогает только "ручное отключение под надзором" минут на 15-20 и повторный запуск.
Запитать кондиционеры через "умный трансформатор" или от UPS-а или от дизель-генератора пока нет возможности.

В общем, одну беду победить не удалось -- множество ложных сообщений и "недостаточность параметром" известных мне МИБов.
Упало напряжение с 220-ти до 160, к примеру.
Батареи UPS-а начали работать "на подъём".
Жду минут 15-ть и посылаю SMS-сообщение о пониженном напряжении "на входе" (ну, и иже с ним о текущих температуре и влажности).
Не верю. Жду.
Когда заряда батарей хватает минут на 40 (чтобы успеть добраться до места и вручную "опустить" несколько специфичных серверов), отсылаю ещё одну SMS-ку.
Приходится ехать.
Приезжаю (или ещё в дороге) --> входящее напряжение в норме.
"Чтоб они так жили!" (ЦЕ)
Но, раз уж выехал --> приходится доехать и посмотреть что там и как.

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

APC-шными envinroment девайсами не заморачивались, не было необходимости. Когда надо мониторить темп. и влажность, а также для сухих контактов, берем Netprobe Lite от megatec http://megatec.com.tw/. Это единственное полезное их изделие. Для контактов допаиваю подтягивающие резисторы на входы АЦП - итого 8 контролируемых с.к. В остальном с МИБами от АРС никаких проблем не было. Я давал ссылку на нашу прогу выше, можете потестить. Дема работает 15 мин.

Почем покупаете дивайсы у megatec не скажете ?

Собираемся тоже самое почти делать по размерам

Точно только после праздников, надо у манагера спросить. Типа 200$. Заодно предостерегу от Net101 - отстойнейшая не вещь.
И кстати что вы думаете о NetAgent II? Они его типа позиционируют как открытую платформу для мониторного софта, но ничего более подробного я не нашел.
Вообще довльно халтурная контора. Несколько раз обащался к ним за хелпом (сбросить пароль на Нетпробе, оживить его просле апгрейда фирмы) - ноль реакции. И это при том что мы их дистрибуторы.
Валяется у меня один труп Нетпроба могу подарить для анализа.
И еще (чета меня понесло), мне очень нравится атмеловский девайс DB101 http://www.atmel.com/dyn/Products/tools_ca...sp?tool_id=4221
даже купил на свои. К нему Лантрониксовкий Xport и готовое сетевое устройство. На худой конец AVR Butterfly, у меня уже собран такой девайс, тока прогу некому написать.

Платформы типа NetAgent могут быть открыты только в плане железа.
Т.е. могут дать схему.
В лучшем случае некий примитивный разрозненный набор исходников как-то работающий на заданной платформе, как в случае с DB101.
Исходники вроде и есть, но заставить их работать все одновременно и чтоб еще приложение легко модифицировалось от задачи к задаче трудновато, я бы сказал слишком трудно.
Довольно странная идея эмуляции VT100 на экранчике маленького дисплея DB101.

Склейкой тех либ и драйверов которые дает Atmel должна являться операционная система реального времени (RTOS). Также должно быть и в NetAgent-е.
Иначе не получится действительно мощного и универсального фреймворка который позволит подключаться к любым датчикам, UPS-ам и другому оборудованию и иметь при этом гибкий HMI, диагностику и апгрейд.
Но такие фреймворки либо монструозны поскольку спускаются с линукса и их не тянет ни одна бюджетная платформа, либо они хорошо упакованы и их уже производителям отдавать жалко.
Начинается тогда возня с либами, какими-то кастрированными API и проч. прослойками призванными изолировать юзера от исходников системы.
Характерный пример Lantronix. Я вообще не понял туда прогу свою залить можно? Или все делается через какие-то настройки?
NetAgent думаю будет снабжен той-же левизной, либо будут предлагать услуги по кастомизации своего софта без привлечения программистов заказчика.

В общем случае дополнения в софте SNMP агента для отражения специальных MIB-ов юзера требуют серьезной интеграции в основной софт операционной системы и статической линковки.
Также спецальной структуры callback процедур и статической линковки потребует отражение новых переменных пользователя в HTML страницах встроенного WEB сервера.
Производитель для предоставления таких возможностей должен сделать практически целую интегрированную среду разработки, написать тонны доки. Цена дивайсов вырастет неимоверно.
Похожую стратегию развивает Wavecom в своих модемах.
Все встречавшиеся мне случаи использования технологий с таким подходом кончались неудачно.
В конце концов все упиралось в недостаточную гибкость.

Как-то уж очень в общем у вас сформулирована тема
Мониторинг-мониторингу рознь - одно дело графики выходных данных строить с высокой частотой, другое - опрашивать чего-нить раз в полчаса.
Так что напишите, что у вас в принципе за задача.

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

Сумбурное вы чета написали.
Какой-то поток рассылал по очередям и тут же другой поток собирал из этих очередей
И почему поток собирающий из очередей работал по таймеру, а не сразу по событию из очереди?

У мониторингов всегда интересна масштабируемость.
С этой точки зрения их реализации должны преследовать одну из важных целей - их нагрузочная способность должна определяться пропускной способностью физического канала и процессора, а не какого-то таймера например.

На счет СНМП - каждый стандарт лучше чем отсутствие стандарта. ИМХО сдесь пропблема лежит в следующем. Температура, влажность даже напряжения на акумуляторах УПС изменаються очень медлено. И тут можно производить опрос СНМП агента (делать поолинг). А если система основана на событиях или быстродействующих сигналах то появлеться проблема синхронизации актуалного состояния на верхнем уровне. В принципе как я заметил нет более мение хорошего стандарта на котором основаны системы мониторинга. И каждый делает как угодно. А все фирмы "телекомы" требуют чтобы был реализован СНМП хотя его не используют.

Проблемой синхронизации состояний, анализа корреляций, выявления первоисточников событий и причинно следственных связей в цепочке событий занимаются специальные пакеты вроде HP OpenView, стандарты протоколов за это не отвечают.
Другое дело, что персонал на этих пакетах редко может вообще сообразить как это можно сделать.
Полинг применим в интранетах с хорошими каналами и на неответственном оборудовании.
А когда агенты стоят чтобы сообщить, что разорван магистральный канал?
Или им надо сообщить о выходе оборудования из строя или о саботаже?
Это кстати и есть у нас самые характерные сценарии.
Наши операторы электросетей вообще полингом UPS-ов и других резервных источников не занимаются.
Им подавай только трапы и только высокоприоритетные.
А полинг требует серьезного напряга от персонала на свою организацию и знание особенностей обрудования.
При наличи многих десятков типов оборудования и его постоянным апгрейдом полингом врядли кто серьезно заморачивается в больших сетях.

Пост был немного сумбурен, потому что хотел написать в двух словах
Масштабируемость - свойство интересное не всегда. Она влечет за собой обычно усложнение архитектуры, что может быть неоправдано.
Поэтому я и написал - вопрос в том, какие цели у мониторинга - одно дело промышленный терминал для мониторинга какой-то установки - тогда действительно желательно иметь мощное ПО с развитыми функциями.
Другое дело - мониторинг небольшой системы с выводом например графиков пары переменных состояния. Тут не нужна никакая масштабируемость - главное быстро и удобно под конкретную задачу.

P.S. Про таймер - чисто технической средство для регулярной отрисовки

Хе, к CAN-у я мониторинг тож писал.
Тож графики, управление в realtime и все такое.
http://aly.ogmis.lt/products/closed_polygon/Polygon.htm

Но задач или потоков не использовал, делал проще - все сидело на обработчиках ивентов.
Фишка в том, что многие компоненты Delphi и так используют потоки и нет необходимости еще вводить свои.
Плюс компоненты из палитры в подавляющем числе RAD тулсов под винду не поддерживают многопоточность, и во избежание гемора стараюсь избегать в GUI приложениях интенсивного использования потоков.
Но есть оборотная сторона.
Она в том, что надежность таких приложений собранных из кучи сторонних компонентов и компонентов из палитры с разрастанием функций стремится к нулю.
Поэтому выбор технологии на мой взгляд определяется не "простотой" реализации, а чисто наличием специфических потребностей заказчика, как типа финансовые возможности, имеющаяся IT структура и т.д, потому что простота убивается потом трудной поддержкой.

VCL Delphi - это вопрос отдельный, прямо целая тема для холивара
1) Потоки GUI не мешают - достаточно из них к нему не лезть.
2) Вот именно по приведенным вами соображениям надежности и не использую кучу сторонних компонентов и либ, а обхожусь более менее стандартными API на Win32 или типовые либы на .NET.
3) Под "простотой" понимается отсутствие лишних уровней абстракции и дополнительной функциональности, которые необходимы для обеспечения масштабируемости и универсальности, которые часто нафиг не нужны.
4) Легкость поддержки в первую очередь зависит от качества кода и того, насколько эволюционируют требования к приложению. Чем архитектура проще, тем в общем случае лучше, если только требования в будущем не превысят ее возможностей.

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

А пока вот свежак пришел по новостям:

http://www.zenoss.com/product/what-we-monitor

Это открытая система работающая на базе WEB броузеров может мониторить туже температуру и UPS-ы
по SNMP.

Здравствуйте, Всех с прошедшем Новым Годом!!!

А конкретно по мониторингу ДГУ у вас есть какие-нибудь проекты, информация, описание программ или алгоритмы работы программ.
Мне надо просто в дипломе написать сравнительный анализ моей программе с другими программами мониторинга ДЭУ.
Просто у меня препод пративный, я ему когда проект показывал (темудипломного проекта защищал), он мне сказал что таких еменно программ как моя уже навалом. Вот мне и надо на комиссии расказать что это за программы и как они работают.

ДГУ конечно интересуют, но меньше
А препод пральна сказал. Нефиг плодить неюзабельные программы.
Берите LabView и конфигурируйте как все нормальные студенты делают.

Эта программа разрабатывается не ради диплома (ну и для некого тоже), а ради внедрения в большие сети ДЭУ по всей Сибири, ну канечно же в других регионах.
Просто наша компания в этом году летом была на выставке в Москве, и там мониторингом ДЭУ заинтересовались многие фирмы и они заложили у себя в поректах эту программу.

А мне надо просто посмотреть какое ПО в настоящее время используется в России, так для диплома.

Очень мб. Я им после Net101 вообще мало доверяю.



А при чем тут VT101? Я имел ввиду минималную инфу типа как на NetProbe: IP, Mask, Gateway, Температура, Влажность ну еще чего по мелочи.



ИМХО от монструозности одни гиморы. Нужная универсальность достигается просто набором прошивок.

ЗЫ. Цены на Нетпроб у Мегатека: <20 шт. $180, >20 $130-$150. Если у нас покупать - в два раза дороже.



А вот скриншоты наших мониторных прог. Слева-направо: UPSLook - SNMP, JSLook - Modbus, GSLook - Modbus, Disbatt - мониторинг батарей.

Просто хотел сказать что решения делать на DB101 не эффективно, и при этом себестоимость выше средней при сравнимом количестве фичей.

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

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

Вот скриншот моей мониторинговой программы для PC :



Такая программа пишется в Delphi за пару недель при соответствующей библиотеке компонентов.

С одной стороны не писать програм типа LabView с другой стороны скриншеты почти програм типа LabView (есть параметры, состояния текущие и события нехватает визуализации). И такой вопрос, а эта монотиринговя програмка соберает даные по SNMP или реализован свой протокол с устройством балансировки заряда стрингов батарей?

Такой вопрос а с LabWindows/CVI кто-нибудь имел дело?

Таки да.

не знаешь в LabWindows\CVI имеется библиотека Modbus?

По ссылке http://sine.ni.com/nips/cds/view/p/lang/en/nid/201711 лежит библиотечка для modbus, правда, для Лабвью.
Хотя написано что для версии 8.2, вполне успешно работает на версии 8.6, актуальной в настоящее время.
Опробовал эту библиотечку на практике в небольшом проекте - впечатления самые положительные.
Посмотрите, может поможет, если я правильно понимаю, LabWindows\CVI и Labview отличаются только формой записи исходного текста программы.
У первого - текстовый, у второй - графический.
После установки библиотечки появляется новая вкладка с компонентами, в том числе есть примеры. Все исходные тексты открыты, их можно просмотреть.
Там два варианта - с применением последовательного порта и TCP IP.
Я пробовал вариант с последовательным портом.

Нет не получается это библиотека для LabView. Хотелось бы для LabWindows билиотечку ну или файл (*.fp) с расшитением .fp

Ай блин. Я тоже ищу. Штатно нет
Наверное придется самому писать.