подскажите, насколько актуальна проблема медленного опроса для проектов, где надо считывать много параметров modbus (сотни три) и есть 20-30 опрашиваемых входов?
Вид для печати
подскажите, насколько актуальна проблема медленного опроса для проектов, где надо считывать много параметров modbus (сотни три) и есть 20-30 опрашиваемых входов?
давайте определимся с конкретикойЦитата:
сильно тормозить будет?
что такое "тормозить" и в каких единицах это выражено
что такое "не тормозить" и на каком значении для вас критично, а на каком значении параметра некритично
сотни три - с одного слейва, с десяти, с тридцати? надеюсь понимаете, что есть разница?
далее
сотни три - какой формат данных?
далее
какие скорости на шине
какие расстояния и структура сети? а то сейчас что у вас длина трассы два километра или сеть собрана кривее некуда
и что за адская нищета настигла вашего заказчика, что всё это надо запихинуть в один контроллер?
потому как запихнуть-то не такая проблема, а вот потом обработать а потом и выдать оператору - это следующий танец марлезонского балета
поэтому лучше думать как-то в комплексе, где вполне может выясниться, что 300 сигналов это только начало и нужна полноценная скада и разбивать на несколько контроллеров и строить более менее полноценную асу тп
Если первый раз, надо начинать не на объекте, а на столе. Не громоздить сразу большой проект, а добавить 1-2 регистра на вход и выход и добиться мгновенного отклика. Далее добавлять регистры, уже понимая правильность действий. Если хотите конкретной помощи, подробней пишите, что и с чем соединяете, выкладывайте скрины настроек и-или пример проекта.
Могу сказать по себе, если нет уже готового проверенного решения, даже у опытных людей возникают ошибки, и вопрос в том как быстро вы их найдёте и исправите.
рассматривал ОВЕН в качестве "готового решения", руководство настаивало на приобретении варианта "в котором уже все есть" и "не надо ничего программировать", чтоб нам надо было только смонтировать датчики и поставить ПО
в итоге выбрал другое решение (WB + Zabbix), у Овен меня напугали пара моментов
в общем выбрал вариант менее приспособленный для этих дел, но мне более знакомый
и вот в варианте "не Овен" столкнулся с такой-же проблемой - куча датчиков и при механизме опроса каждого с определенным периодом, все жутко тормозит
надо было лезть в питон, использовать библиотеки, а я откровенно не вывожу эту тему, мне бы что-нибудь по проще
в итоге проблема с медленным опросом вдруг изящно решилась с совершенно неожиданной стороны
но сейчас хочу попробовать Овен тоже, и вот увидел тему, что проблема тоже есть, интересно насколько она актуальна и как решается?
shkiper Хм... так вроде причин обычно две:
а) Связанная со способом передачи данных: несколько коротких запросов Modbus нагрузят линию больше, чем один длинный (речь идёт о последовательном чтении регистров, которые стоят друг за другом).
Тут решение и сводится к тому, чтобы при помощи штатных средств (если среда разработки позволяет) или библиотек читать максимум данных одним запросом.
б) Связанная с особенностями реализации опроса в каждом конкретном случае (контроллере): где-то могут быть тормоза ядра, где-то могут быть задержки между запросами на уровне ядра.
А тут решение сводится к тому, чтобы сначала всё изучить, а потом устройство выбирать.
Ну так в итоге оказалось, что человек пытался читать системные регистры скопом ( которые во первых никому не нужны и во вторых, читаться должны по одному, по инструкции), а регистры измерений в итоге отлично прочитались.
И вообще 95% проблем с медленным опросом, в итоге оказывается ошибками в настройках или адресах. Особенно если панель мастер, то дикие тормоза.
Интересно, как решилась у вас проблема изящным способом?