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

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 снифером не цеплялся и другой ПЛК на нем щупал. Овен как-то даже не хочется :) вообще удивляюсь как вы его выбрали для умного дома :) Точнее как вы выбрали только СПК для такой задачи, да еще и Овен :)

В микросекундах:

Вложение 52580

Цитата:

---

Сообщение от Валенок

Ну так если цикл такой маленький (заявлен даже меньше 1мс) но не вижу проблем в обмене если работать напрямую через местный аналог syslibcom. Он есть ?

---

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

Цитата:

---

А разве для обмена нужно что-то быстрое ? Обмен - процесс медленный по сравнению с заявленными циклами.

---

Судя по предыдущим постам в теме - в данном случае нужно.
И, очевидно, есть разница между пустым циклом и циклом конкретного пользовательского приложения.

Цитата:

---

Про какую биб-ку говорим ?

---

Про SysCom, естественно ("местный аналог syslibcom").

Цитата:

---

А это вообще - что ?

---

Естественное возобновление нормальной работы линии связи после, например, прекращения действия краткосрочной помехи.

Валенок Ой как я буду ругаться. Я очень жёстко не люблю тех, кто читает невнимательно. CodeSys 2 от CodeSys 3 отличается примерно как MS-DOS от Windows 10. И если хоть ещё кто в этой теме скажет "Да вот у меня на CodeSys v2 всё пашет, хрен ли вы тут морочитесь", то я призову на него все кары мира. Потому что надоело!

Вы хочите цифр? Их есть у меня. Даю средние времена цикла за 4 часа работы ПЛК:
Задача опроса модулей IO = 671 мксек
Задача этого диммера, одна, только с диммером (проект пустой до сих пор) = 453 мксек
Но при этом реакция ПЛК на кнопку не мгновенная, как на CodeSys v2. Ты можешь кнопку нажать, а ПЛК её не увидит.
Я снял короткое видео, прям с рук, показать реакцию: https://cs-cs.net/ExxChange/MAH01874...-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 работает не так, как описано в справке...

Цитата:

---

А в 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%). По идее железо будет влиять.
А как виртуальному контроллеру надо будет указать физические порты, с которых он опрос будет вести?
Сечас побалуюсь, попробую!

Цитата:

---

Сообщение от Cs-Cs

Ну с OCL загрузка проца в СПК стала в 70% примерно (была 50%). По идее железо будет влиять.
А как виртуальному контроллеру надо будет указать физические порты, с которых он опрос будет вести?
Сечас побалуюсь, попробую!

---

В этом случае указывается номер виртуального COM-порта из диспетчера устройства Windows.

Хммм... он на виртуальном ПЛК ругается на OCL. Пишет что "...невозможно конвертировать тип ULINT в UDINT" во многих FB либы.

Цитата:

---

Сообщение от Cs-Cs

Хммм... он на виртуальном ПЛК ругается на OCL. Пишет что "...невозможно конвертировать тип ULINT в UDINT" во многих FB либы.

---

Покажи, пожалуйста, скриншотом, какой таргет виртуального ПЛК ты выбрал.
Нужно выбрать именно CODESYS Control Win V3 (не x64, не RTE и не какой-либо другой).

Этот: Вложение 52586
Надо было Realtime брать?

Нужно выбрать именно CODESYS Control Win V3 (не x64, не RTE и не какой-либо другой).
И версию лучше поставить 3.5.14.30.

Валенок Неее! Ещё читай до полного понимания =) Надоело объяснять каждому, кто просто забежал почитать.

Итак, ВИДОС: https://cs-cs.net/ExxChange/MAH01877...n-Requests.MP4
Циклы выполнения задач (в том числе опроса через OCL) сократились до десятков микросекунд О_о!
Но при этом CodeSys всё равно так же, как и на ПЛК, медленно опрашивает модули. Как будто он сам делает задержки.

Пошёл за логическим анализатором... интересно!
ЗЫ. Чёрт, НЕ ТАК я собирался набирать инфу о работе планировщика опроса Modbus в CodeSys v3... думал, буду тихо под чай проводить опыты... А не экстремально изучать на лету =)

На мой взгляд - эксперимент наглядно показывает, что наблюдаемый эффект никак не связан с железом и к СПК тут вопросов нет.
Остаются две момента, которые могут влиять на происходящее:
- какие-то особенности рантайма 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...CodeSys-v3.MP4
Файл с данными логического анализатора лежит тут: https://cs-cs.net/ExxChange/CodeSys-...5200.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 с нуля составлять... на уровне байтов! Эхх!
Ну, "Ныряй, здесь неглубоко" ©

Пойду погуляю, приду - буду кодить!

Цитата:

---

А можно забыть про "интервал вызова" а просто каждый следующий сразу после окончания транзакции предыдущего ?

---

Конечно, можно - через SysCom и его синхронные вызовы.
Следующая тема на форуме, видимо, будет "что-то при обрыве линии RS-485 визуализация очень сильно тормозит, как будто ее что-то блокирует".
Я согласен с вами в том ключе, что в ряде конкретных случаев обмен через синхронные функции в CDS V3.5 - единственный способ решения поставленных задач.
Но на практике - эти задачи обычно рождаются из изначально неправильного подхода при проектировании системы автоматизации.


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

Цитата:

---

Может тему уже в раздел по 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...110-Modbus.MP4
Вот файл анализатора (кривоватый): https://cs-cs.net/ExxChange/CodeSys-...5200.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 вернусь.

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