Просмотр полной версии : Логика: Распознать отдельно короткое и отдельно длинное нажатия (CodeSys v3)
Камрады, мне требуется помощь и пинок в нужном направлении в плане логики.
Я на CodeSys v3 изобретаю диммер под один из своих щитов. И я запутался в логике алгортимов! Но не диммера (эта часть работает у меня нормально), а отслеживания нажатий на аппаратную кнопку.
Даю вводные:
а) Кнопка - это вход модуля IO. Модуль опрашивается по Modbus RTU, задержка опроса около 100 мсек.
б) Логика диммера у меня написана на уровне "If bSinglePress Then..." и "ElsIf bLongPress Then" - тут вопросов нет, и тут всё работает.
в) До этого у меня были наработки FBшки, которая умела отличать одинарное, двойное и длинные нажатия на кнопку, но делала это на все нажатия подряд, без взаимоисключения: одинарное нажатие всегда выдавалось при нажатии на кнопку.
Эта логика работала через:
* Краткие нажатия - через изменение счётчика импульсов модуля. Я сранивал предыдущее считанное значение счётчика импульсов и текущее и решал, сколько нажатий было.
* Длинное - тупо по TON с заданной выдержкой.
Ща мне нужна другая логика: чтобы FB умел отличать отдельно короткое нажатие и отдельно длинное.
Я пошёл по тупому пути:
а) по TRUE на входе кнопки запускаю TP (интервал времени - на 100 мсек больше, чем у TON из пункта ниже) и в конце интервала TP смотрю на то, нажата ли кнопка. Если всё её нажата - то блокирую короткое нажатие, считая что идёт длинное.
б) Длинное отслеживаю так же, как и делал - по TON.
Всё это то работает нормально, а то косячит - иногда после длинного нажатия ловится короткое, а иногда после короткого ситема решает что у неё ещё и длинное пошло.
Скорее всего путь этот неверный, но я ща оказался пленником этой идеи и мозг не видит альтернатив.
Короче, как в "истории одного байта" - уже третий день хожу из комнаты в комнату (или даже когда в магазин за едой) и бормочу что-то себе под нос и туплю.
Может ли кто мне посоветовать другой алгоритм? Я наплодил всяких F_TRIG/R_TRIG, и ещё больше запутался нахрен.
Может какие-то другие таймеры попробовать?
Отслеживайте по заднему фронту, если нажатие длиннее, блокируйте действие короткого нажатия.
Вообще, вешать такие вещи на модули тот еще изврат, но вы сами это выбрали.
capzap У меня есть OSCAT для CodeSys v2. Там в коде такой адский шлак (переменные нормально не названы, комментариев нет), что я его посмотрел и давно закрыл. Стоит ли для CodeSys v3 смотреть?
melky А в чём изврат? Была бы кнопка на экране - так такой же функционал надо было бы сделать. Один фиг же откуда сигнал идёт: с аппаратного IO или нет.
А вот туплю я. Ща попробую пересказать. Значит мне нужны:
а) F_TRIG для заднего фронта.
б) TON для длинного нажатия.
По F_TRIG я должен смотреть, работает ли TON, так? Если TON работает - то значит я ещё в длинном нажатии, и на F_TRIG наплевать?
Ох, туплю. А что тогда будет после длинного нажатия? Вот покрутил я длинным нажатием яркость... отпустил кнопку - и у меня опять получилось по F_TRIG короткое нажатие, которое мне не нужно...
НЕ ожидал от вас .На FDB это делается минуту.
rovki и работать не будет
rovki и работать не будет
Теперь будет! С 3х утра на ногах...:p Спатьспать,спать...Время можно и 1сек поставить
:) только поправочка, все, что длиннее короткого нажатия, должно быть длинным нажатием.
и тут стоит задуматься, что есть короткое нажатие ? я должен стоять и держать выключатель строго дольше 100 мс? да фиг вы угадали, человек клацая выключателем не ждет столько и будет дальше так - я сделал короткое нажатие или не сделал ? почему свет не включился ?
НЕ ожидал от вас .На FDB это делается минуту.
Ну я же и признался, что запутался, мозг замылился, и я накрутил фиг чего.
*разводит руками* Вон вчера всё IO перетащил на OCL, накрутил там удобный массив структур IO и кучу всего с указателями, а тут вот запутался, и хоть тресни.
Ща сделаю прям сначала отдельный FB на CFC, и испытаю и отпишусь!
melky Вот как раз как поймать короткое нажатие в стиле "пришёл злой и тыркнул кнопку" - это я научился делать по счётчику импульсов.
Задача может крутиться с любой скоростью и IO может хоть на 500 мсек тормозить - я там просто смотрю дельту импульсов с модуля IO, и решаю, сколько нажатий было - одинарное, двойное или (если надо) больше.
Но тут этот алгоритм не катит (вроде бы...).
Я забуксовал на взаимной блокировке нажатий пока что. Даже пусть сейчас на 100 мсек придётся кнопку давить для одинарного нажатия - пофиг пока что.
Ну я же и признался, что запутался, мозг замылился, и я накрутил фиг чего.
*разводит руками* Вон вчера всё IO перетащил на OCL, накрутил там удобный массив структур IO и кучу всего с указателями, а тут вот запутался, и хоть тресни.
Ща сделаю прям сначала отдельный FB на CFC, и испытаю и отпишусь!
Главное не забудьте про пунктирную связь -задержка на такт!!!!! Время можно и 1сек поставить , все что короче -короткое нажатие , больше -длинное
тогда так и делайте, считайте импульсы (так понимаю счетчик вычитываете ?). Если через определенное время вы видите лог 1, значит кнопку держите и тут считайте время.
тогда так и делайте, считайте импульсы (так понимаю счетчик вычитываете ?). Если через определенное время вы видите лог 1, значит кнопку держите и тут считайте время.
Зачем огород с счетчиком городить , когда таймер все это делает один
Так... а как в третьем CodeSys задержку на такт сделать? У меня ж не OWL сейчас.
F_TRIG, что ли, применить?
UPD: Не, не заработало.
melky Ага, счётчик. И тоже дико туплю: так я ж по нему могу короткие нажатия поймать... а длинные ловлю по TON.
Но они всё равно между собой дерутся и не блокируют друг друга.
UPD: А, не! Не время счётчиком, а из модуля IO (Mx110) беру счётчик срабатываний входа и по нему смотрю, было ли одинарное нажатие или нет, вот так:
//Считаем разницу показаний счётчика импульсов на входе модуля IO. Она всегда считается
iPulseDiff := ABS(InPulses - iPrevPulses); //Считаем по модулю, так как счётчик может переполниться
//Смотрим, что нам дали по разнице показаний и решаем, какие нажатия надо выдавать на выход
//Последовательность проверки очень важна для того, чтобы не путать двойные и одинарные нажатия
IF (iPulseDiff > 1) THEN //Больше одного - значит два нажатия было
bSingle := FALSE;
bDouble := TRUE;
ELSIF (iPulseDiff = 1) AND (NOT tmDoubleDetect.Q) THEN //Ровно одно нажатие
bSingle := TRUE;
bDouble := FALSE;
ELSE //Не было нажатий
bSingle := FALSE;
bDouble := FALSE;
END_IF
//Если мы нашли одинарный щелчок, то стартуем таймер задержки, чтобы поймать двойной
//Ловля двойного щелчка означает то, что на некоторое время (пока работает таймер) мы перестаём
//обновлять дельту числа нажатий, давая возможность блоку подсчитать другие нажатия
tmDoubleDetect(IN:= bSingle, PT:= VarsRetain.Sys_BtnDBClickDly);
Это я просто ловлю щелчки с модуля IO. Ща с этим вопросов нет - у меня затуп в том, как их взаимоисключить.
Я ещё раз прошу не смеяться: у меня за три дня поиска решения мозг замылился, и я в полном ступоре даже от очевидных вещей.
krollcbas Ах ты ж чёрт!! Конечный автомат с состояниями!
Вот про это я и не думал! Ловил всё на задержках и IFах, пытаясь ими состояния заблочить!
Ща попробую этот код!
krollcbas Выражаю огромную благодарность за идею и код!!
Оно заработало!! И принцип конечного автомата мне ясен! Большое тебе спасибо! Я возьму этот код за основу, за завтра попробую наваять свой код так, чтобы он одинарные ловил и по изменению числа счётчика импульсов модуля IO, и твоим способом. И попробую это закрутить в конечный автомат.
Если всё заведётся - то выложу сюда код!
Cs-Cs так как модуль у вас удаленный (период опроса и время опроса влияет), то определение по счетчику коротких, а лог 1 с канала для проверки удержания.
Но все равно это все не гуд, как реагировать на то, что был импульс на счетчике и вы опять выжидаете время для проверки держится кнопка или нет ?
лично мне это время всегда было критично. я нажал клавишу и пошел, свет должен включиться СРАЗУ, а тут ПЛК из-за периодов опроса в 100мс проверяет еще, а не держу ли я кнопку дальше? Вот я о чем говорю и не важно как вы это реализуете в коде.
Но это мой бзик. Вот krollcbas-а и его клиентов не бесит, что свет от HMI или кнопки включается через 200-300 мс, а меня лично такое поведение бесит :)
был опыт с Carel pcO3 у которого фильтрация по входам 320 мс 320 Карл! и не отключаемые и нажатие на кнопку щита как мы привыкли не приводило ровным счетом ни к чему :)
melky Можно (нужно) на "ты": это ж интернет всё-таки.
Ты прав во всём. И я так же злюсь на тормоза всего и вся. И если просто обсуждать кнопки, то у себя на блоге я даже комментаторов банил и посылал жёстко, когда они говорили что хотят делать реакцию на кнопку по её отпусканию, а не по нажатию.
Модуль не удалённый, а в щите стоит (или я не про то?). Просто CodeSys v3 сама по себе тормознее, чем CodeSys v2. У меня есть большой и дальний проект - потыкать логическим анализатором в них и посмотреть разницу. Вот штатный планировщик CodeSys v3 тупенький, и очень мутный. OCL даёт чуть более быструю и стабильную работу.
СПКшки я выбрал из-за того, что там единая среда разработки и единый файл проекта. Один, чёрт побери, файл. И даже архив проекта можно создавать со всеми либами. И отладка удобная, и разные языки программирования, и визуализации удобно делать (не надо для Web где-то отдельно ковырять другую программу, не надо для панели оператора делать отдельный проект). Вот из-за этих удобств я за него держусь и выжимаю оттуда максимум.
Про кнопки. У меня есть написанный блок, который определяет короткие нажатия кнопок по дельте счётчиков импульсов модуля IO. Вот с ним проблем нет. Я ж барабанщик ещё, руки у меня быстрые. Вот этот блок ловит очень быстрое нажатие на кнопку. Быстрота реакции блока зависит только от времени опроса IO и задачи, в которой он крутится.
Про диммер. В диммере частный случай (с которым я и затупил): он МОЖЕТ и даже ДОЛЖЕН быть тормозной, потому что я не представляю как по другому понять, что от нас хочет человек, жмущий на кнопку: то ли яркость подрегулировать, то ли включить-выключить. Тут пусть будут задержки - плевать на них.
У меня с 2010 года стоит диммер от Шнайдер Unica, обычный, в подрозетник. Там тоже есть задержка его работы по быстрому нажатию. Видать, алгоритмы похожие.
Так как у krollcbas я увидел то, что все вовсю юзают конечный автомат (я на микроконтроллерах его юзал, а в ПЛК не догадался), то я попробую закрутить на конечном автомате отлов быстрого нажатия кнопки по счётчику импульсов модуля IO, а длинное - способом krollcbas или по TON, и посмотрю что получится.
Если удастся сделать отлов быстрого нажатия на включение-включение диммера - то будет круто. А подержать кнопку 500 мсек, чтобы диммер начал крутить яркость - это пусть будет нормальным. Тем более что все эти задержки я выношу в проекте в константы, и их можно подстроить. Можно даже на экране в настройки вытащить.
В общем, в моей практике диммер - это частный случай.
Вот что лично меня бесит - так это выдача наружу мигалок! У меня во всех проектах вовсю используется мигание подсветками кнопок, чтобы показать специальные режимы работы вентиляторов, мастер-кнопок, кнопок управления тёплыми полами. Подсветка от такой кнопки выводится на отдельный выход, и ПЛК ею рулит по нужной логике.
Например, я под один проект нафигачил классное управление тёплыми полами (электрическими). На стене ставится только кнопка с подсветкой. Температура пола настраивается через UI на СПК (по опыту на своих домашних полах я её редко меняю). На кнопку навешано пока так:
* Одинарное нажатие включает или выключает пол
* Подсветка не горит, если пол выключен и горит, если пол включен
* Подсветка мигает, если пол включен и включен его нагреватель
Это офигенски прям классная обратная связзь.
Так вот из-за опроса модулей IO обычные BLINK ведут себя хрен как! И подсветка может мигать не меандром, а быстро мигать - это вообще ужасно.
Я всё хочу попробовать побаловаться штатным ШИМом на модулях IO, но меня останавливает то, что на некоторые кнопки мне надо менять скорость миганий, а у модулей вроде как постоянно записывать период ШИМ в них плохо. Правда там есть защита памяти от записи и, если это означает то, что в модуль можно писать что попало, но он не будет это сохранять - то в каком-то из проектов я потом это попробую. Пусть модуль аппаратно мигает сам.
==========
Всё! Сегодня под ночь буду кодить и смотреть, что получается.
[QUOTE=Cs-Cs;345164]Так... а как в третьем CodeSys задержку на такт сделать? У меня ж не OWL сейчас.
F_TRIG, что ли, применить?
UPD: Не, не заработало.
[/CODE]
Элементарно -
rovki Нет, это уже как раз сложно и зависимо от времени, а не от цикла задачи.
А речь же шла в задержке на один цикл именно задачи. То есть я к тому, что задача в ПЛК может протупить так, что 0,011 секунды уже пройдёт. И чего тогда будет?
Я попробую докодить тот конечный автомат. Мне на конечном автомате даже больше нравится - это вообще в принципе исключит все глюки.
rovki Нет, это уже как раз сложно и зависимо от времени, а не от цикла задачи.
А речь же шла в задержке на один цикл именно задачи. То есть я к тому, что задача в ПЛК может протупить так, что 0,011 секунды уже пройдёт. И чего тогда будет?
Я попробую докодить тот конечный автомат. Мне на конечном автомате даже больше нравится - это вообще в принципе исключит все глюки.
Да там TOF заменяет задержку на один цикл , время ставьте хоть 0,1 сек . Это просто блокировка ...Работает 150% , не зависит не от чего ..Не важна задержка - хоть в одном цикле ,хоть в нескольких .Главное что бы блокировка ушла позже чем сигнал с F- триггера .Ни какого шаманства ,чистая электроника .
krollcbas
13.12.2020, 16:41
Валенок, не работает такой код. Проверил.
При подаче короткого импульса на IN, выход OUT_SHORT зажегся и больше не гас.
krollcbas цикл в 10-20 мс не заметен. А вот когда он растягивается на 100 и более становится заметным.
Коротко это как мы привыкли нажимать выключатель, длинно - регулируемая величина.
Cs-Cs по этому я пришел к выводу, что кнопки управления светом должны обрабатываться локально при помощи контроллеров в этажном щите, если это частный дом например. Для этих целей хорошо подходят ПР от Овен. А надо их в глобальную систему вводить, то через основной мозг, который занимается управлением на верхнем уровне - HMI, управление через интернет и так далее.
Ха. Два действия кнопки можно сделать ТОЛЬКО по отпусканию чтобы сохранить адекватную реакцию в скорости. Другого к сожалению не дано.
алгоритм просто "нажали - отпустили = реакция" или "нажали и держим (блок первого действия) = реакция"
Все остальное МЕДЛЕННО :)
Сильно не пинайте, делалось много лет назад, когда были только ПР110 и ПР114
У всех кнопок однократное действие (то есть только включение и выключение света по короткому нажатию), начиная с входа I6 два действия или три, в зависимости от включен свет или выключен. Может идея сама поможет. Как раз для регулировки яркости можно делать, так как свет включен и пауза выдержана, короткое действие заблокировано - регулируем.
Sergey666
14.12.2020, 10:49
Офигеть на 3 страницы .
Если каждую фигню, типа диммера-выключателя делать на командоаппарате, то самая простая программа превратится в собрание сочинений В.И Ленина.
Во вложении проект КДС2 (ПЛК110-30[M02]), принципиальной разницы с КДС3 нет, есть визуализация.
Sergey666 А точно ли нет принципальной разницы с CDS3? Я-то знаю, что она есть. Потому что CDS3 АДСКИ медленный по сравнению с CDS2 по опросу модулей IO.
И там от реального нажатия кнопки до того, как её увидит ПЛК, может пройти около 100-200 мсек.
И поэтому все алгоритмы, которые основаны на потенциалах (смене TRUE/FALSE) на CDS3 косячат. Например, может быть такой случай, время условное:
0 мсек => Опрашиваем модуль IO, значение FALSE
20 мсек => Человек нажал кнопку
100 мсек => Опрашиваем модуль IO, значение TRUE
130 мсек => Человек отпустил кнопку
195 мсек => Человек нажал кнопку второй раз
200 мсек => Опрашиваем модуль IO, значение TRUE
280 мсек => Человек отпустил кнопку второй раз
300 мсек => Опрашиваем модуль IO, значение FALSE
И получается что человек сделал двойное нажатие, а ПЛК увидел одинарное. Или вообще длинное. Так что нетушки. В третьем CDS нужны дикие извраты, например (в будущем я когда-нибудь напишу пост с названием типа "Ускоряем CodeSys v3"):
а) Опросы модулей IO внутри щита (критичных) не через штатный кофигурал, а через OCL. Это снижает число ошибок из-за тормозов планировщика, и увеличивает скорость опроса в 1,5 раза;
б) Длинные нажатия можно сделать по классике через TON, так как плавающее время +/-100..150 мсек - пофиг
в) А вот короткие нажатия в третьем CodeSys правильно ловить только через изменение встроенного счётчика импульсов модуля IO. Там и нажатия бешеного барабанщика прокатывают (пример бешенства можно глянуть тут, пока не удалил (https://cs-cs.net/ExxChange/DT-InThePrPt1-Demo.avi), это я тренируюсь, сбиваюсь и поэтому это в ЮТуб не пошло).
melky Ой! Пропустил я твой ответ! Отвечу по частям тебе:
а) От этажных щитов я ушёл сразу же, как только внедрил IPM™ в своих щитах (переключение на сеть, генератор и инвертор, читать тута (https://cs-cs.net/ipm-power-management-emulator)). А то в этажные щиты надо по 3-6 кабелей питания от основного тянуть. При этом селективность никакая. Про это я писал ещё и тут (https://cs-cs.net/etajniye-shhity-dlya-kottedja-ekonomiya).
Ссылки привёл как свои аргументы про "нафиг этажные щиты".
Но никто не мешает разместить ПРки в основном щите. Как-нибудь попробую такое замутить, чтобы на СПК инфа шла только в визуализацию. Хотя пока я хочу из СПК выжать максимум!
б) Ага, мы мыслим в одном ключе, ура! Я тоже всегда за быструю реакцию в нажатиях кнопок. Есть два подпункта:
* Я выжимаю из СПК всё-всё, потому что мне нравится то, что всё делается в одной среде - HMI, код и само проганье.
* Некоторые современные светильники (от Arlight/Centrsvet например) имеют такие хитрые драйвера от Mean Well, которые сами по себе включаются с задержкой аж в секунду. И это западло может свести на нет все фишки "убыстрим кнопки на ПРке".
в) Ага, вот как раз по нажатию у меня есть FB, который ловит одинарное и двойное по счётчику импульсов модуля IO. Только они там не разделяются. А с разделением я знал что надо по отпусканию, но сел в лужу в логике.
Всем. УРА! Вроде бы я скрестил код от krollcbas со своей обработкой одинарных нажатий по счётчику импульсов. Кажись работает!
Сейчас вот думаю над тем, выкинуть ли из него обработку одинарного нажатия по числу тиков или оставить. Склоняюсь к тому, чтобы выкинуть, и оставить счёт тиков только для длинного.
Пока выкладываю то, что получилось. Я код снабдил комментариями, потому что тупил и разбирался. Ну и другие дела ещё на неделе делал.
krollcbas
19.12.2020, 02:39
Cs-Cs, сейчас поднимаю похожее решение на ПЛК210 и тоже надо делить импульсы длинных и коротких, но там у меня есть еще сетка кнопок с KNX и UMC шлюз, который нужно очень быстро опрашивать.
В умном доме реакция света на кнопку - штука принципиально важная. Пока рано мне рассуждать про задержки CDS3, они же там в аппаратной части. Постараюсь все замерить и доложусь по итогу.
krollcbas А вот я на CFC во вложении видел уже.
Скажи, а ты по KNX кнопки в ПЛК затащил? Мне пара заказчиков хотела подкинуть эту идею, но мне казалось что они будут долго опрашиваться.
Отпишись пожалуйста потом, что с задержками было. У меня всё IO - на дискретных модулях Мх110. И основная задержка там тупо в Modbus RTU, потому что он в CodeSys v3 реализован совсем не так, как в CodeSys v2.
krollcbas
19.12.2020, 03:34
Ну, мне так видится что делать освещение используя ввод/вывод на Modbus RTU не самая хорошая идея вообще (извини за критику). Ведь рассуди сам как сигнал идет: Модуль, принял, записал в таблицу(задержка), далее ждет запроса от мастера, далее мастер принял/обработал/передал в алгоритм, алгоритм ну обязан взять время на реализацию, далее запись в регистр, далее посылка телеграммы в другой модуль, далее его задержка, далее задержка самого реле, далее свет горит.
Ну встречал такие системы от известной компании. Владельцы квартиры не в восторге, если говорить мягко. Причем ладно задержка, она плавает!!! то есть не всегда одинаковая.
В моем случае KNX этот протокол он событийный скорость до шлюза быстрая. Шлюз от Iridium Mobile уже опрашивал с циклом 10мс, пока полет нормальный, но жизнь конечно скорее всего меня развернет. В моем случае везде эзернет
Cs-Cs ну, вы меня немного не поняли. Делайте на СПК и т.д. на чем нравится в разных щитах или одном тоже не важно. Просто для таких вещей как кнопки вместо модуля IO примените ПР (например, тут как бы цена играет роль, ну не ПЛК же брать).
То есть ловля нажатий выполняется САМИМ ПР, включение, регулирование димером (есть же у ПР и аналоговые выходы) от кнопок выполняет он, а из сети - HMI визуализация, через Internet ПР просто выступает как модуль IO.
То есть логически ПР-ка является тем же самым модулем ввода=вывода для основного мозга, но кнопки берет на себя.
Тогда вопросов об извращенных победах не стоял бы :)
Ну и чистое имхо, применяйте ПЛК, где модули на внутренней шине, может увидите разницу в скорости :)
В общем немного не для тех задач вы выбрали Овен. Тут либо вообще его менять, либо использовать ПР-ки для быстрых процессов и часть логики скидывать в них.
melky Так я ж про то и написал же, про чего ты мне ответил =)
Меня пугает один вопрос... если у меня примерно 100 входов и 100 выходов - это ж СКОЛЬКО ПРок надо будет? =) Я наоборот убежал от "поставим три комплекта Siemens Logo в щит" на ПЛК, а тут назад вертаться...
Я бы лучше такое с ПЛК110 провернул, потому что он умеет IO опрашивать быстрее.
А возможно, если ОВЕН уберёт Мх110 с поставок (вон, они писали что увлекаются Ethernet), то мне придётся от них уйти. Мне Мх110 очень нравятся.
Вообщен, CodeSys v3 САМЫЙ тормозной по опросу Modbus. Потому что (это уже часть ответа для krollcbas) я ж шёл по нарастающей:
0) Аппаратные импульсные реле.
а) Логические реле + их модули расширения IO. Работали быстро, все алгоритмы я там легко кодил на FBD и делал щиты.
б) ПЛК110. Работали тоже быстро, и все алгоритмы с Siemens Logo я туда портировал, перешёл на ST и продолжал фигачить по тем же принципам: ПЛК + модули IO и думал, что оно так и должно работать - быстро.
в) Потом перешёл на СПК на CodeSys v3. И вот тут и начались приколы. И не с самим СПК, а конкретно с Modbus, причём пофигу с каким - TCP/RTU - пофиг. Он там ТОРМОЗИТ, если опрашивать его штатными средствами.
Ишьты! Вот про шлюз спасибо! Я ещё не про всё в курсе, потому что шёл по пути "надоели реле - возьми логические, не хватает - бери простой ПЛК - нужна визуализация - бери СПК", а не от "Так, мне тут KNX надо".
Повторюсь, мне пара заказчиков подкидывала идею взять кнопки от KNX и прокинуть их через шлюз в ПЛК, чтобы не тащить кучу кабелей к ним. Как я понял, у тебя это же и сделано?
У меня по Modbus TCP опрашивается ABB CMS. Вроде не тормозит, да. Но там одно устройство всего. А вот шесть штук Mx210 на ПЛК210 уже тормозили.
Сколько у тебя на каких каналах устройств?
Ты их опрашиваешь штатными средствами, добавляя в дерево устройств?
Просто это называется разделение задач :) Если нужно выиграть время, то вместо Mx110 берем ПР ну или даже второй ПЛК с кучей дисретных входов и выходов и никаких RS485 для чтения кнопок.
Вот посчитайте стоимость второго ПЛК вместо некоторого количества MX ? сравните по цене.
melky Я не уверен, что хочу разделять. Одно дело, если бы там только свет был. А там может быть так, что на датчике присутствия и лампы будут висеть, и батареи, и шторы и ещё тёплый пол. И как тогда разделять?
Ещё раз напоминаю: около 100 входов и 100 выходов у меня ща - норма. К февралю буду собирать щит, где 100 входов и 200 выходов. И вот как это по ПЛК или ПРкам разбивать? Мне это неудобно.
Ща меня CodeSys v3 пока устраивает вовсю. Я научился работать. Дальше хочу пробовать кнопки от KNX брать, как krollcbas делает.
Да молча разделять. ПЛК на много входов-выходов сколько заменит модулей MX ? Берете такой ПЛК, пишите в нем логику кнопок и включений и сетевой обмен с головным ПЛК (СПК) для управления по сети или с экрана. Для головного ПЛК(СПК) он как модуль ввода вывода.
Если бы в Конфигурации ПЛК можно бы было делать опрос по сценарию, было бы проще, но представителям Овен наверное это не знакомо. Пример. 2 модуля участвуют в быстрых процессах, остальные в медленных, всего ну скажем 8 модулей.
1,2,3-1,2,4-1,2,5-1,2,6-1,2,7-1,2,8- и снова 1,2,3 Через библиотеки так наверное сделать можно, вот почему нельзя так же настроить конфигуратор ????
А опыт есть? Конкретный? Один же фиг, СПК будет этот "модуль" опрашивать так же, как и модули IO.
Наверное? Блин, вот тут я бы попросил или конкретики, или не сетовать. Я такое сделать могу, я с библиотеками разобрался специально под это дело.
Какой опыт вы имеете ввиду ? Это же принципы построения систем, а для большого дома при выбранной системе (Овен) сам бог велел.
Все быстрые процессы скинуть на другой мозг, между ним и основным мозгом сетевое взаимодействие. СПК будет его читать периодически для отображения на экране или WEB визуализации. Команды от экрана и визуализации должны проходить сразу в подчиненный ПЛК. Но сам ПЛК, на который вешаете быстрые процессы работает в цикле, к тому же, если он занимается только своими вх/вых то этот цикл минимален.
Я на ПЛК такое не делал, только на Scada системе. Если мне надо контролировать счетчик электроэнергии, он стоит в циклическом опросе, если мне надо из ПР читать или писать часть переменных постоянно, то забиваю эти переменные последовательно и одним групповым запросом так же читаю в цикле. Все переменные для настроек делаю дальше и можно тоже одним групповым запросом читать, но скажем раз в 30 сек а то и реже. Но никто же не говорит, что то же самое нельзя сделать и на ПЛК ? Разделите запросы и модули и уйдите от конфигуратора, раз у вас есть быстрые процессы.
Конфигуратор же выполняет опрос строго последовательно модуль за модулем, отсюда у вас и задержки, но наверняка часть ваших модулей можно читать реже.
Например частный дом - есть генератор, бассейн с вентиляцией. Не надо вешать все задачи на один ПЛК(СПК). генератором должен управлять свой мозг, вентиляцией бассейна свой. И вот тут еще добавляются кнопки (выключатели) и их тоже на свой мозг. И просто панель или СПК для агрегации, ну и все медленное на него можно тоже скинуть.
А, мы про разное.
Так то, что ты описал - это понятно. Скажем, у нас есть щит IPM™, щит автоматики бассеина, мелкие модули IO для сбора данных по коллекторным шкафам отопления - и мы с них собираем данные на уровне "О, мозг в щите IPM™ запустил генератор, сообщает что топлива хватит на 10 часов работы".
Это мне всё ясно и понятно.
А у нас речь ща идёт о том, что как раз этот самый один мозг, который должен рулить светом и простой автоматикой, с этим справляется с некоторыми тормозами.
А если разбивать его на отдельные мелкие части - так центральному ПЛК достанется больше обмена. И что этот обмен будет с модулями IO, что с ПРками - один фиг.
Причём с ПРками обмена будет в два раза больше: из модуля IO я читаю состояние входов и пишу в выходы, а в ПРке мне надо будет читать состояние света, записывать новое состояние света и ещё и делать это по флагу, чтобы UI с аппаратным состояние света не конфликтовал.
Так что я не хочу это ещё больше разделять.
КОРОЧЕ. Просто CodeSys v3 МДЛЕННЕНЕ раз в ДЕСЯТЬ, чем ПРки и чем CodeSys v2. Вот с этом - ПРОБЛЕМЫ. Когда там висит один-два модуля IO - то нормально. А когда десять (по 32 канала) - вот тогда уже будет весело.
Ну тогда поставьте эксперимент, раз не хотите разделять задачи. Отключите все модули, кроме парочки кнопочных. Успеваете все опрашивать и управлять ?
Если да, переходите на бибки и разделяйте опрос, быстрые в каждом цикле, медленные в очередь по одному с быстрыми.
з.ы. если кнопками рулит ПР например, то все двойные нажатия, короткие, длинные контролирует ПР - не тратится на это обмен раз, сокращается логика в центральном мозгу два, сокращается обмен между центром и ПР кстати три. (меньше переменных придется читать)
Так. Я щас сорвусь. Потому ни хера мой этот дьяволодиммер не пашет. Всё равно проскакивают какие-то мутные нажатия. НЕ ПОЛУЧАЕТСЯ! Вот не получается, и всё!
Короче melky, чёрт раздери тебя. УСЛЫШЬ МЕНЯ: CODE SYS v3 - МЕДЛЕННЫЙ. ПО ФАКТУ. ОЧЕНЬ! В ДЕСЯТЬ РАЗ МЕДЛЕННЕЕ СКАД, ПРок и ПЛК110!! И медленный (АДСКИ) медленный там опрос по любому Modbus-протоколу.
ДАЖЕ ЕСЛИ ТЫ ЗАДАЧЕ ОПРОСА ВЫДАШЬ ВРЕМЯ В 8-10 мсек - всё равно МЕДЛЕННЫЙ. У меня щас проект и состоит из двух FB всего: Dimmer и ClickTest. Один хрен.
Поэтому никакие советы по разделению и прочему тут не помогут. Сел я в лужу с этим идиотским диммером и уже так запутался в коде, что сам не понимаю, ЧТО написал и КАК оно работает и КАК должно работать. Всё. У меня коллапс мозга. Пойду в окно выкинусь.
Сколько кнопок используется в диммере? поставьте вместо модуля в/в ПР-ку, ведь наверняка есть у вас в наличии, хотя бы временно и напишите в ней свою ловлю кнопок
з.ы. ну вы сами выбрали CodeSys 3 и кучу модулей в/в, никто же вас не тянул строить все на одном мозге.
И кстати, вы счетчиками ловите нажатия, вы их как опрашиваете? по одному на вход или всей пачкой ?
melky Да можно на "ты", так проще и злее, чем этот официоз с выканьем.
Хватит мне втирать про отдельные ПРки! Это щас не имеет отношения к теме и делам. Этот способ тут не применим.
И хватит меня выводить из себя. Я тебе могу хоть по телефону наорать и объяснить, что CodeSys v3 ПОФИГУ кого опрашивать. ПРку или модуль IO - один фиг, это будет тормозить.
Выбрал, потому что у меня на этом откатано уже штук пять щитов. Но диммера в них не было ни разу. И я думал (да-да, это самы круитой аргумент), что написать диммер будет легко, потому что у меня был блок отлова нажатий, который на свет, вентиляторы, тёплые полы и мастер-кнопку работал на ура, чётко и без сбоев.
Модулей IO в этом щите у меня всего лишь 6 штук. Пять штук на 32 канала и один на 16.
Конечно же счётчики я все опрашиваю разом. Причём на тех входах модуля, которые нужны, а не на всех.
По ходу у меня косяки с логикой. Ща вон проистерил, в душ сгонял... и самый умный тут krollcbas, потому что он в курсе дела.
И косяки мои с логикой в том, что надо запихать обработку логики диммера в тот самый конечный автомат обработки кнопок.
По ходу дела, всё это грёбаное наследие Logo, FBD и прочее надо запихать в мусор и вспоминать как я микроконтроллеры на конечных автоматах прогал. Я всё забыл нафиг, потому что делал это как хобби в 2009 году, а потом в 2010 забросил.
Ща попробую запихать этот чёртов диммер в конечный автомат. Сову на глобус натянуть, блин.
ЗЫ. Про CodeSys v3 когда-нибудь я напишу пост. Напишу-напишу. Там круто с визуализацией, круто с программированием, но вот Modbus - это ЖОСТЬ и подстава.
ЗЫ2. Да, я уже ДАЖЕ думал делать так, что ставитиь в щите ПЛК110ый, который будет опрашивать модули IO с бешеной (там можно выставлять 5 мсек на модуль даже) скоростью и по Modbus TCP просто передавать битовые маски IO в Codesys v3. Возможно когда у меня будет время, я это попробую.
krollcbas Самая УЖАСНАЯ особенность работы CodeSys v3 в том, что там вытесняющая многозадачность. В том числе и на опросы. То есть, показалось ядру то, что надо отдать приоритет экрану - он другие задачи прям посередине цикла может остановить и переключиться на другую. Если это попадает на опрос устройства, то этот цикл опроса может выдавать ошибку таймаута ответа (при живой линии связи и живых устройствах).
Вторая УЖАСНАЯ особенность работы CodeSys v3 - это мутный штатный опрос Modbus-регистров. Если в CodeSys v2 у нас при таймауте опроса одного регистра отваливался весь модуль целиком сразу (и никто не пытался опрашивать остальные регистры), то в третьем CDS каждый регистр (канал опроса) модуля - это отдельная сущность.
И это вот меня бесит больше всего (речь идёт про штатный планировщик опроса)!
Вот образно, есть у меня модуль ..8А. Опрашиваю я с него 8 каналов положим восемью запросами. Таймаут на модуль стоит пусть в 100 мсек.
В CodeSys v2, если этот модуль отвалится со связи, он будет пытаться опросить первую группу регистров, получать таймаут и идти опрашивать следующий модуль. Задержка в опросе будет в 100 мсек.
В CodeSys v3, если модуль отвалится, он, гад, попытается опросить первую группу регистров, подождёт 100 мсек, потом начнёт пытаться опрашивать вторую группу регистров этого же отвалившегося модуля и ждать 100 мсек, потом третий... И в итоге вся связь и опросы встанут на 100 мсек х 8 = 800 мсек. Вот так-то!
Причём штатно этого не заметить, если опрашивать устройства медленно (типа частотников, датчиков температуры, влажности, освещения и прочей медленной фигни). А вот опросить модули IO - это проблема. И я ж не дурак, я выношу их на отдельный интерфейс, задаю им быстрое время реакции и опроса...
Решается это через либу OCL. Там всё так же тупо (и этим круто) как в CodeSys v2: мы как бешеные белки опрашиваем всё подряд. Что успело ответить - то и молодца. Что не успело - опросим ещё раз потом. Я хочу для модулей IO внутри щита использовать эту либу и даже делаю тузлу (медленно, ОЧЕНЬ), которая позволит сделать дерево конфигурации каналов IO, а потом сгенерит код для OCL с разбором всех значений.
Вот пока интерфейс выдумал: 52576
Вот такие дела. Но мне ща кажется, что у меня проблема в том, что я конечные автоматы не использую. Нажималка работает хорошо, а диммер - нет. Пойду кодить код.
Cs-Cs как скажешь, но ты тормоз :)
Потому что вынося задачу в отдельное устройство ты экономишь на всем.
1. цикл мозга уменьшается и не заморачивается распознаванием длинных нажатий кнопок да и вообще какой-то логикой
2. опрос уменьшается, так как из той же ПР надо считывать только состояния выходов, входы ПР считывает и обрабатывает сама
ну а так по теме
1. используете групповой запрос регистров модулей или каждый счетчик по одному из модуля читаете ?
2. определитесь, что есть короткое и длинное нажатие даже одним запросом? можете ?
3. какие модули используете ? МХ110-32ДН ?
1. Я тебя ещё раз спрашиваю: как мне 100 входов запихать в ПР?
2. Дааа? А как же визуализация? Мне же надо ещё и заставить ПРку переключить выход, если на визуализации кто-то ткнул кнопочку.
Про тему:
1. Стоит быть внимательнее. Я использую групповой запрос.
2. Нет. Как это одним запросом?
3. Да.
МАТЬ ЕГО!! НЕ РАБОТАЕТ!! Всё равно нет-нет, да и проскочит одинарное нажатие вместо длинного!!
Я опускаю руки ((((( Я неделю не могу победить этот дьяволов диммер!!
Чёрт... попробовал взять OSCAT. Так мало того, что эта фигня всего до 255 гоняет значение, так она тоже так же криво работает.
Потому что кнопка считывается раз в 100 мсек...
...и дрянь в том, что именно-то короткое нажатие я могу отловить. Но я не могу прикрутить то, чтобы в момент отлова короткого нажатия отлов длинного прекращался напрочь, и по короткому диммеры эти чёртовы включались и выключались, а не регулировались.
1. разделяйте процессы, быстрые на свои мозги - обмен только для показаний и передачи команд (это быстрее чем вся логика в одном мозге на модулях)
2. смотри выше, команды должны быть приоритетом выше и даже если есть задержка это есть на что списать, совсем не то же самое, что нажал кнопку выключателя и ждешь секунду, разницу видишь ?
2. человек нажал на кнопку и пошел - сколько в счетчике разница? 1 ??? - короткое нажатие - выполнил действие
Человек держит кнопку - сколько разница в счетчике ? та же 1? но при этом состояние входа в модуле 1 или 0 ?
У вас все 100 входов это кнопки с диммерами ? даже не представляю себе такой дом, у вас там что, вентиляция в сортирах на диммерах ? :)
Да уж, с нескольких модулей читать по 70+ байт это печалька для кнопок.... кнопочные входы на отдельный модуль и отдельный интерфейс, иначе никак...
Ни хрена я не понял про разделение, чёрт побери, и как его сюда применять. Давай эту тему закроем, потому что я тебя ну не понимаю, просто вообще ну никак.
Я зол на тебя, потому что ты сам же спрашиваешь и сам же отвечаешь спустя рукава. Модули у меня - Мх110. Ты про них же и спрашивал. Ну так раз спрашивал - то сам и узнай, как там счётчик импульсов по входам работает.
По фронту входа он инкрементируется, и всё. Поэтому когда сделали любое нажатие на кнопку, то счётчик увеличивается на 1.
При этом длинное нажатие я могу определить только по уровню.
Опрос модуля един, поэтому в FB и счётчик и уровень приходят одновременно. То есть если опрос протупил - то не будет такого, что мы увидим счётчик раньше уровня или наоборот.
Какая разница, сколько у меня диммеров, если речь идёт об одном FB?
Апломб про "кнопочные входы на отдельный модуль и интерфейс" просьба прекратить. Кнопок столько, сколько надо. Примерно штук 40-50. Диммеров из них 17 штук.
Что за тупость? Какой отдельный интерфейс-то? Я тебя спрашиваю последний раз: ты САМ ЛИЧНО трогал CodeSys v3 и ВИДЕЛ ли ты (логическим анализатором и/или пишущим осциллографом/сниффером протокола) то, КАК он опрашивает модули по Modbus? Вот если видел - то тогда давай говорить предметно. Если не видел - то пожалуйста не лезь ко мне с советами невпопад!
Cs-Cs как применять разделение. представь ПЛК(ПР) на входы которого подключены быстрые процессы (кнопки) а на его выходы управляющие реле.
ПЛК(ПР) не занимается визуализацией, опросом каких-то модулей, он занимается только слежением за кнопками и управлением от них - БОЛЬШЕ НИЧЕМ. Это когда надо быстро.
Что от этого ПЛК нужно знать голове? кроме состояния его выходов, больше ничего. То есть включен свет в кухне или нет, в спальне или нет.
Что голове надо передавать в такой ПЛК(ПР) ? только команду со стороны - "включи свет в сортире" - все, больше ничего.
ПЛК(ПР) сколько потратит времени на обработку собственных входов и выходов ? - один сраный цикл программы в несколько мс, при чем это несколько будет менее 10-ти...
Вот диммерные кнопки на один модуль и один интерфейс - раз
Правильно, длинное нажатие определяется состоянием счетчика и уровня, короткое только состоянием счетчика - какова будет погрешность, что при нажатии кнопки человеком (его желание только включить) совпадет действие с опросом ? Если счетчик изменился а состояние этого входа =0 однозначно короткое нажатие.
Если счетчик изменился, а состояние входа = 1 - сколько процентов, что это именно длинное нажатие ?
Если опрос протупил, мы как раз и увидим изменившийся счетчик и состояние входа = 0 если это было короткое нажатие, ведь так ?
Про тупость CodeSys 3 снифером не цеплялся и другой ПЛК на нем щупал. Овен как-то даже не хочется :) вообще удивляюсь как вы его выбрали для умного дома :) Точнее как вы выбрали только СПК для такой задачи, да еще и Овен :)
Евгений Кислов
19.12.2020, 21:38
В микросекундах:
52580
Евгений Кислов
19.12.2020, 21:49
Ну так если цикл такой маленький (заявлен даже меньше 1мс) но не вижу проблем в обмене если работать напрямую через местный аналог syslibcom. Он есть ?
Аналог SysLibCom, конечно, есть.
Проблемы станут видны, когда окажется, что контроллер должен делать что-то еще, кроме ловли нажатий кнопок - и тоже, разумеется, быстро.
Или когда оборвется кабель связи (библиотека синхронная, ждем таймауты всех модулей...).
Безусловно, при желании можно даже это обрабатывать - ждем какое-то время восстановления шины, если не поднялась - вообще прекращаем обмен. Возобновление по нажатию кнопки на экране и т.д.
Евгений Кислов
19.12.2020, 22:08
А разве для обмена нужно что-то быстрое ? Обмен - процесс медленный по сравнению с заявленными циклами.
Судя по предыдущим постам в теме - в данном случае нужно.
И, очевидно, есть разница между пустым циклом и циклом конкретного пользовательского приложения.
Про какую биб-ку говорим ?
Про SysCom, естественно ("местный аналог syslibcom").
А это вообще - что ?
Естественное возобновление нормальной работы линии связи после, например, прекращения действия краткосрочной помехи.
Валенок Ой как я буду ругаться. Я очень жёстко не люблю тех, кто читает невнимательно. CodeSys 2 от CodeSys 3 отличается примерно как MS-DOS от Windows 10. И если хоть ещё кто в этой теме скажет "Да вот у меня на CodeSys v2 всё пашет, хрен ли вы тут морочитесь", то я призову на него все кары мира. Потому что надоело!
Вы хочите цифр? Их есть у меня. Даю средние времена цикла за 4 часа работы ПЛК:
Задача опроса модулей IO = 671 мксек
Задача этого диммера, одна, только с диммером (проект пустой до сих пор) = 453 мксек
Но при этом реакция ПЛК на кнопку не мгновенная, как на CodeSys v2. Ты можешь кнопку нажать, а ПЛК её не увидит.
Я снял короткое видео, прям с рук, показать реакцию: https://cs-cs.net/ExxChange/MAH01874-CodeSys-v3-Modbus.MP4
Я сранивал это в других проектах на ПЛК110. Там светодиоды опроса на модуях IO мерцают почти постоянно, а тут видно перерывы между ними.
А теперь ГВОЗДЬ ПРОГРАММЫ. Ещё одно видео: https://cs-cs.net/ExxChange/MAH01875-ModbusPoll-IO.MP4
Я взял на компе Modbus Poll, загнал туда все шесть модулей IO, выставил на каждый интервал по 10 мсек, интервал между фреймами в 5 мсек и читаю...
(3 х (32 + 2)) + (2 х 2) + (1 х 1) = 3 х 34 + 4 + 1 = 102 + 5 = 107 регистров в общей сложности на 115 200... иииии! И дело не в Modbus, не в том, что он тормозной и старый, и даже не в "низкой" скорости. На видео видео, что модули реагируют почти моментально на нажатие кнопки!
Вот на CodeSys v2 планировщик опроса именно так и работает: читает всё подряд без разбора
На CodeSys v3 всё работает в десять раз медленнее!
Поэтому если кто-то ещё хоть слово пикнет про быстроту, про ПЛК 110 и CodeSys v2 - пришибу. Всеми RTU-пакетами разом. Я уже не знаю, что вас всех убедит ещё.
ЗЫ. Евгений Кислов сохрани видео на память, если тебе удобно. Это прям яркий пример на тему CDS 3. И это на OCL даже!
И ещё. А в OCL можно менять интервал между фреймами? Я бы его воткнул бы в 5 мсек. Сколько он там задан?
Чёрт, я знаю что ты в отпуск хотел... может лучше поотдыхать?
Вернёмся к диммеру моему многострадальному. Я уже начал над ним смеяться, так что стадия истерики прошла.
Так вот что у нас получается (тем, кто не читал гуляющую по Сети "Историю Одного Байта" - я очень рекомендую к прочтению поржать):
* Ловим короткие нажатия по уровню (биту). Нажали, а CodeSys не успел среагировать - Fail, нажатие пропущено;
* Ловим короткие нажатия по счётчику импульсов - ура, ловятся и не пропускаются.
* Ловим длинные нажатия по TON - ура, ловятся. Небольшая задержка в реакции пофиг, так как нажатие длинное.
* НО! Сделали несколько коротких подряд - попали в ситуацию когда из-за медленного опроса CodeSys видит их не как TRUE-FALSE, TRUE-FALSE, TRUE-FALSE, а пропускает некоторые FALSE и видит как TRUE-TRUE-TRUE-FALSE-TRUE-TRUE и иногда считает длинным нажатием - Fail!
* Ставим блокировки на TP или TOF после того как поймали короткое или длинное нажатия, чтобы не ловить другие нажатия? Чёрт побери, а из-за проглатывания нажатий система снова видит TRUE-TRUE-TRUE, считает это длинным и все эти блокировки уходят не в ту степь...
Вот такие пироги на данный момент. Я попробую ещё раз накодить вариант с конечным автоматом и блокировками после выполнения действия по нажатию. Сдаётся мне, что TP работает не так, как описано в справке...
Евгений Кислов
20.12.2020, 10:23
А в OCL можно менять интервал между фреймами? Я бы его воткнул бы в 5 мсек. Сколько он там задан?
OCL дает контроль на уровне отдельных запросов, так что интервал между фреймами зависит от кода пользователя.
В данном случае, этот интервал - время между срабатыванием xDone одного блока и фронта xExecute следующего.
Я взял на компе Modbus Poll
Я предлагаю на ПК запустить виртуальный контроллер CODESYS (CODESYS Control Win V3) и запустить на нем проект из видео. Это займет минут 5.
В результате станет ясно, влияет ли как-то "железо" на получаемые результаты.
krollcbas О! Давай попробуем! Но я тебя огорчу...
1, 2, 3. Интерфейс точно в порядке. Я смотрю по счётчику ошибок. Их набегает 20 штук за сутки при опросе через OCL. При опросе средствами CodeSys v3 их набегает около 2000 за сутки.
4. Читаю одним запросом READ_MULTIPLE_REGISTERS, получаю массив из двух WORD. Потом разбираю их в коде побитно в переменные BOOL.
5. Дребезг не буду убирать, сейчас ниже поясню почему.
6. Счётчик импульсов аппаратный. Ловит вовсю, без проблем.
7. И вот самое интересное. Я вчера так и сделал, только через Modbus Poll. Вот цитирую из моего длинного ответа:
А теперь ГВОЗДЬ ПРОГРАММЫ. Ещё одно видео: https://cs-cs.net/ExxChange/MAH01875-ModbusPoll-IO.MP4
Я взял на компе Modbus Poll, загнал туда все шесть модулей IO, выставил на каждый интервал по 10 мсек, интервал между фреймами в 5 мсек и читаю...
(3 х (32 + 2)) + (2 х 2) + (1 х 1) = 3 х 34 + 4 + 1 = 102 + 5 = 107 регистров в общей сложности на 115 200... иииии! И дело не в Modbus, не в том, что он тормозной и старый, и даже не в "низкой" скорости. На видео видео, что модули реагируют почти моментально на нажатие кнопки!
Что было сделано:
* От СПК было откинуто питание и адаптер интерфейсов. То есть СПК мы отключили.
* На эту линию (на тот же кабель в щите) были подкинуты два кривых провода, валяющиеся по комнате, не свитые
* Через ОВЕНовский USB-RS-485 адаптер был подцеплен Modbus Poll с указанными выше параметрами.
И оно залетало! Так что дело и не в фильтре дребезга, и не в линии...
Такая фигня у меня с СПК на всех щитах, которые я на нём сделал, была. Прям однотипная - телеграммы летают медленно.
Я ставил кучу опытов и с задачами (и делил по задачам, и собирал всё в одну задачу), и с таймингами - получается ещё хуже, чем щас.
Могу натравить логический анализатор сегодня ночью (днём смотаюсь по делам) и посмотреть им, как СПК работает (я в будущем собирался это делать для статиь на блоге).
И ещё ночью я подтяну ПЛК110 и посмотрю, как он это всё будет опрашивать. Аж интересно!
А скажи, сколько штук у тебя модулей IO, которые ПЛК210 опрашивает, и чем нагружен сам ПЛК210 (ну, задачами и действиями)?
У меня всё время получается, что логика летает с космической скоростью, а тормозит сам опрос.
Валенок Чёрт подери... что ж все такие резвые, но ни фига невнимательные-то? Неееет, моё терпение лопнуло. Ты или перечитай тему с её начала, или глянь видео. Вот там и увидишь и что такое nnn мксек, и какие модули стоят и как.
Я предлагаю на ПК запустить виртуальный контроллер CODESYS (CODESYS Control Win V3) и запустить на нем проект из видео. Это займет минут 5.
В результате станет ясно, влияет ли как-то "железо" на получаемые результаты.
Ну с OCL загрузка проца в СПК стала в 70% примерно (была 50%). По идее железо будет влиять.
А как виртуальному контроллеру надо будет указать физические порты, с которых он опрос будет вести?
Сечас побалуюсь, попробую!
Евгений Кислов
20.12.2020, 10:44
Ну с OCL загрузка проца в СПК стала в 70% примерно (была 50%). По идее железо будет влиять.
А как виртуальному контроллеру надо будет указать физические порты, с которых он опрос будет вести?
Сечас побалуюсь, попробую!
В этом случае указывается номер виртуального COM-порта из диспетчера устройства Windows.
Хммм... он на виртуальном ПЛК ругается на OCL. Пишет что "...невозможно конвертировать тип ULINT в UDINT" во многих FB либы.
Евгений Кислов
20.12.2020, 10:52
Хммм... он на виртуальном ПЛК ругается на OCL. Пишет что "...невозможно конвертировать тип ULINT в UDINT" во многих FB либы.
Покажи, пожалуйста, скриншотом, какой таргет виртуального ПЛК ты выбрал.
Нужно выбрать именно CODESYS Control Win V3 (не x64, не RTE и не какой-либо другой).
Этот: 52586
Надо было Realtime брать?
Евгений Кислов
20.12.2020, 10:57
Нужно выбрать именно CODESYS Control Win V3 (не x64, не RTE и не какой-либо другой).
И версию лучше поставить 3.5.14.30.
Валенок Неее! Ещё читай до полного понимания =) Надоело объяснять каждому, кто просто забежал почитать.
Итак, ВИДОС: https://cs-cs.net/ExxChange/MAH01877-CodeSys-Win-Requests.MP4
Циклы выполнения задач (в том числе опроса через OCL) сократились до десятков микросекунд О_о!
Но при этом CodeSys всё равно так же, как и на ПЛК, медленно опрашивает модули. Как будто он сам делает задержки.
Пошёл за логическим анализатором... интересно!
ЗЫ. Чёрт, НЕ ТАК я собирался набирать инфу о работе планировщика опроса Modbus в CodeSys v3... думал, буду тихо под чай проводить опыты... А не экстремально изучать на лету =)
Евгений Кислов
20.12.2020, 12:00
На мой взгляд - эксперимент наглядно показывает, что наблюдаемый эффект никак не связан с железом и к СПК тут вопросов нет.
Остаются две момента, которые могут влиять на происходящее:
- какие-то особенности рантайма CODESYS в плане работы с COM-портом
- пользовательский код
Я хотел бы обратить внимание, что OCL - это обертка над библиотекой CAA SerialCom, которая является асинхронной.
Таким образом, выполнение каждого ФБ MB_SerialRequest занимает как минимум 2 цикла контроллера (на практике - их может быть больше).
Если предположить, что в проекте 10 запросов Modbus (по 2 на каждый модуль с DI и по одному на каждый модуль с DO), и они вызываются в задаче с заданным интервалом вызова T#10ms - то период полного опроса шины в принципе не может быть меньше, чем 200 мс (больше - может). Поэтому если длительность нажатия на кнопку меньше, чем 200 мс - то оно может быть пропущено, и это не должно вызывать удивления.
Переписать обмен через синхронную SysCom - совершенно разумная идея в рамках проводимого эксперимента.
Итак, докладываю! Я натравил Saleae (простой и дешманский логический анализатор БЕЗ развязки по GND - будьте осторожны!) на линию.
Видео с моими путанными комментариями лежит тут: https://cs-cs.net/ExxChange/MAH01879-Saleae-CodeSys-v3.MP4
Файл с данными логического анализатора лежит тут: https://cs-cs.net/ExxChange/CodeSys-v3-Modbus-115200.logicdata
Вы можете найти в сети бесплатную программу Saleae Logic (на сайте производителя https://www.saleae.com/ru/downloads/) и посмотреть этот файл прямо в ней без самого анализатора. Можно увеличивать его, подключать разные анализаторы потока данных и смотреть прям байты, которые в линии ходят.
Комментари путанные, потому что я на телу путался переводить DEC-HEX, а я в этом не спец.
Даю кучу скирншотов и пояснений.
1. Весь поток данных в линии выглядит таким образом: 52587 - идёт куча запросов-ответов к модулям IO.
2. Мы знаем, что я читаю и что пишу, а именно:
а) Запрос к модулю ввода на чтение битовой маски (два регистра, модуль на 32 канала)
б) Запрос к тому же модулю ввода на чтение 32х регистров счётчиков входов
в) Запрос к модулю вывода на запись битовой маски (два регистра)
Адреса модулей:
10 (0x0A) = Входы 1 (32 канала)
12 (0x0C) = Входы 2 (32 канала)
14 (0x0E) = Входы 3 (32 канала)
20 (0x14) = ВЫходы 1 (32 канала)
22 (0x16) = ВЫходы 2 (32 канала)
23 (0x18) = ВЫходы 3 (16 каналов)
3. Вот мы видим, увеличив график, что у нас так и есть: запрос и короткий ответ (битовая маска), а потом запрос и длинный ответ (счётчики входов): 52588
4. Окей, посмотрим, что же там такое есть: 52589
Ага! Это мы шлём модулю с адресом 0x0E (14) команду 0x03 - чтение регистров. В количестве двух штук. Битовую маску читаем, значится =)
5. Через 4,74 миллисекунды модуль нам отвечает: 52590
То есть, сам модуль отвечает быстро и работает хорошо.
6. Вот его ответ: 52591 - он нам сказал, что пойдут 4 байта данных (так как регистр занимает два байта, а мы читаем два регистра). И так как на этом модуле никакие кнопки сейчас не висят, и ни один вход его не активен - то бвся битовая маска у нас - нули.
Тут мы убедились, что Запрос-Ответ были именно к модулю вводов, и что мы читали именно битовую маску, и что модуль ответил за 4,74 милисекунды.
7. А теперь - ФАРШ! Дальше CodeSys v3 (что на виртуальном, что на физическом ПЛК), зараза, ЖДЁТ аж 73 мсек, и потом начинает опрашивать следующий модуль: 52592
8. Модуль, не будь дурак =), отвечает опять быстро - за 5,154 мсек: 52593
Время ответа чуть больше, и я вангую, что оно больше из-за того что в прошивке модуля в этот момент в буфер ответа копиурется большооой массив байт )) То мы отвечали четырьмя байтами, а то аж сразу сорока байтами. Вот время на подготовку ответа модулем и стало больше.
9. Ну и дальше всё то же самое: 52594 - везде эти паузы появляются.
При этом напоминаю, что сейчас опрос я веду через OCL и, как Евгений Кислов говорил, тут никаких интервалов между фреймами быть не должно.
Да и задача опроса у нас выполнялась на ПЛК в среднем за 650 микросекунд - то есть, по сравнению в ответами модулей, адски быстро.
К ночеру попробую выложить инфу о том, как ПЛК 110 эти модули опрашивает. Анализатор у меня без развязки (я писал) и я боюсь, что чего-нибудь бахнет, так как у меня будет блок питания в щите для модулей IO, блок питания настольный для ПЛК, и блок питания от компа для питания компа, куда по USB анализатор воткнут.
Мне аж интересно, как ПЛК110 будет такие запросы фигачить!
ЗЫ. Евгений Кислов, тема уже перешла в "... как работает Modbus в CDS3" =)) Правда, я собирался набрать материал на пост, про который тебе всё говорю. Но тут неожиданно получается, что есть живой материал вот прям сейчас
Может тему уже в раздел по CodeSys v3 переместить? И к названию добавить что-то про скорость работы Modbus?
Переписать обмен через синхронную SysCom - совершенно разумная идея в рамках проводимого эксперимента.
Ой! Новые знания... а есть ли документация про это? Я перепишу!
Посмотрел на либу... ах ты ж! Это то, чего я боялся - что придётся сами запросы Modbus с нуля составлять... на уровне байтов! Эхх!
Ну, "Ныряй, здесь неглубоко" ©
Пойду погуляю, приду - буду кодить!
Евгений Кислов
20.12.2020, 13:07
А можно забыть про "интервал вызова" а просто каждый следующий сразу после окончания транзакции предыдущего ?
Конечно, можно - через SysCom и его синхронные вызовы.
Следующая тема на форуме, видимо, будет "что-то при обрыве линии RS-485 визуализация очень сильно тормозит, как будто ее что-то блокирует".
Я согласен с вами в том ключе, что в ряде конкретных случаев обмен через синхронные функции в CDS V3.5 - единственный способ решения поставленных задач.
Но на практике - эти задачи обычно рождаются из изначально неправильного подхода при проектировании системы автоматизации.
Надо сказать, 10 мс я взял из умозрительных соображений (так обычно по дефолту) - какие интервалы и приоритеты задач у Cs-Cs мы пока что не знаем.
Евгений Кислов
20.12.2020, 13:15
Может тему уже в раздел по CodeSys v3 переместить? И к названию добавить что-то про скорость работы Modbus?
Я пока повременю с этим, потому что она касается не конкретных особенностей контроллеров ОВЕН, а более глобальных вопросов работы обмена в CODESYS V3.5
Но когда результат обсуждений будет формализован в виде статьи - то с радостью добавлю.
Это то, чего я боялся - что придётся сами запросы Modbus с нуля составлять... на уровне байтов! Эхх!
В рамках теста - можно просто захардкодить запросы, чтобы быстрее получить результаты эксперимента.
capzap Отвечаю согласно PDFничку:
1. Данного компонента у меня НЕТ =) Я веду опрос через OCL (OwenComminucation).
До этого ставил опыты с временем цикла в 5 мсек, в 8 мсек и в 10-20 мсек. На 5 и на 8 мсек ошибки начинают валиться пачками, а на 10-20 работает нормально, но тормозит ЕЩЁ сильнее.
2. Также, я не использую штатный конфигуратор для опроса сейчас.
До этого время опроса DI стояло 20 мсек, DO тоже 20 мсек.
Валенок Терпеливо. Читающий да найдёт. Только что же писал про модули, когда давал картинки с логического анализатора и писал адреса модулей. Все модули серии Мх110.
Если 1й гуано - то дальше ловить нечего. Это как-то проверили ?
*граммофонным голосом* ПРОВЕРЯЕМ. Оставайтесь на линии =))
Евгений Кислов Нет, такой темы не будет. Я ещё не настолько сильно отупел, и про асинхронные понимаю.
Так как это канал связи внутри щита, то обрыв связи означает то, что щит и не должен работать ВООБЩЕ. Так что даже если всё будет тормозить - это так и так полное ЧП.
В рамках теста - можно просто захардкодить запросы, чтобы быстрее получить результаты эксперимента
Да, всё. Не пойду гулять. Завариваю чай и ныряю. Не буду хардкодить, сейчас попробую сразу нормальный опрашиватель написать.
Ну про неправильный подход я не согласен. Возможно, неправильный подход - это делать автоматизацию квартир и коттеджей на СПкшках, но это сейчас лучшее на рынке из того, что есть. У других производителей или Web кривой, или среды разработки мутные, или железо плохое.
Поэтому я хочу выжать максимум из СПК.
Дополнение. Побаловался с ПЛК110. Вот там всё гораздо веселее.
Вот видео: https://cs-cs.net/ExxChange/MAH01880-CodeSys-PLC110-Modbus.MP4
Вот файл анализатора (кривоватый): https://cs-cs.net/ExxChange/CodeSys-v2-Modbus-115200.logicdata
52595 52596
Тут запросы идут через 10-12 мсек, а ответы модулей такие же как и раньше - за 4-5 мсек.
Когда я погружался в ПЛК, то я начинал со 110ых. И там всё как раз летало вовсю. И поэтому то, что CDS 3 опрашивает устройства медленнее, для меня было открытием в своё время.
Мое ухо одного резануло то, что одним запросом читается маска, а вторым запросом счетчики ? не?
Просто одним запросом прочитать весь модуль не бывает ?
Валенок да как не? MB110-32ДН Битовая маска значений входов регистры 0x63 и 0х64 и далее с 0x65 пошли счетчики входов.
Как не? опять что-то поменялось в Датском (Овеновском) королевстве ?
melkiy Про прочитать одним запросом. Угу! Это - инерция мышления. Когда-то привык, что в некоторых (не ОВЕНских) модулях регистры могут идти не подряд, так и делал. Перетряхну на один общий запрос, конечно.
capzap Штатный работает ещё медленнее, чем OCL. Поэтому на OCL и перешёл.
Валенок Мне сказали, что ты всех троллишь. Окей, вот, держи список:
МВ110-32.ДН = 3 штуки. Читаем битовую маску и счётчики входов (количество зависит от модуля: где-то все 32, где-то только 12, где-то 16)
МУ110-32.Р = 2 штуки. Пишем битовую маску выходов
МУ110-16.Р = 1 штука. Пишем битовую маску выходов
Порт ща будем юзать. То есть ээ... собак учить. Но не плавать, а летать. Методом "засунем петарду в собаку и посмотрим, полетит или лопнет".
capzap А я там писал. Сейчас, найду, повторю:
* На интервал между фреймами пробовал ставить 5-10-15-20 мсек. На 5 мсек всё работает быстро, но валятся ошибки таймаутов. На 20 мсек всё работает медленно, но ошибок не валится.
* Сама скорость опроса каналов стоит по 20 мсек на канал.
capzap Не понял. Ну 20 мсек на канал. И что тут не так?
Как тогда это работает в CDS v3 (я это сам собрался исследовать, но вдруг уже есть ответ)?
Вот положим у меня не туева хуча, а всего лишь шесть модулей. Это не 20 модулей же.
Как тогда мне время опроса канала ставить? Считать руками, что ли? По идее этим сам планировщик опроса CDS должен заниматься.
Блин! Ну-ка поясните мне, а как в DO слать битовую маску тогда, если я не знаю, что у меня в ней в какие моменты изменится?
Ща-ка поднабросим-ка... на вентилятор.
Вот у меня есть модуль DO. На 32 канала. Например, из него:
* Часть каналов - это приводы кранов отопления
* Часть каналов - это лампы
* Часть - шторы
* Часть - вентиляторы
Всё это обсчитывается и управляется в разных местах проекта (и даже разных задачах) в разных булевых переменных.
Вы тут с Валенком напираете на запись IO по изменению. Ну и как я буду отлавливать в задачах изменение отдельных бит битовой маски и потом её писать один раз-то?
Или вы что? Не используете безопасные значения на модулях, что ли? У меня на модулях стоит настройка безопасных значений: если его не опрашивать, то через 5 секунд модуль переходит в безопасное состояние (аварийное).
Как тогда у вас, троллей чёртовых, вообще промка работает?
И последний забавный вопрос. Почему у меня ПЛК110 c теми же чтениями-записями ЛЕТАЕТ? И при этом не жалуется на какие-то там 20 миллисекунд задержек.
Валенок Эммм... я не фанат туалетного мышления с кабинками, поэтому эти образы мне не совсем понятны.
Что мне слышать и чувствовать, когда я посмотрел всё логическим анализатором? И я вижу, что запросы пролазят хорошо. На ПЛК110.
Не отвеченным остался мой вопрос про то, как там в промке про отвал связи и безопасные значения?
Или это было keep-alive, что ли?
Просьба уточнить:
а) А чем это отличается от обычной отправки запроса к модулю?
(я знаю, что якобы меньше загружает шину)
б) Что будет, если именно в момент отправки запроса по изменению маски будет Framing Error, и запрос до модуля не дойдёт?
(я не фанат событийного программирования, и телеграмм типа как в KNX: там нет никакого подтверждения о том, дошло это до адресата или нет)
в) На сколько в байтах это уменьшит загруз линии?
(на 8 байт из сотни - так вот прям это поможет-то?)
ЗЫ. Ща мучаю SysComLib. Отсылать - отсылаю, пока не пойму как прочитать. Ща задержки введу туда и буду мозговать.
Сам опрос летает на ней даже быстрее, чем модули успевают отвечать. Так что да... собака с петардой кажется собирается взлететь, да.
Так. По запросам (по скорости их отправки) SysLibCom рулит, да. Светодиоды мигают на модулях как бешеные.
Сами модули при этом отвечают за 5-6 (максимум) мсек, так что запросами их можно закидывать до умопомрачения.
Я ни разу до сегодня SysLibCom не юзал и не понял, как ею читать из порта. По логическому анализатору я вижу, что интервалы между запросами и ответами там в 13-25 мсек (это плавает в зависимости от других задач), но у меня не получается пока что прочитать назад в ПЛК ответ из порта.
52603
По ходу дела писать SysComWrite и сразу SysComRead было плохой идеей. Я даже пробовал сдвигать чтение на следующий цикл задачи - всё равно пока не соображу, чего не работает.
Валенок
1. Про SysLibCom не решили. В ответ я получаю 2/3 мусора, а 1/3 правильных ответов.
2. Как именно в SysLibCom - я не знаю. Под CodeSys v3 документации мало. На днях попробую вытащить примеры из CodeSys v2.
3. Так ПЛК ж работает циклами - всякие FB, таймеры же. Как по другому их обсчитывать-то?
4. А вот не надо странных интонаций. И про секреты не надо. Лучше прямо пиши.
А в чём разница байтов и запросов? По мне так всё равно же запросы упираются в пересылааемые данные.
Ща тестану на OCL более длинный запрос, да, чтобы на три штуки сократить число запросов. Посмотрим, даст ли это что-то.
5. Ну, гм... ты не читал раз пять, я тоже до пяти раз дождусь, а потом начну включать понималку.
6. Про унитазы не надо. Я могу завернуть тему (и Тему тоже) и похлеще, но это ж не тот форум. Профиль не тот, так сказать.
7. Так что мне даст запись битовой маски по изменению. Ну буду я слать её:
а) Раз в 3-4 секунды для keep-alive
б) По изменению
Даст ли мне это убыстрение, если у меня тьма ситуаций вида "Нажали кнопку - включился выход" - то есть, как только я считаю кнопку, мне сразу же надо писать на выход. И в этом случае у меня получится то же, что получается и сейчас: пачка запросов к модулю вывода.
Не понимаю, в чём плюс подхода записи несчастной фигни по изменению для моих задач.
Дополнение. Про сокращение числа запросов. Вот ты предлагаешь читать маску входов + счётчики входов одним запросом, так как они в карте регистров идут подряд.
Но у меня же читаются НЕ ВСЕ счётчики входов. Частные случаи в этом проекте, например, такие:
Модуль 1 - Читаем счётчики с 21 по 31
Модуль 2 - Читаем счётчики с 2 по 17
Модуль 3 - Читаем счётчики с 1 по 32
Вот я и не сокращал запросы до "счётчики + маска", чтобы не читать то, что мне не нужно и сократить длину данных.
Я прав или нет? Получается, что из-за большого интервала между запросами тут проще прочитать вообще всё?
Ну-ка, попробую
Дополнение 2. Нет, стало хуже, если читать счётчики + маску одним длинным запросом. И визуально тормозит и по анализатору видно, что опрос генерит ошибки. Верну как было на OCL.
А кетаец с осциллом это подтверждает ?
Да в том-то и дело, что ни фига. Там на нём, как на ПЛК110 ровненько идёт: запрос - ответ, запрос-ответ.
Скорее всего я не понял, как эта либа работает и читаю что-то не то и/или не в те моменты.
по дополнению, если программа предполагает так же чтение счетчиков, то в схеме они должны быть первыми, чтобы всегда было с 1-ого по Х---какой-то
melky На будущее я возможно этот момент внесу в техкарту этапов проектирования, чтобы не забывать так делать.
Там же - да - идут регистр (или два) битовой маски, а потом счётчики.
Валенок Так, ща, сначала рассортируем путаницу про ошибки и битые байты.
Во ВСЕХ случаях по логическому анализатору я вижу, что модуль получает запрос и что он отдаёт корректный ответ.
Однако:
а) На штатном опросе через конфигуратор работает медленно и периодически сыпятся ошибки таймаута. Косвенно это зависит от интервала между фреймами, но НЕ зависит от времени опроса канала. Такое ощущение, что штатный планировщик не успевает что-то опросить (или прочитать ответ) и вываливается в таймаут.
За сутки у меня набиралось около 2 000 ошибок.
б) На опросе через OCL опрос идёт быстрее, количество ошибок - около 20 в сутки.
в) Мои пробы через SysCom пока не увенчались успехом, потому что я не разобрался как получать ответ от устройства. Иногда я читаю верный, иногда - мусор.
Ещё раз повторю, что на анализаторе и на шине я вижу и интервалы между запросами, и ответы модулей IO. Там всё отлично, и нет такого что мы передавали данные, оборвали их, и вдруг стали передавать что-то другое.
Про времена. Тут ты меня этими t0, t1 запутал. Это напоминает плохой стиль программирования, когда куча переменных и ни фига не ясно.
Поэтому можешь ли ты подставить нормальные цифры? Это ж ты в туалетах смыслишь, а я - простой дурачок, не понимаю вот.
Но зато знаю, что на скоростях выше 19200 эти времена между фреймами должны быть уже не 3,5 символа, а чётко фиксированными:
а) 750 мксек между символами;
б) 1 750 мксек (1,75 мсек) между фреймами
Так что на 115 200 тайминги будут другие.
Короче. Вот давай возьмём те данные для Saleae и просто померим. Фигли считать?
Вот запрос на чтение 32 регистров: 52604
Время запроса (с запасом я там маркеры поставил) равно 0,847 мсек.
Вот ответ на этот запрос: 52605
Время ответа равно 6,131 мсек.
Тут у нас отдаётся 32 регистра.
Среднее время на регистр равно 6,131 / 32 = 0,191 мсек
Вот ответ на запрос битовой маски: 52606
Время ответа равно 0,781 мсек.
Тут отдаются два регистра.
Среднее время на регистр равно 0,781 / 2 = 0,390 мсек
Время на подготовку ответа модулем колеблется от 4 до 6 мсек (это было ранее показано).
То есть, прикидочно считаем так:
а) Запрос 1 занял 0,847 мсек + подготовка Ответа 1 заняла 6 мсек + Ответ 1 занял 6,131 мсек = 12,978 мсек.
б) Запрос 2 занял 0,847 мсек + подготовка Ответа 2 заняла 5 мсек + Ответ 2 занял 0,781 мсек = 6,628 мсек.
в) И ещё не забываем интервал между запросами ПЛК, который в лучшем случае равен у меня 10-12 мсек.
Вот тепрерь я наглядно вижу, что простой запрос на чтение пары регистров занимает аж половину времени запроса на чтение 32 регистров. А если учитывать интервал между запросами - то аж чуть ли не большее время.
Вот это - наглядно. А не t0, t1, t2...
И вот это - аргумент для чтения регистров подряд. Мне кажется, ты кому-то в теме про AI пояснял про STRING для ПЛК110. Вот можешь эти скриншоты взять вместе с расчётами и показать людям наглядно, как длинный запрос экономит время.
Про запись по изменению. Ну так я и не использую. Это ж ты про кабинки начал и про туалеты. У меня, кхм, не было такого вот гоповского опыта - в очередях стоять и туда-сюда бегать. Мы из более чистой среды - анимешников, готов. Это когда в рубашках с жабо и кружевами вино пьют и о высоком разговаривают. Или в длинных пальто и шляпах по паркам гуляют а-ля 19 век.
Все норм, все устраивает.
Да неее! Верну - это значит, что сейчас я этот щит гоняю сутками без перерыва в режиме Test IO. Это когда ВСЕ реле и нагрузки включены, блоки питания нагружены по максимуму. В этом случае программа может быть полностью не написана (только тестовый режим), но зато можно недельку так щит погонять, чтобы вылезли глюки модулей, реле, блоков питания (ну, например расчёты мощности проверить).
Я это имел ввиду - что верну опрос модулей, чтобы тестовый режим работал. А так буду разбираться с SysComLib, по любому прям! Она, кстати в первых тестах даже процессор грузила меньше, чем OCL. На OCL было под 70%, тут под 60%.
Оно надо мне ?
А кто ж тебя знает. К примеру, если бы тебе тут было бы не надо - то ты бы, как спокойный и грамотный человек, мимо бы прошёл. Значит - надо, значит интересно.
Угу. Я практик, мне проще померить, чем рассчитывать.
Пока всё. Дальше мне надо дня на три отвлечься на другое, а потом я к SysCom вернусь.
Погоди, Валенок. А чего ты выяснил? У меня ж не получилось пока. Пока получилось только запросы посылать, а ответы нормально я не получаю.
Я считаю это недоделанным делом, и выводы делать пока рано.
capzap У меня на блоге (на техническом) есть куча таких вот советчиков. Которые что-то знают в общем виде, но не имеют конкретной практики по моему вопросу или теме поста...
Так вот. Можно я задам прямой и точный вопрос: вы (ты) ЗНАЕТЕ, КАК устроен и КАК работает штатный планировщик опросов CodeSys v3?
Например, что будет если я создам десяток одинаковых устройств (датчики температуры и влажности), в каждом из которых будет опрашиваться по 5 регистров с временем 500 мсек для каждого? Как планировщик распределит это по времени? Что он будет делать?
Вот если не знаете (не знаешь) - то просьба не лезть сюда вообще ну никак с абстракциями и общими рекомендациями. Либо выкладывать сюда PDF, где производителями CodeSys будет описано, как это работает именно в третьей версии. Тогда и будем говорить предметно, а не общими фразами и догадками.
Также второй претензией (также как и к Валенку была) является чтение темы по диагонали. То есть, если вы (ты) сюда забежали бросить парочку стандартных фраз, увидев только два ключевых слова "modbus RTU" и "плохо работает" - то честь вам и хвала за внимательность. Мне скучно и не интересно по пять раз повторять одно и то же: просьба читать ВНИМАТЕЛЬНО!
а) Штатный опрос всегда даёт тормоза. Дикие. И ещё и кучу отвалов по таймауту.
б) Опрос через OCL грузит процессор до ~70%, даёт среднюю скорость.
в) Опрос через SysCom грузит процессор до ~60%, даёт самую высокую скорость, но я с ним не разобрался до конца.
г) Прям в том же PDF про Modbus в конце 13ой странице внизу написано:
Remark:
The implementation of RTU reception driver may imply the management of a lot of interruptions due to the t1.5 and t3.5 timers. With high communication baud rates, this leads to a heavy CPU load. Consequently these two timers must be strictly respected when the baud rate is equal or lower than 19200 Bps. For baud rates greater than 19200 Bps, fixed values for the 2 timers should be used: it is recommended to use a value of 750μs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5).
Рекомендация не строгая, так как написано "should", но всё же не надо делать из меня полного дурачка. Правда, когда мне лепят фигню невпопад, я обожаю им прикидываться, да. Но это не этот случай.
В общем, тут ставлю вопрос прямо: если вам ТОЧНО известно про внутреннюю кухню планировщика опросов Modbus CodeSys v3, то я буду слушать и внимать. Если не известно - то просьба в этой теме не появляться и не сотрясать воздух.
Мне - неизвестно, и поэтому позже я буду ставить опыты, пользуясь логическим анализатором. Пока же я на практике вижу разницу между штатным и OCL.
Валенок
Неужели syscom сделана наполовину и не позволяет читать свой буфер ? Тоже вроде нет
Вот ж ты торопыга. По идее же дядька взрослый и знаешь распространённую фразу о том, где обычно нужна спешка.
Неее! Я это я что-то не то делаю и скорее всего невпопад читаю.
Про 1/3 я имел ввиду, что данные (я читаю в байтовые буфера) о двух модулях из шести читаются ровно, а в данных остальных модулей - плавающий мусор, изредка перемежающийся данными. Ну как будто я читаю, пока ответ не готов. Или как будто читаю остаток ответа от прошлого запроса.
Щас я это отложил, потом разберусь в коде, раз нахрапом не вышло сделать.
Я пробовал ставить и задержки, и буфера очищать - пока не помогло.
Меня вот интересует - у ТС прям 96 кноп без фиксации по дому раскидано ?
Это ко мне вопрос, или общественности? Мне кажется, что общественность тебе не скажет, а скажу я.
Цитирую Быкова из Интернов: "Включай логику!" ©
Вот если ты внимательно читал тему и мои ответы (в том числе и тебе и про модели модулей и про данные, и даже вчерашние о том, что с некоторых модулей мне нужна часть счётчиков импульсов), то ты мог бы проявить желание сообразить о том, что нет - не все 96 кнопок. Кнопок столько, сколько счётчиков я читаю.
Точного числа я не давал, сейчас загляну в документацию и подсчитаю. 27 штук + 17 штук + 11 штук = 55 всего.
Кто хочет повеселиться - вот я сделал фйлик всего IO. Вот входы: 52619 А вот выходы: 52620
Я так понимаю, что сейчас сделал новый наброс местной общественности для обсуждений всех ужасов. Ну, потому и файлик сделал. Изучайте, черти! =)
ЗЫ. Наверное надо подписать вот что: что если кто-то не делает документацию на проекты хотя бы на таком простом уровне, то пусть лучше промолчит.
приборист
21.12.2020, 11:27
О, кнопки с подсветкой - а что за кнопки такие, и что за подсветка?
ачуметь, на подсветку кнопок DO тратить :)
приборист А вот аж пост целый есть: https://cs-cs.net/knopki-dlya-impulsnyx-rele-i-plk
Подсветки управляются не всех кнопках, а только на специальных - вентиляторы санузлов, мастер-кнопка при входе, кнопки тёплых полов. Чтобы показать специальные режимы, например:
а) Подсветка кнопки тёплого пола: не горит, если пол выключен, мигает, если пол включен и идёт его нагрев, горит, если пол включен и нагрет до уставки. А одинарное нажатие на кнопку этот пол включает и выключает. А например двойное (быстрое) - включает его на установленное время работы (скажем, часа три погреть и выключиться).
б) Подсветка мастер-кнопки, которая гасит и потом восстанавливает весь свет как было, тоже может показывать: что свет включен, что свет полностью выключен, или что свет выключен, но есть его сохранённое предыдущее состояние и его можно вернуть как было.
melky А в промке, что ли, не так? Когда у кнопки есть подсветка и она должна мигать или светиться или не светиться, показывая работу в разных режимах.
И вообще - разве я нанимал тебя критиковать и тем более осуждать свои разработки? Что-то я у себя в базе не вижу полученных и тем более оплаченных счетов (за работу по критике) в твою сторону. А альтрузим у нас обычно наказуем.
Валенок А ты смотрел таблички? Вот скажи: внимательно смотрел? Я там IO сортировал ещё и по SSxx/COMxx и под удобство расположения модулей и проводов. А не просто так напихал как попало или потому что мне так захотелось.
Cs-Cs допустим с кнопкой "Вырубить всё" я как-то соглашусь с подсветкой. С остальным, ну это больше вопрос к вашему заказчику, если у него есть лишнее бабло на каждый канал платить за подсветочку, то флаг ему в руки. Будь я заказчиком, руки бы вырвал такому автоматизатору, при чем безплатно :)
з.ы. это не критика, а просто непонимание - зачем? больше относится к заказчику. Он поиграется этим и забудет как что мигает, уже сто раз проверено на практике. Потом звонят и спрашивают, сколько раз им и когда надо нажать на кнопку, чтобы произошло чудо...
Соглашусь с Валенком. Зная, что есть каналы, которые надо опрашивать быстро, пихать их куда попало это моветон. Их надо было собрать вместе последовательно, зная, что можно столкнуться с проблемами опроса с самого начала.
melky Я тут кучей сразу отпишусь.
1. Про сортировку каналов так, чтобы опрашивать их хитро одной кучей регистров, всё - замётано и внесено в техкарту.
2. Про кнопки с подсветкой. Ну так так и есть - ТОЛЬКО на спецфункции. На все кнопки - нет.
То есть мы НЕ делаем так, что мы нажали кнопку - у нас зажглась лампочка - подсветка в кнопке погасла. Это тогда было бы смешно и было бы на 100 кнопок 100 выходов.
3. Про проблемы с опросом. Вот это нам в самое начало темы надо. Именно в этом проекте, именно для опроса одинарного и длинного нажатий отдельно - Я НЕ ЗНАЛ, что столкнусь с проблемами, потому что до этого я сделал несколько щитов на СПК, и там с другими нажатиями проблемы успешно решил и отладил.
Если бы я заранее знал - то не было бы этой темы =)
capzap Попыток переобуться (а заодно оправдаться и прочего) не было. Просто надо ВНИМАТЕЛЬНО читать тему с самого начала. Внимательно, а не в 5 утра забежать и что-то там ляпнуть. Если ты не вычитал о "я пробовал штатный опрос, было 2000 ошибок в сутки, я от него отказался" - то это не мои проблемы. И то, что обо мне подумает чужой человек, мнение которого меня не волнует - тоже не является моими проблемами.
Ничего я про штатный планировщик не читал и ничего про то, как он работает на низком уровне, не знаю. Суть моей претензии была примерно такая:
- Ты знаешь, как он работает? Не знаешь? Тогда не надо советовать невпопад.
Никаких понтов. Просто зачем советовать то, про что не знаешь? Например ты уверен, что там очередь FIFO? Это подтверждается документами? Графичками с логического анализатора?
Если выражаться корректно, то я в силу не знания (положим) не могу отличить профанацию от точной информации. Поэтому слушаю тех, кто имеет конкретный опыт и конкретные данные или документацию. Nothing personal, just business.
capzap Сортирую мысли по тезисам.
1. С документом в руках - да, я буду самым умным среди тех, кто его не читал. Или наравне с теми, кто его прочитал и понял. Потому что есть откуда учиться.
2. Советую снова читать ВНИМАТЕЛЬНО. Я Валенку писал о том, что попробовал нахрапом накинуть функции записи и сразу же чтения, и оно работало криво. Конкретно сейчас я занимаюсь совсем другими делами и к СПК даже не буду подходить до четверга.
3. Про OSCAT. Я попробовал их диммер с ужасным кодом. Он работает ещё хуже в плане кнопок, чем предложенная krollcabs версия.
4. Не понимаю передёргиваний в плане "самый умный", "подачек". Если это началось с того, что я прямо сказал о том, что если есть знания о внутренней кухне планировщика CodeSys v3 - то тогда стоит советовать, если нет - то не надо. Если это было воспринято как издёвка или оскорбление - то тут следует искать причину этого внутри себя, так как я этого в свой текст не вкладывал, хоть он был и жёстким.
За пример - спасибо. Доберусь до компа с CodeSys - поизучаю.
эээм, ну как бы чтобы прочитать что-то, надо записать в туда что-то. шина то последовательная (если на одном интерфейсе все сидит).
Тут как бы асинхронизмом и не пахнет.
Cs-Cs напомнили тут про свои мытарства, ну как там с опросами через что нибудь? У меня 32 мс на устройство максимум на 38400 с двух слейвов по одному регистру 54929
capzap Вот стоит обсмеяться. За это время я:
* Собрал несколько простых щитов
* Купил станок лазерной резки
* Выпустил огромный пост с разными новостями (не всё про ОВЕН, но есть (https://cs-cs.net/news-spring-2021-afdd-inrush-smi-plc-sh-wiren)).
* Взял в заказ ещё щитов, чтобы денег было
* Не разобрался, как читать этот чёртов буфер. Туплю, почему во всех примерах его все кусками читают. Прям вот не понимаю принципа чтения (надеюсь что пойму).
И ща через неделю-две приступлю к опытам. В той теме, где ща ещё писали про такую же штуку, был дан совет вызывать FB опроса в OCL несколько раз. Это у меня руки чешутся тестануть на своём ПЛК сразу же. Может завтра тестану и анализатором посмотрю сразу.
На OCL время тоже самое 32мс на прибор, ну разве что я в предыдущей версии искусственно добавлял некоторое время таймерами. Единственный момент, разработчики постарались, "развернули" байты, поэтому REAL не собирался из с копированного кода постом выше. И очень бибка чувствительна к ошибкам, может быть потому что я уменьшил время таймаута в 10 раз
Мне-то на REAL пофиг, это не страшно. У меня там одни WORD слошные - счётчики импульсов и битовые маски.
Может завтра врублю второй комп с CDS и затестю всё.
capzap Просьба записать меня в махровейшего ужасного идиота.
Посмотрел оба примера, и вот что я скажу: я - идиот, но я не могу понять ни одной строчки кода. Особенно когда там куча магических чисел и ни одного комментария, а на STATE хоть и создан ENUM, всё равно пробегают конструкции типа mSTATE := mSTATE +1;
А ещё круто когда в начале кода пишется mSTATE := FIRST; (типа азяли из Enum), а потом в Case идут магические числа...
Это УЖАСНО! Так программировать - это позорно, потому что (если брать пример из ENUM), то никто не даёт гарантии того, что значения там будут идти последовательно. А значит всякие +1 не прокатят.
Ещё я хочу придраться к функции CRC. Что? Это первая найденная функция из инета? А о том, что CRC табличным методом считается быстрее (при условии, что у нас не 8-битный микроконтроллер, да и то у меня даже там памяти на 1024 байта таблицы хватило) - это мы не знаем?
Не хочется переходить на личности, но перейду. Вот в ПЛК capzap точно мнее меня. А в стиле написания кода - УЖАСНО.
В общем, про CommLib я НЕ ПОНЯЛ. Больше всего я не понимаю, как оно вообще работает.
Буду разбираться сам. По нормальному коду.
Так, подниму немного тему. У меня утро понедельника, хех, плодовитое.
Отписываюсь по паре пунктов:
1. С помощью Евгения Кислова (который навадал мне по мозгам и пояснил, как работает SysComLib) запустил опрос модулей IO под СПК.
Пока замеров логическим анализатором НЕ проводил; доделываю дургие проекты, чтобы заработать денег (был же простой из-за сдыхания ПЛК в другом щите (https://owen.ru/forum/showthread.php?t=35059)).
На глаз работает в половину скорости CodeSys v2.3, но при этом раза в два быстрее, чем OCL/конфигурация ПЛК.
2. Проистерил, разозлился и (под зацикленную Linkin Park - Faint) при помощи конечного автомата (огромное спасибо за упоминание про него от krollcbas) написал крутой диммер для CodeSys v2.3, где опрос IO идёт быстрее. Диммер работает по потенциалу входа (True/False) и умеет плавно зажигаться и гаснуть, включаться и выключаться по одночному нажатию и регулироваться по длинному, имеет настройку минимальной яркости (для некоторых типов ламп надо их врубать с яркости не ниже хх%), имеет настройку яркости, на которую он включится, если программу первый раз залили в ПЛК. Умеет понимать команды центрального управления (погасить всё / зажечь как было).
Код замутил так, что конечный автомат обработки нажатий стоит отдельно от кода диммера, чтобы обработку кнопок можно было копипастить куда-то ещё.
56465 56466 56467
Буду портировать его на CDS 3.5, и посмотрю, что получится из этого. И вот после этого сделаю все замеры и отпишусь.
Кажись, дело движется чуточку. Конечные автоматы рулят, и как я про них забыл - я даже не представляю.
я так понял что платят за буквы, больше буков - больше денек?
Вот какой ты вредный! =) Пару бы тебе, пару... чтоб было два валенка, а не одинокий и вредный же...
Кажется, за количество строк кода платили там, где оставалось армейское или советско-бумажное наследие в головах. Ну, типа, чтобы листов в дипломной было побольше. Для солидности. Нормальные люди с таким наследием не работают.
Валенок Я не знаю, что это за мужик и может ли он быть ненормальным для какого-то другого мужика.
Нетушки. Там не i++;, а пояснение: что после всяких условий и выборов надо прибавить яркость диммера на шаг (а не на единицу). Смысловая нагрузка.
i := i + 1; (*увиличиваем переменную i на единицу*)
найдите хотя бы одно отличие
Нашёл два:
а) увЕличиваем
б) не на единицу, а на шаг. Шаг задан где-то, и он не равен единице.
ну при увеличении не всегда можно использовать i++, можно и i+шаг
и даже в циклах это можно делать.
а-ха, я понял над чем Валенок стебется.... вариант индуского кода :)
Чё за индусский код-то?
Мне хоть расскажите, я стебаться сам буду. А то я не в курсе и думаю, что вы все - диванные эксперты по коду, которые переменные толком назвать не умеют.
Валенок А ты всё читал? Или так забежал?
Я написал, что автомат там - ДО этого. Он окучивает работу с кнопкой.
А дальше отдельно есть логика диммера. Которую в виде конечного автомата я и не писал.
Чё за индусский код-то?
Мне хоть расскажите, я стебаться сам буду. А то я не в курсе и думаю, что вы все - диванные эксперты по коду, которые переменные толком назвать не умеют.
Могу ошибаться, но, лично мне, не нравятся граничные проверки.
Могу ошибаться, но, лично мне, не нравятся граничные проверки.
Без них никуда же: текущее значение яркости и шаг его изменения может быть любым. И может быть такой случай, когда
capzap Всё равно мне непонятно, над чем стебутся.
Я воспринимаю это с той стороны, что когда я помощи просил - то 2/3 начало пихать примеры под ПРку и ПЛК110, которые мне тогда не годились. А другая треть - пихала примеры без комментариев и пояснений. И с кривыми именами переменных. В которых я мало что понимал, потому что у меня были проблемы с алгоримизацией в том числе.
И я вижу, что те, кто стебутся, на форуме сами мало что выкладывают, втом числе и понятного для новичков (где-то и я полный ноль или тупенький новичок). Из тех примеров, которые я использовал с форума, только пример архивации на флешку в CSV-файл был отлично документирован и прокомментирован. Каждой строчкой.
Про многобукв. Если это пишут дети инстаграмма, про который в лекциях SEO рассказывают так: "Не бойтесь писать посты длиннее 1000 символов", то зачем мне их слушать?
Я по форуму вижу тренды на:
а) Диванных экспертов (которые заполнили всю тему про ПЛК110 со своими рассказнями про блоки питания);
б) Умных жадин. Это те, которые бросают фразу вида "Ха! Не так ты делаешь! И такие вот идут в автоматизацию!", но не хотят или даже не могут пояснить подробно.
Всё это я проходил на своём рабочем сайте, которому идёт 11ый год. Диванных экспертов я выгонял, а умным жадиной не был: я ругал, и потом объяснял почему.
Касательно картинок. Валенок стебался, кажется, не над этим. Он стебался над тем, что значение прибавляется, и что про это написано.
А тут прошу пояснить про границы. Только не в стиле умной жадины пожалуйста. Когда я это писал, у меня в голове была чёткая логика:
а) Там, где IF - это ОПЕРАЦИЯ. Изменение яркости по шагам, пока нажата кнопка. И мне надо решить: меняю я яркость, или она дошла до максимума и её менять не надо.
А так как:
* Шаг изменения задаётся в настройках.
* Яркость диммера задаётся (будет задаваться) на СПК слайдером на экране с точностью 1%
Может получиться так, что мы к 99% прибавляем шаг, равный 3%, то на шаге прибавления мы можем получить не 100%, а 102%.
Вот поэтому я написал ограничения по краям. На каждом ШАГЕ изменения яркости.
б) Там, где MAX - это ВКЛЮЧЕНИЕ. Там однократно задаётся начальная яркость диммера при включении, так как она может быть задана двумя параметрами:
* Минимальная техническая Config.DimLimitMin - я могу настроить диммер так, что меньше 5% диммер даже не опускается. Например для LED-ленты, которая отключается по питанию 230V и её гасят аппаратно. От диммера в этом случае требуется не дать загнать яркость ленты в ноль, чтобы исключить ситуации, когда питание на ленту подано, а она "не горит".
* Минимальная яркость включения (Config.DimStartMin) - та яркость, на которую диммер встаёт при операции его включения. Это задумано для LED-ламп, некоторые из которых могут корректно включиться только при определённой яркости на момент включения. Условно, включать надо на 70%, а потом регулировать можно хоть до 20% минимума. Такое бывает, и ещё на CCFL-лампах было.
Короче, эксперты (?). За год активничания на форуме я многих из вас хорошо узнал. И скажу следующее:
1. Оправдываться мне не за что.
2. Критикуя логику - объясняйте, что не так. На пустую критику без пояснений (где-то - пояснений для новичков) я отвечать не буду.
3. Критику по коду (комментариям, стилю написания и индусскости) я буду принимать от тех, кто публично покажет свой код размером не менее чем в один экран. Без этого я слушать никого не буду. Как я уже говорил, я учусь только у тех, кто делает лучше меня.
4. Конкретно capzap. Прежде чем учить меня код писать, просьба научиться писать на русском языке. Я имею ввиду "научиться писать сложноподчинённые предложения и грамотно (или хотя бы вообще начать) расставлять знаки препинания".
Всё.
Без них никуда же: текущее значение яркости и шаг его изменения может быть любым.
Я не про их наличие
А тут прошу пояснить про границы. Только не в стиле умной жадины пожалуйста. Когда я это писал, у меня в голове была чёткая логика:
а) Там, где IF - это ОПЕРАЦИЯ. Изменение яркости по шагам, пока нажата кнопка. И мне надо решить: меняю я яркость, или она дошла до максимума и её менять не надо.
А так как:
* Шаг изменения задаётся в настройках.
* Яркость диммера задаётся (будет задаваться) на СПК слайдером на экране с точностью 1%
Может получиться так, что мы к 99% прибавляем шаг, равный 3%, то на шаге прибавления мы можем получить не 100%, а 102%.
Вот поэтому я написал ограничения по краям. На каждом ШАГЕ изменения яркости.
А Вы уверены, что прибавив 3 к 99 на выходе Вы получите 100? (см. третий скрин строки 38-42)
И нижнюю границу, на мой взгляд можно проверять проще:
1. Сдвинув 0 вправо, например, на 100 и тогда сравнивать Value c 100
2. Привести результат к значению со знаком и сравнивать с 0.
saii
Туплю. Что тут не так? Если у меня Value равно 99, то если я прибавлю Config.DimValStep * 2 (который может быть чем угодно) - то получу Value больше 100.
IF (Value < Config.DimLimitMax) THEN
Value := Value + Config.DimValStep * 2; (* Прибавляем значение на шаг *)
ELSE
Value := Config.DimLimitMax; (* Уравниваем значение с максимумом, ограничивая его сверху *)
END_IF
Value - это сразу же выход диммера. Напрямую, выход FB. Поэтому я и не хотел его фигачить со знаком, а хотел чтобы он был WORD - чтобы сразу в регистры его можно было пихать без преобразований типов. Поэтому написал муть с проверкой на отрицательные значения в дополнительном коде.
Туплю. Что тут не так? Если у меня Value равно 99, то если я прибавлю Config.DimValStep * 2 (который может быть чем угодно) - то получу Value больше 100.
Согласен
IF (Value < Config.DimLimitMax) THEN
Value := Value + Config.DimValStep * 2; (* Прибавляем значение на шаг *)
ELSE
Value := Config.DimLimitMax; (* Уравниваем значение с максимумом, ограничивая его сверху *)
END_IF
При исходных данных чему будет равно Value по завершению этого куска кода?
Value - это сразу же выход диммера. Напрямую, выход FB. Поэтому я и не хотел его фигачить со знаком, а хотел чтобы он был WORD - чтобы сразу в регистры его можно было пихать без преобразований типов. Поэтому написал муть с проверкой на отрицательные значения в дополнительном коде.
А я и не предлагаю преобразовывать Value, а преобразовать результат операции Value - Step в значение со знаком и результат сравнивать с нулем. Либо, как вариант:
if Value + 100 - Step < 100 then ...
Value := MAX(Config.DimLimitMax,Value + Config.DimValStep * 2);
разве будет хуже? Меньше кода -> меньше потенциальных ошибок, меньше комментариев
Здесь нужен MIN, и разницы между IF и MAX/MIN принципиальной нет, т.к. MAX/MIN это те же IFы.
Cs-Cs Индусский код, это когда людям платят за количество строк кода. погуглите.
А Валенок стебется над тем, что программисту объяснять понятие IF THEN в принципе глупо, а не программист туда просто и не полезет.
Комменты надо писать по самому внутреннему коду функции, а не по прописным истинам типа IF
Sergey666
10.08.2021, 13:05
Cs-Cs Индусский код, это когда людям платят за количество строк кода. погуглите.
А Валенок стебется над тем, что программисту объяснять понятие IF THEN в принципе глупо, а не программист туда просто и не полезет.
Комменты надо писать по самому внутреннему коду функции, а не по прописным истинам типа IF
Индусский код- наиболее хитровывернутый, неочевидный вариант решения задачи. Примеры откуда-то из ... Ну и наверное построчная оплата таки да...
Примеры индусского кода
Пример № 1 (C#)uint i;
...
if (i.ToString().Length == 1)
{
...
}
Не сразу можно понять, что в этом коде просто-напросто выполняется проверка 0 <=i <10. Алгоритм достаточно прост: выполняется преобразование i в строку, после чего вычисляется её длина. Если число больше 9, то его десятичная запись содержит больше одного символа. Поскольку отрицательные числа переменная типа uint содержать не может, то проверку успешно проходят лишь числа от 0 до 9. Строка же, полученная из отрицательного числа, состоит как минимум из знака '-' и одной цифры, поэтому проверка справедлива и для знаковых целых (int). Алгоритм ресурсоёмок, неочевиден, и не поддаётся сопровождению даже теоретически.
А вот и про комментарии:
5. Комментарии с фанатизмом
Комментируйте все подряд, кроме самых не очевидных кусков (см пример 1.) Если вы еще не достигли полного просветления и в вашей индусской программе случайно осталось две-три функции — создайте «шаблон описания функции», включите туда умные слова-разделы, в разделе «Description» перечислите еще раз все что было написано выше, но развернуто. Особенно эффект умножения строк кода проявляется с функциями типа «FSerror()» из примера выше.
даже пустой такая шапка смотрится значимо
/************************************************** ************************
Function:
void func (void)
Summary:
Does a hard work
Conditions:
This function should not be called by the user
Input:
None
Return Values:
None
Side Effects:
None
Description:
This function will do <a hard work>, with <none> input parameter....
Remarks:
Optimize code later
************************************************** ************************/
Но есть еще и китайский код, очень востребован, а иногда (часто) просто необходим в АСУ-ТП
Kитайский код — стиль написания программ, нарушающий принцип НПС («Не повторяй себя»). Китайский подход к программированию требует эксплицитного отказа от циклов, локальных переменных, любых процедур и условных выражений, а также использования технологии copy-and-paste чуть менее, чем везде (http://nouveau.lurkmore.net/%D0%A7%D1%83%D1%82%D1%8C_%D0%B1%D0%BE%D0%BB%D0%B5% D0%B5,_%D1%87%D0%B5%D0%BC_%D0%BD%D0%B0%D0%BF%D0%BE %D0%BB%D0%BE%D0%B2%D0%B8%D0%BD%D1%83). Такой подход точно увеличивает объём исходников и может увеличить производительность (ведь пропускаются такты на джамповые команды).
[<collapsible-collapse> (http://nouveau.lurkmore.net/%D0%98%D0%BD%D0%B4%D1%83%D1%81%D1%81%D0%BA%D0%B8%D 0%B9_%D0%BA%D0%BE%D0%B4#)] Возьмём, к примеру, такой кусочек программы на C:
int arr[10];
int i;
for (i = 0; i < 10; i++)
{
arr = 0;
}
Который, кстати, вполне мог бы выглядеть и так:
int arr[10] = {0};
Типичный программист в китайском стиле напишет это так:
int a0 = 0;
int a1 = 0;
int a2 = 0;
int a3 = 0;
int a4 = 0;
int a5 = 0;
int a6 = 0;
int a7 = 0;
int a8 = 0;
int a9 = 0;
и в дальнейшем будет использовать a0, a1, a2, a3, a4 и т.д. Например, вместо прекрасного:
if (x < 10) arr[x] = x;
будет:
if (x == 0)
{
a0 = x;
}
else if (x == 1)
{
a1 = x;
}
else if (x == 2)
{
...
}
Пример № 1, приведённый выше (http://nouveau.lurkmore.net/%D0%98%D0%BD%D0%B4%D1%83%D1%81%D1%81%D0%BA%D0%B8%D 0%B9_%D0%BA%D0%BE%D0%B4#.D0.9F.D1.80.D0.B8.D0.BC.D 0.B5.D1.80.D1.8B_.D0.B8.D0.BD.D0.B4.D1.83.D1.81.D1 .81.D0.BA.D0.BE.D0.B3.D0.BE_.D0.BA.D0.BE.D0.B4.D0. B0):
uint i;
...
if (i.ToString().Length == 1)
{
...
}
приверженец китайской методы перепишет так:
if (i == 0 || i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6 || i == 7 || i == 8 || i == 9)
{
[I]// произвести ещё одну бессмысленную операцию
}
В то время как суть индусского метода заключается в как можно более полном затуманивании предназначения программного продукта, китайский код зачастую поражает и даже отупляет простотой и брутальной прямолинейностью подхода, что характерно для китайской инженерии в целом. С другой стороны, нельзя не отметить, что подобные технологии позволяют максимальным образом трудоустроить население и приводят к сокрушительным победам в социалистических соревнованиях по количеству написанных строчек.
http://nouveau.lurkmore.net/%D0%98%D0%BD%D0%B4%D1%83%D1%81%D1%81%D0%BA%D0%B8%D 0%B9_%D0%BA%D0%BE%D0%B4
saii
Привет!
Ну так чем всё закончилось?!
Прочитал всю тему)) Вообще говоря, работоспособность модбаса в панельном ПК судя по твоим постам не обрадовала.
По существу:
1. Нашёл инфу, как работает планировщик?
2. Планировщик делает асинхронные вызовы (запросы) и, возможно, из-за этого иногда "натыкается" "запрос" на "ответ"? 2000 ошибок непозволительно много. 1 - нормально. 0 - идеально;).
3. Выходит, кроме как "вручную" рисовать запросы\ответы более-менее вменяемого механизма опроса сейчас для СПК нет? Интересно, для МК210 будет всё также?
4. 60% загрузки ПЛК только на опрос I\O?!??! Как по мне... это прям очень, очень много. Тоже решаю, какой ПЛК бы поставил себе в дом... Вот провести бы нагрузочное сравнительное тестирование в сравнении с тем же сименс S7-1200..
5. Так как сейчас у тебя устроен поллинг? Запрос-Ответ, Запрос-Ответ?
И да... Планировщик... Не разыта ли здесь собака как раз в том, что насколько я понимаю (не спец по кодесис, правда) - там всё в линуксе? Просто в ПК110 стоит некая RT-оболочка, позволяющая выполнять циклы "жестко", а планировщик - это уже больше из области управления ресурсами\контекстом, т.е. ближе к операционной системе, чем системам с "жестким циклом", тем это и чревато?
Teemon Двумя вещами:
а) SysCom
б) Нормально написанным конечным автоматом для диммера.
Ща портировал на CDS v3.5, и при опросе 9 модулей IO всё пашет. Пока ещё тестирую.
Про планировщик, про прочее - позже будут посты. Сильно позже.
Да, запросы составляю вручную. Код примерно такой злой:
IF (bPortR1Open = TRUE) THEN
CASE iMBReqStateR1 OF
iReqR1W2Msk: //ОПРОС МОДУЛЯ W1 - Маска Входов
fbMbReqW2Msk(
bEnable:= TRUE,
hPort:= hPortR1,
pCmdBuffer:= ADR(pBuffReqReadDIMaskW2),
pCmdBufferLen:= SIZEOF(pBuffReqReadDIMaskW2),
pRcvBuffer:= ADR(bfRecieveBuffer),
pRcvBytesNeed:= wBuffAnswReadDIMaskW2,
bCheckCRC:= TRUE,
);
IF (fbMbReqW2Msk.bComplete = TRUE) THEN //Парсим данные в DWORD маски входов, если запрос завершился успешно
iMBReqStateR1 := iReqR1W2Cnt; //Идём на следующий шаг
iomW2DIMask := BYTE_TO_DWORD(bfRecieveBuffer[6]) //Входы 1-8
OR SHL(BYTE_TO_DWORD(bfRecieveBuffer[5]), 8*1) //Входы 9-16
OR SHL(BYTE_TO_DWORD(bfRecieveBuffer[4]), 8*2) //Входы 17-24
OR SHL(BYTE_TO_DWORD(bfRecieveBuffer[3]), 8*3); //Входы 25-32
END_IF
... ... ... ... ...
IF (bPortR2Open = TRUE) THEN
CASE iMBReqStateR2 OF
iReqR2W5Out: //ОПРОС МОДУЛЯ W5 - Маска выходов !!
bfSendBuffer[0] := 20; //Адрес
bfSendBuffer[1] := 16#10; //Команда
bfSendBuffer[2] := 16#00; //Старший (начальный адрес регистра)
bfSendBuffer[3] := 16#61; //Младший (начальный адрес регистра)
bfSendBuffer[4] := 16#00; //Старший (число регистров)
bfSendBuffer[5] := 16#02; //Младший (число регистров)
bfSendBuffer[6] := 4; //Число байт данных (далее)
bfSendBuffer[7] := DWORD_TO_BYTE(SHR(wBitMask32W5, 8*3)); //16#FF; //Выходы 25-32
bfSendBuffer[8] := DWORD_TO_BYTE(SHR(wBitMask32W5, 8*2)); //16#FF; //Выходы 17-24
bfSendBuffer[9] := DWORD_TO_BYTE(SHR(wBitMask32W5, 8*1));// 16#FF; //Выходы 9-16
bfSendBuffer[10]:= DWORD_TO_BYTE(SHR(wBitMask32W5, 8*0));// 16#FF; //Выходы 1-8
CSMBAddBuffCRC(ADR(bfSendBuffer), SIZEOF(bfSendBuffer), 11);
fbMbReqW5(
bEnable:= TRUE,
hPort:= hPortR2,
pCmdBuffer:= ADR(bfSendBuffer),
pCmdBufferLen:= 13,
pRcvBuffer:= ADR(bfRecieveBuffer),
pRcvBytesNeed:= wBuffAnswWriteDOMaskW5,
bCheckCRC:= TRUE,
);
IF (fbMbReqW5.bComplete = TRUE) THEN
iMBReqStateR2 := iReqR2W6Out;
END_IF
Teemon Двумя вещами:
О, ну по коду ничего страшного не вижу, на S7-1200 тоже так писал, всё "ручками". Зато работало как часы.
ЦРЦ драйвер сам считает или нужно тоже руками считать?
Кстати, в модбасе неизбжено (но тут уже что уж поделать) - если у меня будет ошибка опроса\таймаут - и в этот момент я жму кнопку - я потеряю её нажатие... Но по идее в шкафу ошибок должно быть очень, очень мало. Что говорит статистика?
Как в итоге автомат работает, одиночное, длительное, двойное нажатие как разделяешь?
Какой диммер?
Teemon Не, драйвер только гоняет байты. Причём все равно какие и сколько. Тупо выплёвывает буфер в порт, и всё. Или читает из полрта в буфер столько, сколько скажешь. Поэтому всё ручками. Там у меня вон функция даже есть - "CSMBAddBuffCRC" =))
Статистику ещё не причесал со старого формата опроса. Визуально - летает всё, ошибок нет.
Сливаю идею: одинарные/двойные нажатия кнопок у ОВЕНа круто ловить по счётчикам импульсов модулей IO. Поэтому даже если ошибка будет - то при следующем опросе, который быстро происходит, нажатие отловится. Если же ошибка длится дольше XX времени - то логика обработки кнопок перезапускается, и тогда нажатие потеряется. Чтобы не было такого, что через полчаса модуль подключили - и пошли нажатия, которые уже не нужны.
Автомат работает как обычный конечный, как подсказывал Krollcbas в начале темы: считаю условные тики (tick) и по их числу перехожу или в состояние "Single" или в состояние "Long", блокируя остальную логику.
Что значит - "какой диммер"? Ну, диммер. Как обычно он и должен работать.
Teemon Не, драйвер только гоняет байты. Причём все равно какие и сколько. Тупо выплёвывает буфер в порт, и всё. Или читает из полрта в буфер столько, сколько скажешь. Поэтому всё ручками. Там у меня вон функция даже есть - "CSMBAddBuffCRC" =))
Статистику ещё не причесал со старого формата опроса. Визуально - летает всё, ошибок нет.
Сливаю идею: одинарные/двойные нажатия кнопок у ОВЕНа круто ловить по счётчикам импульсов модулей IO. Поэтому даже если ошибка будет - то при следующем опросе, который быстро происходит, нажатие отловится. Если же ошибка длится дольше XX времени - то логика обработки кнопок перезапускается, и тогда нажатие потеряется. Чтобы не было такого, что через полчаса модуль подключили - и пошли нажатия, которые уже не нужны.
Автомат работает как обычный конечный, как подсказывал Krollcbas в начале темы: считаю условные тики (tick) и по их числу перехожу или в состояние "Single" или в состояние "Long", блокируя остальную логику.
Что значит - "какой диммер"? Ну, диммер. Как обычно он и должен работать.
Одинарное\Двойное по счётчику это понятно. Кстати, при переполнении счётчика прога не даст сбой?)
А как увязываешь счетчик нажатий и передний фронт для оценки длительного нажатия? Если есть передний фронт - он должен блокировать Single до тех пор, пока не истечет таймер Long или не будет задний фронт?
В любом случае, Single будет работать по заднему фронту... Тоже сколько раз думал об этом. Особой проблемы, мне кажется, нет. В конце концов, в Винде кнопки рабтают по заднему фронту и проблемы особой нет) Потому что "клик" - это цикл нажатия и отпускания))
А про диммер - я думал у тебя какой-то модбас диммер. А у тебя - полностью софтварный, с АО.
Как пред-итог: родные либы для модбаса (кроме планировщика) - работают? или всё таки кривоваты? Там выше по тексту было где-то упоминание, что не стоило делать вызовы на чтение до получение ответа или я не так понял?..
Интересно...
https://ftp.owen.ru/CoDeSys3/98_Books/CodesysTaskManagment.pdf
Таким образом, если в проекте есть задача с адекватным временем цикла (например, для
протокола Modbus – 10…20 мс) – то описанные выше настройки задач всех Modbus-компонентов
можно оставить в значениях по умолчанию, и при этом никаких проблем с обменом не возникнет.
С другой стороны, если пользователь, например, увеличит время задачи MainTask до 100
мс (и при этом в проекте не будет задач с меньшим временем цикла) – то обмен будет работать
некорректно (с точки зрения пользователя опрос будет медленным, часть ответов slave-устройств
будет пропущена).
" (с точки зрения пользователя опрос будет медленным, часть ответов slave-устройств
будет пропущена)." - как это " часть ответов будет пропущена"??? Я так понимаю, увеличение времени цикла определяет просто частоту посылок запросов\обработки ответов? Что происходит на последовательном порту при приеме данных? Если это аппаратный модуль, там обычно буфер, куда всё и складывается... В кодесис по идее тоже при приёме данных они "сами" должны ложиться в какой-то буфер, не?.. У Сименса модули последовательной связи вроде этим и занимаются. А тут как? Типа если вызвал задачу раз в 100мсек, а где-то посередине был приём, который твоя программа пропустила и не сложила в буфер приема??.. Кто может разжевать.
Страница 24:
У внимательных пользователей может возникнуть вопрос – а как именно компоненты
Modbus обрабатываются в контексте вызывающей их задачи? Точное описание работы
коммуникационных драйверов отсутствует, но в целом можно считать, что операции, связанные с
обменом (например, чтение/запись из COM-порта) выполняются асинхронно по отношению к
задаче цикла шины. В задаче CODESYS происходит только синхронизация буферов драйверов с
каналами компонентов. В справке CODESYS приводится следующий рисунок, который поясняет
принцип работы драйверов:
По идее, задача обмена данными имеет приоритет над остальными, а то я думал, что может быть, HMI и другие задачи грузили контроллер в твоем случае и "прерывали" задачу обмена?..
CS, не пробовал применять тип задачи - Тип задач «Событие» для "отлова" изменения входного сигнала на модуле DI? Или это неприменимо для данного случая?..
CS, а чем конкретно этот пример
https://ftp.owen.ru/CoDeSys3/11_Documentation/03_3.5.11.5/CDSv3.5_Modbus_v2.0.pdf
плохо работает? И почему "самописное" складывание данных в порт\из порта работате лучше\быстрее? Это норма?)
Мне НЕ нравятся такие подробные беспардонные расспросы. Как владелец своего блога я умею отличать вежливые и подробные вопросы от тех, кто хочет сразу, всё и на блюдечке. К таким ситуациям у меня идиосинкразия. Острая.
Будет пост - вот там и будет всё показано и рассказано.
Да как по твою душу угодно будет. Вопрос то был простой по своей сути - разобраться удалось где и что не работает или нет
Почему-то эта суть растянулась на кучу сообщений...
Вот я ДОДЕЛАЮ - и выложу сюда видоса кусок. Ты же на тему подписан? Не просто так забежал?
Вот выложу - ты увидишь. Скорость опроса меня втащила: на 9 модулях летает так, как на штатном планировщике на пяти модулях не летало.
Sergey666
28.09.2021, 22:45
Мне НЕ нравятся такие подробные беспардонные расспросы. Как владелец своего блога я умею отличать вежливые и подробные вопросы от тех, кто хочет сразу, всё и на блюдечке. К таким ситуациям у меня идиосинкразия. Острая.
Будет пост - вот там и будет всё показано и рассказано.
Ядрена вошь! От Вики-
Идиосинкрази́я (от греч. (https://ru.wikipedia.org/wiki/%D0%93%D1%80%D0%B5%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D 0%B9_%D1%8F%D0%B7%D1%8B%D0%BA) ίδιος — своеобразный, особый, необычайный и σύγκρασις — смешение) — генетически обусловленная реакция, возникающая у некоторых людей в ответ на определённые неспецифические (в отличие от аллергии (https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%BB%D0%B5%D1%80%D0%B3%D0%B8%D1%8F)) раздражители (https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D0%B4%D1%80%D0%B0%D0%B6%D0%B8%D 1%82%D0%B5%D0%BB%D1%8C). В основе идиосинкразии лежит врождённая повышенная реактивность и чувствительность к определённым раздражителям или реакциям, возникающая в организме (https://ru.wikipedia.org/wiki/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%BC) в результате повторных слабых воздействий некоторых веществ и не сопровождающаяся выработкой антител (https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8%D1%82%D0%B5%D0%BB%D0%BE).
В настоящее время термин используется редко; его основное современное значение близко к понятию ферментопатия (https://ru.wikipedia.org/wiki/%D0%A4%D0%B5%D1%80%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D 0%BF%D0%B0%D1%82%D0%B8%D1%8F), так как болезненные проявления часто связаны с недостаточностью определённых звеньев обмена веществ (https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%BC%D0%B5%D0%BD_%D0%B2%D0%B5%D1%89% D0%B5%D1%81%D1%82%D0%B2) в условиях той или иной внешней нагрузки.
Что? Прям подавился?
Sergey666
28.09.2021, 22:51
не летало.
Опрос через конфигуратор модулей Seneca Z-SG (получение одного FLOATa) работает быстрее чем то-же самое через библиотеку Мodbus.
Все относительно.
Опрос через конфигуратор модулей Seneca Z-SG (получение одного FLOATa) работает быстрее чем то-же самое через библиотеку Мodbus.
Все относительно.
Вот хотелось бы разобраться, где же собака зарыта)
Новости! Заработало?!
Ну, УРА! ЗАРАБОТАЛ мой диммер. Ща в проекте задействовано все 5 интерфейсов СПК (или 6, если считать LAN и Modbus TCP).
SysCom рулит аццки, буду его теперь использовать.
Снял для форума и заказчика видос (пролежит месяц-два, потом удалю): https://cs-cs.net/ExxChange/SPK107-Full-RS-TestsOK.avi
Диммер работает, на кнопки реагирует. Всё. Теперь надо писать основную прогу и интерфейс!
Сегодня ещё добавилось IO на щит санузла. И вообще - сейчас к щиту подключено ВСЁ IO, и все Modbus-устройства полным комплектом (датчики, тёплые полы, внешние модули IO).
Новости! Заработало?!
Ну, УРА! ЗАРАБОТАЛ мой диммер. Ща в проекте задействовано все 5 интерфейсов СПК (или 6, если считать LAN и Modbus TCP).
SysCom рулит аццки, буду его теперь использовать.
Снял для форума и заказчика видос (пролежит месяц-два, потом удалю): https://cs-cs.net/ExxChange/SPK107-Full-RS-TestsOK.avi
Диммер работает, на кнопки реагирует. Всё. Теперь надо писать основную прогу и интерфейс!
Сегодня ещё добавилось IO на щит санузла. И вообще - сейчас к щиту подключено ВСЁ IO, и все Modbus-устройства полным комплектом (датчики, тёплые полы, внешние модули IO).
Посмотрел видео - нормик! Самое ОК что с модбасом на большой скорости получилось.
Все 5 интерфейсов по модбасу опрашиваются через ПЛК? Как он себя чувствует при этом, скок ресурсов занято, скок свободно? Я думал, что его пара интерфейсов нормально будут так грузить, а тут вон оно как.
Напомни модель ПЛК.
Чуть-чуть оффтопа: планирую при наличии главного ПЛК избавиться от покомнатных термостатов - зачем? Делать термостат сразу в ПЛК, а интерфейс - уже где удобнее. Что думаешь?
Teemon
Что думаешь? Я нетерпеим не тем, кто спешит, скачет галопом по европам. Тебе стоит почитать мой блог внимательно, посмотреть разные проекты и примеры работ, и понять, какие ПЛК я использую, и что я уже делал всё без термостатов, и это работает.
Из того, на что можно ответить (остальное и так понятно) - только о загрузке проца. Она около 60%, это для СПК норма.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot