Codesys и вообще контроллеры с главным циклом - как?

[PetrP]

Добрый день!

Уважаемые участники форума. Если можно, объясните, пожалуйста, такую штуку. Общий принцип работы с внешними данными в CDS 3.5, а то у меня какое-то глубинное непонимание. Особенно волнует работа с TCP. Возмем для примера библиотеку NBS. Прежположим, я сделал на ней сервер (или клиент, не важно). Что бы он работал, я, естественно, должен вызывать сервер (FB) в суперцикле. Но, предположим, между вызовами данные по сети поступили дважды - ведь в таком случае в приемном буфере будет только вторая порция данных. По небольшому опыту работы например в Delphi, там как правило использовалась идеология, когда приход данных вызывал событие, и их можно было тут же обработать. А тут нужно что-то делать в основном цикле и еще успевать принимать данные от устройств (устройств может быть штук десять, плюс еще и через последовательные порты). Как избежать потери (не обработки) данных?

Как назло, это проявляется в том, что уже несколько раз не проходили логические единицы от удаленного устройства, т.к. информацию о них, как я подозреваю, "перекрывали" поступающие с минимальным зазором данные об уровне принимаемого сигнала. И тут важный момент - передача данных идет не циклически, а как только один из контроллируемых параметров изменился. Например, тот же уровень сигнала. Не зная точно, в каком состоянии находится удаленный объект, не получается точно на него воздействовать. Т.е. например на приемнике локально аппаратной кнопкой включили Mute, а контроллер это не отловил. Из WEB интерфейса включаем Mute, а по факту он его выключает и приходит логический ноль. Удивляемся, что кнопка Mute не подсветилась... как то так. Согласен конечно, что протокол прибора не удачен.

Про Modbus TCP в качестве транспорта думал кстати, но смущает то, что он судя по отзывам не очень быстр. Люди испытывают (с их слов) проблемы с задержкой даже при подключении по нему обычных выключателей света, если их больше десятка примерно. Мне же нужна масштабируемость для передачи примерно 30 штук аналоговых величин (два байта), состояния до сотни кнопок, и символьных строк до нескольких десятков символов.

Вот все же думаю, а не случалось ли Вам работать или слышать о TCP сервере или клиенте, реализованном в CDS, который бог бы работать, как бы это сказать, сам по себе, без циклического вызова. И "дергать" внешние процедуры при получении данных. Или, возможно, достаточно просто динамического буфера (очереди) для принимаемых данных.

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

[Ryzhij]

Прежположим, я сделал на ней сервер (или клиент, не важно). Что бы он работал, я, естественно, должен вызывать сервер (FB) в суперцикле. Но, предположим, между вызовами данные по сети поступили дважды - ведь в таком случае в приемном буфере будет только вторая порция данных.

Во-первых, данные по сети не могут поступать чаще установленного интервала для данного тега. Чаще всего, нет никакого смысла передавать одно и то же. Соответственно, периоды опроса удалённой периферии должны быть выставленны правильно для медленных и быстрых точек.
Во-вторых, дело не в среде исполнения/программирования CoDeSys или иной какой, а в архитектуре самого контроллера. Есть в нём сопроцессор связи или нет.

[PetrP]

Во-первых, данные по сети не могут поступать чаще установленного интервала для данного тега.

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

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

Отправлено спустя 7 минут 23 секунды:

Во-вторых, дело не в среде исполнения/программирования CoDeSys или иной какой, а в архитектуре самого контроллера. Есть в нём сопроцессор связи или нет.

И здесь в общем согласен. Но скорее, тут еще многое зависи и от программного ядра контроллера. У многих контроллеров CODESYS на TI Sitara аппаратные средства поддержки коммуникаций вроде как есть. Но суперцикл остается со всеми вытекающими проблемами. Есть еще один контроллер, не помню кто делал. Там был процессор Motorola ColdFire 150mhz. И Ethernet, и RS-485. Внутри - NucleOS. Общего цикла не было. Но данные от десятка LAN-клиентов подобного типа никуда не пропадали. Как-то так.
Вот он, кстати, контроллер-то: https://www.crestron.com/Products/Contr ... stems/PRO2

