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

[Cs-Cs]

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...110-Modbus.MP4
Вот файл анализатора (кривоватый): https://cs-cs.net/ExxChange/CodeSys-...5200.logicdata
Saleae-CDS-v2-1.gif Saleae-CDS-v2-2.gif
Тут запросы идут через 10-12 мсек, а ответы модулей такие же как и раньше - за 4-5 мсек.

Когда я погружался в ПЛК, то я начинал со 110ых. И там всё как раз летало вовсю. И поэтому то, что CDS 3 опрашивает устройства медленнее, для меня было открытием в своё время.

[melky]

Мое ухо одного резануло то, что одним запросом читается маска, а вторым запросом счетчики ? не?
Просто одним запросом прочитать весь модуль не бывает ?

[melky]

Валенок да как не? MB110-32ДН Битовая маска значений входов регистры 0x63 и 0х64 и далее с 0x65 пошли счетчики входов.

Как не? опять что-то поменялось в Датском (Овеновском) королевстве ?

[Cs-Cs]

melkiy Про прочитать одним запросом. Угу! Это - инерция мышления. Когда-то привык, что в некоторых (не ОВЕНских) модулях регистры могут идти не подряд, так и делал. Перетряхну на один общий запрос, конечно.

capzap Штатный работает ещё медленнее, чем OCL. Поэтому на OCL и перешёл.

Валенок Мне сказали, что ты всех троллишь. Окей, вот, держи список:
МВ110-32.ДН = 3 штуки. Читаем битовую маску и счётчики входов (количество зависит от модуля: где-то все 32, где-то только 12, где-то 16)
МУ110-32.Р = 2 штуки. Пишем битовую маску выходов
МУ110-16.Р = 1 штука. Пишем битовую маску выходов

Порт ща будем юзать. То есть ээ... собак учить. Но не плавать, а летать. Методом "засунем петарду в собаку и посмотрим, полетит или лопнет".

[Cs-Cs]

capzap А я там писал. Сейчас, найду, повторю:
* На интервал между фреймами пробовал ставить 5-10-15-20 мсек. На 5 мсек всё работает быстро, но валятся ошибки таймаутов. На 20 мсек всё работает медленно, но ошибок не валится.
* Сама скорость опроса каналов стоит по 20 мсек на канал.

[Cs-Cs]

capzap Не понял. Ну 20 мсек на канал. И что тут не так?
Как тогда это работает в CDS v3 (я это сам собрался исследовать, но вдруг уже есть ответ)?
Вот положим у меня не туева хуча, а всего лишь шесть модулей. Это не 20 модулей же.
Как тогда мне время опроса канала ставить? Считать руками, что ли? По идее этим сам планировщик опроса CDS должен заниматься.

[Cs-Cs]

Блин! Ну-ка поясните мне, а как в DO слать битовую маску тогда, если я не знаю, что у меня в ней в какие моменты изменится?
Ща-ка поднабросим-ка... на вентилятор.

Вот у меня есть модуль DO. На 32 канала. Например, из него:
* Часть каналов - это приводы кранов отопления
* Часть каналов - это лампы
* Часть - шторы
* Часть - вентиляторы

Всё это обсчитывается и управляется в разных местах проекта (и даже разных задачах) в разных булевых переменных.
Вы тут с Валенком напираете на запись IO по изменению. Ну и как я буду отлавливать в задачах изменение отдельных бит битовой маски и потом её писать один раз-то?
Или вы что? Не используете безопасные значения на модулях, что ли? У меня на модулях стоит настройка безопасных значений: если его не опрашивать, то через 5 секунд модуль переходит в безопасное состояние (аварийное).
Как тогда у вас, троллей чёртовых, вообще промка работает?

И последний забавный вопрос. Почему у меня ПЛК110 c теми же чтениями-записями ЛЕТАЕТ? И при этом не жалуется на какие-то там 20 миллисекунд задержек.

[Cs-Cs]

Валенок Эммм... я не фанат туалетного мышления с кабинками, поэтому эти образы мне не совсем понятны.
Что мне слышать и чувствовать, когда я посмотрел всё логическим анализатором? И я вижу, что запросы пролазят хорошо. На ПЛК110.

Не отвеченным остался мой вопрос про то, как там в промке про отвал связи и безопасные значения?
Или это было keep-alive, что ли?
Просьба уточнить:
а) А чем это отличается от обычной отправки запроса к модулю?
(я знаю, что якобы меньше загружает шину)
б) Что будет, если именно в момент отправки запроса по изменению маски будет Framing Error, и запрос до модуля не дойдёт?
(я не фанат событийного программирования, и телеграмм типа как в KNX: там нет никакого подтверждения о том, дошло это до адресата или нет)
в) На сколько в байтах это уменьшит загруз линии?
(на 8 байт из сотни - так вот прям это поможет-то?)

ЗЫ. Ща мучаю SysComLib. Отсылать - отсылаю, пока не пойму как прочитать. Ща задержки введу туда и буду мозговать.
Сам опрос летает на ней даже быстрее, чем модули успевают отвечать. Так что да... собака с петардой кажется собирается взлететь, да.

[Cs-Cs]

Так. По запросам (по скорости их отправки) SysLibCom рулит, да. Светодиоды мигают на модулях как бешеные.
Сами модули при этом отвечают за 5-6 (максимум) мсек, так что запросами их можно закидывать до умопомрачения.

Я ни разу до сегодня SysLibCom не юзал и не понял, как ею читать из порта. По логическому анализатору я вижу, что интервалы между запросами и ответами там в 13-25 мсек (это плавает в зависимости от других задач), но у меня не получается пока что прочитать назад в ПЛК ответ из порта.
SysLibCom-DI.gif
По ходу дела писать SysComWrite и сразу SysComRead было плохой идеей. Я даже пробовал сдвигать чтение на следующий цикл задачи - всё равно пока не соображу, чего не работает.

[Cs-Cs]

Валенок
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.