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

[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.

[Cs-Cs]

А кетаец с осциллом это подтверждает ?

Да в том-то и дело, что ни фига. Там на нём, как на ПЛК110 ровненько идёт: запрос - ответ, запрос-ответ.
Скорее всего я не понял, как эта либа работает и читаю что-то не то и/или не в те моменты.

[melky]

по дополнению, если программа предполагает так же чтение счетчиков, то в схеме они должны быть первыми, чтобы всегда было с 1-ого по Х---какой-то

[Cs-Cs]

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

[Cs-Cs]

Валенок Так, ща, сначала рассортируем путаницу про ошибки и битые байты.
Во ВСЕХ случаях по логическому анализатору я вижу, что модуль получает запрос и что он отдаёт корректный ответ.
Однако:
а) На штатном опросе через конфигуратор работает медленно и периодически сыпятся ошибки таймаута. Косвенно это зависит от интервала между фреймами, но НЕ зависит от времени опроса канала. Такое ощущение, что штатный планировщик не успевает что-то опросить (или прочитать ответ) и вываливается в таймаут.
За сутки у меня набиралось около 2 000 ошибок.
б) На опросе через OCL опрос идёт быстрее, количество ошибок - около 20 в сутки.
в) Мои пробы через SysCom пока не увенчались успехом, потому что я не разобрался как получать ответ от устройства. Иногда я читаю верный, иногда - мусор.

Ещё раз повторю, что на анализаторе и на шине я вижу и интервалы между запросами, и ответы модулей IO. Там всё отлично, и нет такого что мы передавали данные, оборвали их, и вдруг стали передавать что-то другое.

Про времена. Тут ты меня этими t0, t1 запутал. Это напоминает плохой стиль программирования, когда куча переменных и ни фига не ясно.
Поэтому можешь ли ты подставить нормальные цифры? Это ж ты в туалетах смыслишь, а я - простой дурачок, не понимаю вот.
Но зато знаю, что на скоростях выше 19200 эти времена между фреймами должны быть уже не 3,5 символа, а чётко фиксированными:
а) 750 мксек между символами;
б) 1 750 мксек (1,75 мсек) между фреймами
Так что на 115 200 тайминги будут другие.

Короче. Вот давай возьмём те данные для Saleae и просто померим. Фигли считать?
Вот запрос на чтение 32 регистров: MB-RequestReg.gif
Время запроса (с запасом я там маркеры поставил) равно 0,847 мсек.

Вот ответ на этот запрос: MB-AnswerReg-1.gif
Время ответа равно 6,131 мсек.
Тут у нас отдаётся 32 регистра.
Среднее время на регистр равно 6,131 / 32 = 0,191 мсек

Вот ответ на запрос битовой маски: MB-AnswerReg-2.gif
Время ответа равно 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%.

[Cs-Cs]

Оно надо мне ?

А кто ж тебя знает. К примеру, если бы тебе тут было бы не надо - то ты бы, как спокойный и грамотный человек, мимо бы прошёл. Значит - надо, значит интересно.

Угу. Я практик, мне проще померить, чем рассчитывать.

Пока всё. Дальше мне надо дня на три отвлечься на другое, а потом я к SysCom вернусь.

[Cs-Cs]

Погоди, Валенок. А чего ты выяснил? У меня ж не получилось пока. Пока получилось только запросы посылать, а ответы нормально я не получаю.
Я считаю это недоделанным делом, и выводы делать пока рано.