[Михайло]

В системах автоматизации принято делать непрерывный циклический обмен. В умных домах это называется поллингом. Если какое-то значение тега было пропущено, то это не должно ломать систему. Если же это систему ломает, то надо идти на ухищрение: посылать в ответ подтверждение о получении, либо увеличивать длительность сигнала и т.п.
Решать проблему буфером данных - это глупость, ведь реально у вас система может генерировать 100 данных в секунду, а принимающая сторона может физически обрабатывать всего лишь 10 данных в секунду. Иначе, кроме как притормозить "генератор" путей нет. Гигабайтный буфер рано или поздно переполнится.

Делайте на "медленном" ПЛК ответ с подтверждением о получении.

[PetrP]

Делайте на "медленном" ПЛК ответ с подтверждением о получении.

Увы, железка - черный ящик. Как сделана, так и сделана.

[PetrP]

Ради интереса, подскажите - а есть среди промышленных контроллеров такие, в которых главный цикл (суперцикл) отсутствует в явном виде? Слышал, есть Siemens какие-то? Это так? В чем, с вашей точки зрения, достоинства и недостатки подобных контроллеров?

[Михайло]

С каким контроллером вы работаете?

[PetrP]

С каким контроллером вы работаете?

Для себя работаю с CODESYS на Raspberry и с контроллерами Crestron 2-серии (QM-RMC, MPC-M25, они дешевы на Ebay).
Подход Crestron интересен тем, что вот у них как раз нет главного цикла в явном виде.

Пишете например

Change Serial_Input_NNNN
{
//Делать что то, когда пришли данные через последовательный порт или по сети
}

Push Button
{
//Если кнопка или логический сигнал стал "1"
// или Release для перехода в ""0, а Change для любого изменения.
}


Очень удобно, кстати. Вывод данных почти анологично - например, Serial_Outpur_NNNN="dfdgfggfgfdg';

Встроенный язык по типу C, поддержка TCP, UDP, последоваьельных портов, RTC, статическая память от батарейки по типу 2032 (на 10 лет) 256кб и оперативная 32 мб. Вся прошивка вместе с ОС- примерно 1,5 мб. Чудо техники прошлых лет.

[Sokolov_Dmitry]

посмотрите в сторону wirenboard

[PetrP]

посмотрите в сторону wirenboard

Спасибо, правда пока не понял, как у них обстоит дело с визуализацией интерфейсов? В Crestron как-то так, довольно просто делать: https://www.youtube.com/watch?v=e5lOS0mx6iA

[Sokolov_Dmitry]

как у них обстоит дело с визуализацией интерфейсов?

https://wirenboard.com/wiki/SVG-Dashboa ... 0.B8.D0.B5

еще сторонее ПО Zabbix, BARY и т.п..

[PetrP]

еще сторонее ПО Zabbix, BARY и т.п..

Судя по всему, в отличие от меня, с wirenboard Вы знакомы. А если не трудно - для написания логики программы там есть какой-то язык программирования?

[Sokolov_Dmitry]

архитектура по https://wirenboard.com/wiki/Wiren_Board ... iren_Board

[Михайло]

Ради интереса, подскажите - а есть среди промышленных контроллеров такие, в которых главный цикл (суперцикл) отсутствует в явном виде?

Кажется структура всей система задана в стандарте МЭК 61131, поэтому увы. Юзайте железки для умных домов, в них могут наворотить все, что угодно, и честно говоря, там очень много отстоя. А промышленные контроллеры работают. Если железка моргает своим выходом на доли секунды так, что не хватает времени зафиксировать этот сигнал, то ее надо заменить на другую. И все танцы с бубном. В умных домах разработчики могут не понимать этого, вот и живи с этим, как хочешь.

[PetrP]

Если железка моргает своим выходом на доли секунды так, что не хватает времени зафиксировать этот сигнал, то ее надо заменить на другую.

