Логика: Распознать отдельно короткое и отдельно длинное нажатия (CodeSys v3)

[Cs-Cs]

melky Я не уверен, что хочу разделять. Одно дело, если бы там только свет был. А там может быть так, что на датчике присутствия и лампы будут висеть, и батареи, и шторы и ещё тёплый пол. И как тогда разделять?
Ещё раз напоминаю: около 100 входов и 100 выходов у меня ща - норма. К февралю буду собирать щит, где 100 входов и 200 выходов. И вот как это по ПЛК или ПРкам разбивать? Мне это неудобно.
Ща меня CodeSys v3 пока устраивает вовсю. Я научился работать. Дальше хочу пробовать кнопки от KNX брать, как krollcbas делает.

[melky]

Да молча разделять. ПЛК на много входов-выходов сколько заменит модулей MX ? Берете такой ПЛК, пишите в нем логику кнопок и включений и сетевой обмен с головным ПЛК (СПК) для управления по сети или с экрана. Для головного ПЛК(СПК) он как модуль ввода вывода.

Если бы в Конфигурации ПЛК можно бы было делать опрос по сценарию, было бы проще, но представителям Овен наверное это не знакомо. Пример. 2 модуля участвуют в быстрых процессах, остальные в медленных, всего ну скажем 8 модулей.
1,2,3-1,2,4-1,2,5-1,2,6-1,2,7-1,2,8- и снова 1,2,3 Через библиотеки так наверное сделать можно, вот почему нельзя так же настроить конфигуратор ????

[Cs-Cs]

А опыт есть? Конкретный? Один же фиг, СПК будет этот "модуль" опрашивать так же, как и модули IO.

Наверное? Блин, вот тут я бы попросил или конкретики, или не сетовать. Я такое сделать могу, я с библиотеками разобрался специально под это дело.

[melky]

Какой опыт вы имеете ввиду ? Это же принципы построения систем, а для большого дома при выбранной системе (Овен) сам бог велел.
Все быстрые процессы скинуть на другой мозг, между ним и основным мозгом сетевое взаимодействие. СПК будет его читать периодически для отображения на экране или WEB визуализации. Команды от экрана и визуализации должны проходить сразу в подчиненный ПЛК. Но сам ПЛК, на который вешаете быстрые процессы работает в цикле, к тому же, если он занимается только своими вх/вых то этот цикл минимален.



Я на ПЛК такое не делал, только на Scada системе. Если мне надо контролировать счетчик электроэнергии, он стоит в циклическом опросе, если мне надо из ПР читать или писать часть переменных постоянно, то забиваю эти переменные последовательно и одним групповым запросом так же читаю в цикле. Все переменные для настроек делаю дальше и можно тоже одним групповым запросом читать, но скажем раз в 30 сек а то и реже. Но никто же не говорит, что то же самое нельзя сделать и на ПЛК ? Разделите запросы и модули и уйдите от конфигуратора, раз у вас есть быстрые процессы.
Конфигуратор же выполняет опрос строго последовательно модуль за модулем, отсюда у вас и задержки, но наверняка часть ваших модулей можно читать реже.

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

[Cs-Cs]

А, мы про разное.
Так то, что ты описал - это понятно. Скажем, у нас есть щит IPM™, щит автоматики бассеина, мелкие модули IO для сбора данных по коллекторным шкафам отопления - и мы с них собираем данные на уровне "О, мозг в щите IPM™ запустил генератор, сообщает что топлива хватит на 10 часов работы".
Это мне всё ясно и понятно.

А у нас речь ща идёт о том, что как раз этот самый один мозг, который должен рулить светом и простой автоматикой, с этим справляется с некоторыми тормозами.
А если разбивать его на отдельные мелкие части - так центральному ПЛК достанется больше обмена. И что этот обмен будет с модулями IO, что с ПРками - один фиг.
Причём с ПРками обмена будет в два раза больше: из модуля IO я читаю состояние входов и пишу в выходы, а в ПРке мне надо будет читать состояние света, записывать новое состояние света и ещё и делать это по флагу, чтобы UI с аппаратным состояние света не конфликтовал.
Так что я не хочу это ещё больше разделять.

КОРОЧЕ. Просто CodeSys v3 МДЛЕННЕНЕ раз в ДЕСЯТЬ, чем ПРки и чем CodeSys v2. Вот с этом - ПРОБЛЕМЫ. Когда там висит один-два модуля IO - то нормально. А когда десять (по 32 канала) - вот тогда уже будет весело.

[melky]

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

з.ы. если кнопками рулит ПР например, то все двойные нажатия, короткие, длинные контролирует ПР - не тратится на это обмен раз, сокращается логика в центральном мозгу два, сокращается обмен между центром и ПР кстати три. (меньше переменных придется читать)

[Cs-Cs]

Так. Я щас сорвусь. Потому ни хера мой этот дьяволодиммер не пашет. Всё равно проскакивают какие-то мутные нажатия. НЕ ПОЛУЧАЕТСЯ! Вот не получается, и всё!
Короче melky, чёрт раздери тебя. УСЛЫШЬ МЕНЯ: CODE SYS v3 - МЕДЛЕННЫЙ. ПО ФАКТУ. ОЧЕНЬ! В ДЕСЯТЬ РАЗ МЕДЛЕННЕЕ СКАД, ПРок и ПЛК110!! И медленный (АДСКИ) медленный там опрос по любому Modbus-протоколу.
ДАЖЕ ЕСЛИ ТЫ ЗАДАЧЕ ОПРОСА ВЫДАШЬ ВРЕМЯ В 8-10 мсек - всё равно МЕДЛЕННЫЙ. У меня щас проект и состоит из двух FB всего: Dimmer и ClickTest. Один хрен.
Поэтому никакие советы по разделению и прочему тут не помогут. Сел я в лужу с этим идиотским диммером и уже так запутался в коде, что сам не понимаю, ЧТО написал и КАК оно работает и КАК должно работать. Всё. У меня коллапс мозга. Пойду в окно выкинусь.

[melky]

Сколько кнопок используется в диммере? поставьте вместо модуля в/в ПР-ку, ведь наверняка есть у вас в наличии, хотя бы временно и напишите в ней свою ловлю кнопок

з.ы. ну вы сами выбрали CodeSys 3 и кучу модулей в/в, никто же вас не тянул строить все на одном мозге.

[melky]

И кстати, вы счетчиками ловите нажатия, вы их как опрашиваете? по одному на вход или всей пачкой ?

[Cs-Cs]

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 с разбором всех значений.
Вот пока интерфейс выдумал: IOEdit-VB-Icons.gif

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