С этим трудно поспорить. Но все же, буфер был бы не таким уж и плохим выходом, пусть и не на каждый день. Более того, в CODESYS (библиотека NBS) есть NBS.TCP_Read, а есть и NBS.TCP_ReadBuffer. Окна-то в сообщениях есть, т.е. было бы время обработать совсем короткое сообщение, которое сейчас пропускается. И бывает это (ттт) очень редко. Но как работать с этим NBS.TCP_ReadBuffer документации вообще нет. У меня вообще есть подозрение, что там не накапливающий буфер имеется ввиду, а просто работа через указатели в явном виде. Дальше пока не разобрался.

Чисто для себя сделал вывод - если надо что-то для дома и есть в наличии дешевые контроллеры Crestron - то он, честно говоря, легко заруливает все остальное. И по удобству программирования, и по стабильности, и по визуализации интерфейсов. При условии, что инфраструктуру, прежде всего разводку, сразу продумывали головой. Если нет Crestron или нужно относительно легко добавить сторонних примочек (MQTT например или беспроводное управление - хотя здесь радио это ересь еще та), то Raspberry + CODESYS.

P.S. Вспомнил, что в CODESYS есть для главной задачи не только Циклическое выполнение, но и по событию. Но, т.к. принимающий данные блок, по крайней мере из библиотеки NBS, работает "не сам по себе", а требует циклического вызова, то это опять ничего не дает. А так, вообще было бы интересно - вызов задачи управлялся бы потоком данных. Почему бы и нет? Тем более, в моем случаее сейчас среднее время цикла 150 мкс, это довольно мало.

[Михайло]

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

[Sergy6661]

Ради интереса, подскажите - а есть среди промышленных контроллеров такие, в которых главный цикл (суперцикл) отсутствует в явном виде? Слышал, есть Siemens какие-то? Это так? В чем, с вашей точки зрения, достоинства и недостатки подобных контроллеров?

Не бывает таких промышленных контроллеров!

, а то у меня какое-то глубинное непонимание. Особенно волнует работа с TCP. Возмем для примера библиотеку NBS.

Что это за библиотека? Для какого CoDeSys! Для каког вендора?
Вообще от подобных вапросов возникает глубинное непонимание....
Where is mie black Gun!..на большом каретном

[vodav]

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

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

[tonyk]

У ТС явное непонимание принципов построения ПЛК и основ обработки информации.

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

Разберитесь с настройками блока Modbus/TCP. Сам протокол TCP в принципе не может работать без буферов, поэтому, если что-то теряется, то это или неправильная настройка обработки информации, или приёмник не успевает её обрабатывать.

[cu6apum]

Я тоже искал промышленный контроллер со свободно программируемым поведением - и не смог найти. На данный момент пользуюсь упомянутым выше wirenboard для некритичных ко времени задач. Неспешно дописываю к нему рантайм для МЭК языков с целью совмещения коня и трепетной лани. В time-critical приложениях - использую спарку из классического ПЛК и ВБ.

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

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

[Sokolov_Dmitry]

использую спарку из классического ПЛК и ВБ

здесь могу посоветовать вместо ВБ использовать коммуникационные контроллеры (шлюзы протоколов, контроллеры ТМ) производства https://yugsys.ru/produktsiya/tmk-kompas-tm-2-0 , они не программируемые, а параметрируемые, с кучей протоколов, подбираются по количеству нужных интерйфейсов, есть автоматичесое управление по логике если нужно.

или использовать OPC UA и ПЛК200/210 от овен с кодесисом (да кодесис, но на сайте много документации и видео)

связка -это правильно, даже у сименса так, например 1200 ПЛК и коммуникационный процесор 1243-1 IEC

[cu6apum]

не программируемые, а параметрируемые

Вот именно. Для телеметрии, может, и подойдут, спасибо за ссылку. Хотя mqtt и opc/ua с первого диагонального взгляда не увидел.
А для сетевого взаимодействия - точно нет. В моих же проектах это необходимая задача.

[Sokolov_Dmitry]

Для телеметрии

совершенное верно, там MQTT не используют, нет меток времени, в телеметрии метки это главное.
Еще есть ТМИУС для ВБ https://www.cea-energo.ru/ru/products/tmius-linux (как и для ПЛК Овен и Reallab)

[cu6apum]

ТМИУС

Интересно. Подергали уже?

[Sokolov_Dmitry]

Подергали уже?

лично тмиус не использовал, только контроллеры с по югсистема