Просмотр полной версии : Как ускорить считывание регистров?
1. Имеется ПЛК110 м02, и имеется некоторое устройство Raspberry PI, с которого считываются обычные (16bit) регистры в количестве примерно 120 шт. Я, пользуясь стандартными средствами Codesys, накидал эти регистры в конфигурацию плк. И всё бы ничего, но данные в этих регистрах обновляются примерно раз в 10 с. Считывание в настройках стоит каждые 100мс.
На считываемом устройстве изменяю регистр, а обратную связь на ПЛК вижу секунд через 10. При этом если считывать OPC-сервером, изменения условно моментальны.
Считывание происходит по ModbusTCP.
Короче очень долго считывается такой объём регистров. При этом ошибок связи нет. Как-то можно это ускорить стандартными или нестандартными средствами?
2. Также есть модули МУ210-403 и МВ210-202 в количестве примерно по 6шт. каждого, считывание данных с которых происходит с некоторой задержкой, субъективно примерно 0,5с.
В чём суть. Есть умный дом на Apple Homekit, к которому прикручены выходы модулей ввода в качестве осветительных приборов, розеток и прочих аксессуаров. Также есть ПЛК который также опрашивает эти же модули и пишет в них состояния выходов. Есть простые кнопочные выключатели по дому, нажатия с которых обрабатываются контролером, т.е. контроллер постоянно (50мс) опрашивает модули ввода (МВ210-202) на предмет нажатия клавиши, и если клавиша нажата, то включает/выключает соответствующий выход на модуле вывода (МУ210-403), зажигает свет, напрмиер.
И получается так, что ПЛК это делает значительно медленнее чем Rasberry PI с пробросом информации о состоянии на планшет, т.е. механический выключатель, работающий через контроллер, работает медленнее виртуального выключателя, работающего через Homebridge (Raspberry PI) в связке с Homekit на Ipad.
Визуально это проявляется следующим образом: если я "долблю" по иконке на айпаде, я не могу развить такую частоту нажатий, чтобы не сработал свет, если же я это делаю клавишей, подключенной даже непосредственно на вход ПЛК, то свет не загорается/тухнет не чаще 2 раз в секунду, если я это делаю через клавишу подключенную к модулю ввода, то частота включения/выключения света не поднимается выше 1,5 Гц. т.е. свет может включиться/выключиться не чаще 3 раз в 2 секунды. Поэтому проходя мимо клавиши нельзя ткнуть на неё, как обычно привыкли делать, а надо её нажать с небольшой паузой, примерно 0,5с, что весьма неудобно и неприятно. Естественно ошибок по считыванию также нет, считывание каждые 50мс таймаут 150мс.
Как победить этот недуг? И первый и второй?
p.s. И ещё такой нюанс при полной заливке программы с изменением регистров и всем прочим, когда контроллер полностью останавливается, буквально первые несколько секунд-минуту после заливки реакция очень заторможенная нажатия обрабатываются по несколько секунд, потом всё выравнивается и приходит в вышеописанную ситуацию без ошибок.
Пробовали обмен данными организовывать через Raspberry Pi, т.е. малина читает состояние регистров из модулей и пишет их в контроллер, контроллер на основе этих регистров выставляет другие регистры, которые читаются малиной из ПЛК и пишутся в модули вывода, получается тоже быстро.
1. Имеется ПЛК110 м02, и имеется некоторое устройство Raspberry PI, с которого считываются обычные (16bit) регистры в количестве примерно 120 шт. Я, пользуясь стандартными средствами Codesys, накидал эти регистры в конфигурацию плк. И всё бы ничего, но данные в этих регистрах обновляются примерно раз в 10 с. Считывание в настройках стоит каждые 100мс.
На считываемом устройстве изменяю регистр, а обратную связь на ПЛК вижу секунд через 10. При этом если считывать OPC-сервером, изменения условно моментальны.
Считывание происходит по ModbusTCP.
Короче очень долго считывается такой объём регистров. При этом ошибок связи нет. Как-то можно это ускорить стандартными или нестандартными средствами?
2. Также есть модули МУ210-403 и МВ210-202 в количестве примерно по 6шт. каждого, считывание данных с которых происходит с некоторой задержкой, субъективно примерно 0,5с.
В чём суть. Есть умный дом на Apple Homekit, к которому прикручены выходы модулей ввода в качестве осветительных приборов, розеток и прочих аксессуаров. Также есть ПЛК который также опрашивает эти же модули и пишет в них состояния выходов. Есть простые кнопочные выключатели по дому, нажатия с которых обрабатываются контролером, т.е. контроллер постоянно (50мс) опрашивает модули ввода (МВ210-202) на предмет нажатия клавиши, и если клавиша нажата, то включает/выключает соответствующий выход на модуле вывода (МУ210-403), зажигает свет, напрмиер.
И получается так, что ПЛК это делает значительно медленнее чем Rasberry PI с пробросом информации о состоянии на планшет, т.е. механический выключатель, работающий через контроллер, работает медленнее виртуального выключателя, работающего через Homebridge (Raspberry PI) в связке с Homekit на Ipad.
Визуально это проявляется следующим образом: если я "долблю" по иконке на айпаде, я не могу развить такую частоту нажатий, чтобы не сработал свет, если же я это делаю клавишей, подключенной даже непосредственно на вход ПЛК, то свет не загорается/тухнет не чаще 2 раз в секунду, если я это делаю через клавишу подключенную к модулю ввода, то частота включения/выключения света не поднимается выше 1,5 Гц. т.е. свет может включиться/выключиться не чаще 3 раз в 2 секунды. Поэтому проходя мимо клавиши нельзя ткнуть на неё, как обычно привыкли делать, а надо её нажать с небольшой паузой, примерно 0,5с, что весьма неудобно и неприятно. Естественно ошибок по считыванию также нет, считывание каждые 50мс таймаут 150мс.
Как победить этот недуг? И первый и второй?
p.s. И ещё такой нюанс при полной заливке программы с изменением регистров и всем прочим, когда контроллер полностью останавливается, буквально первые несколько секунд-минуту после заливки реакция очень заторможенная нажатия обрабатываются по несколько секунд, потом всё выравнивается и приходит в вышеописанную ситуацию без ошибок.
Пробовали обмен данными организовывать через Raspberry Pi, т.е. малина читает состояние регистров из модулей и пишет их в контроллер, контроллер на основе этих регистров выставляет другие регистры, которые читаются малиной из ПЛК и пишутся в модули вывода, получается тоже быстро.
Это потому, что мастер, который в конфигурации ПЛК, не умеет делать групповые запросы с слейву (модули В/В, регистры в Raspberry PI).
Т.е. читает в каждом запросе только по одному регистру, а "Считывание в настройках стоит каждые 100мс" и того -100мс х 120регистров = 12 сек.
Используйте в в КОНФИГУРАЦИИ ПЛК модули String input/output для ускорения обмена по шине ModBus, например
https://owen.ru/forum/showthread.php?t=22915&p=333593&viewfull=1#post333593
https://owen.ru/forum/showthread.php?t=22915&p=244022&viewfull=1#post244022
Копайте программу, если уж от кнопок с ПЛК у вас тормоза, то явно что-то с кодом.
Про групповые запросы понял, разберусь переделаю. Спасибо за совет.
Как ускорить работу ПЛК с модулями ввода/вывода? Там считывается и пишется по паре регистров с устройства. Изменение времени опроса в диапазоне от 50мс до 400мс субъективно на быстродействие не влияет.
Копайте программу, если уж от кнопок с ПЛК у вас тормоза, то явно что-то с кодом.
Копать программу смыла особого нет, там всё банально и просто:
dword_1.0:=dword_2.0 - задержка в полсекунды, где соответственно dword_1 - регистр модуля вывода, а dword_2 - регистр модуля ввода. Пинг до модулей 1-2мс.
0,5 секунды это 500мс - это дофига...
Филоненко Владислав
25.03.2021, 10:39
Гадание по фотографии плохо работает весной. Выложите проект
Блин... я смотрю, тема ускорения опроса прям везде актуальна )
Хотим проект! Мне играция с рапсберри этой ещё предстоит, но на ПЛК и на CDS v2-то оно должно летать.
А почему были выбраны модули по LAN, если можно было по RS-485 их взять и на ПЛК110 опрашивать?
Блин... я смотрю, тема ускорения опроса прям везде актуальна )
Хотим проект! Мне играция с рапсберри этой ещё предстоит, но на ПЛК и на CDS v2-то оно должно летать.
А почему были выбраны модули по LAN, если можно было по RS-485 их взять и на ПЛК110 опрашивать?
Потому что они новее, лучше, современнее, быстрее, совершеннее (но это неточно). И в конце-концов работают по ethernet в мультимастерном режиме. Поэтому есть возможность управлять напрямую выходами с нескольких мест одновременно с ПЛК и с Homekit минуя плк. Короче нужна была мультимастерность.
Гадание по фотографии плохо работает весной. Выложите проект
У вас есть готовые решения на этих модулях, которые работают со скоростью соизмеримой с пингом до этих модулей? т.е. я правильно понимаю, что эти модули в связке с плк110 вы запускали и они работали с адекватной скоростью, которую позволяет осуществлять обмен данными и время обработки цикла?
Просто пока мы не запустили Homebridge я особо и не задумывался, что эта вся связка способна работать значительно быстрее, буквально моментально. И только после этого понял, что я что-то делаю не так, что у меня через контроллер это работает дольше. Если есть решения поделитесь, пожалуйста.
Parovoz Так. Я вижу совсем другое. Которое называется "Перемудрил". Я не совсем спец (но по моим постам можно найти то, почему я Мх210 для УД не люблю), но то, что я подумал - это что оптимизация "By value change" приводит только к тому, что к каждому модулю IO создаётся куча TCP/TP-соединений вместо одного.
А вот сколько ПЛК110 может этих соединений держать - это кто-то проверял? И смотрели ли сетку сниффером?
И то, что советовал народ - это надо сделать ОБЯЗАТЕЛЬНО. Надо ПАКОВАТЬ (ррр, да, да, да!!) данные в массив STRING (байтов), чтобы максимально сократить объём данных, которые передаются на Сервак.
Ещё я слазитл в конфигурацию задач. Да, я в курсе про минимальное время цикла и всё такое. Но я бы прописал бы явно вызов PLC_PRG и задал бы ему время в 10-20 мсек и посмотрел бы, как это будет работать.
Про группировку и упаковку это понятно, ещё просто не реализовывал. Там вопрос закрытый.
Меня сейчас интересует задержка в связке: модуль ввода-плк-модуль вывода. Там считывание по паре регистров на устройство всего.
"By value change" сделано с той целью, чтобы можно было управлять модулями с других мастеров, в противном случае контроллер перезаписывает свои значения.
Время цикла задано нулевое, я так понимаю тогда оно само варьируется в нужном диапазоне. По работе цикл занимает в среднем примерно 2-3мс.
Тут основной косяк в том, что запись/чтение модбас долго работает сам цикл выполняется моментально.
Я эти модули уже использовал до этого на считывание импульсов датчиков вращения, пытался считывать в реальном времени, импульсы начали теряться, переделал на чтение счётчиков из модулей ввода и периодичное сравнение значений этих счётчиков и вычисление частоты вращения. При этом проверку импульсов в реальном времени делал, когда был подключен один модуль, с изменением количества модулей ситуация субъективно не меняется т.е. реакция не замедляется и не ускоряется. Один модуль или десять модулей частота определяемых импульсов в реальном времени примерно такая же в пределах 5 Гц в лучшем случае, дальше импульсы теряются.
Блин, мне не понятен концепт.
Я у себя вовсю юзаю модули Mx110. С ними проблем нет, и когда они стоят напрямую в щите, и ПЛК ими рулит на 115 200 по RS-485 - всё летает. Я ставлю тогда на опрос DI время в 5-10 мсек на модуль, на выходы - такое же, и на всякие AI - по 300-500 мсек.
С Mx210 я сделал один щит, и дальше от них отказался, так как по Ethernet у меня был неудачный опыт, мне не понравилось. И от моих реле модули глючили ещё.
Я не всё умею, то ты может можешь посмотреть состояние сетки при помощи сниффера? Это такие программы, которые могут отследить все TCP и прочие запросы, которые ходят в сети. И записать их в лог по времени. Вот тогда и можно будет увидеть и понять, нормально ли ПЛК открывает TCP-соединения, правильно ли работают запросы и сколько времени проходит перед ответом модуля.
Так как мне распределённые концепты не нравятся, то я думал, что у меня сердцем будет сам ПЛК, а уже к нему по ОДНОМУ TCP-соединению будет коннектиться этот рапсберри. Причём я думал так, что я сам с нуля возьму библиотеку и напишу обработку TCP не на уровне ПЛК (когда приходится в конфигурации создавать кучу фигни и пытаться это ускорить), а сам - например, открою соединение до сервера и буду гонять туда хоть килобат, но в своём формате -- чтобы быстрее было. Одним запросом.
И, кстати, ещё. Может быть тебе посмотреть в эту сторону вообще? Взять либу (SysLibSockets.lib) и нафигачить на ней опрос модулей? Тогда ты сам сможешь реализовать к ним длинные запросы или писать по изменению, а не создавать тьму регистров в конфигурации ПЛК?
Блин, мне не понятен концепт.
И, кстати, ещё. Может быть тебе посмотреть в эту сторону вообще? Взять либу (SysLibSockets.lib) и нафигачить на ней опрос модулей? Тогда ты сам сможешь реализовать к ним длинные запросы или писать по изменению, а не создавать тьму регистров в конфигурации ПЛК?
Концепция в распределённом управлении, если контроллер с клавишами отвалился можно тыкать дальше с айпада. В MBRTU может быть только один мастер.
Данная концепция была согласована с заказчиком в целях улучшения надежности системы: отвалился айпад - тыкаем выключатели, отвалился контроллер - тыкаем айпад. В случае с Мх110 после отвала контроллера наступает blackout.
Плюс разные элементы автоматизации реализуются на айпаде напряму в homekit, т.е. мне не надо пробрасывать всю коммуникацию через контроллер, что дало свои плоды, с homekit всё работает просто моментально.
Дополнительно развёрнут VPN и можно удалённо конфигурировать модули ввода/вывода, настраивать доп функционал через owencloud да банально просто на коленке поднять скаду на мобильнике и с любого андроида параллельно тыкать дом, в общем как ни крути но Мх210 лучше, современнее, функциональнее и сами модули в итоге работают достаточно быстро, недостаточно быстро почему-то работает обмен с контроллером.
накой весь опрос по tcp пихнули в одного мастера ?
Потому что мне так сказала тех поддержка несколько лет назад. Когда я делал на каждое устройство отдельный мастер у меня валились ошибки связи. Я звонил в тех поддержку, мне сказали, что надо сделать одного мастера на интерфейс, что одним интерфейсом может управлять только один мастер и в него уже надо пихать все устройства подключенные к интерфейсу, в противном случае мастеры будут конфликтовать за право пользования интерфейсом, как-то так, почти дословно.
т.е. на каждое устройство надо создавать отдельного мастера? это ускорит обмен? но опять же, когда я только начинал работать с этими модулями, если мне память не изменяет, я добавил один модуль, чтобы проверить максимальную частоту считываемых импульсов в реальном времени, и она там была в пределах 5 Гц, чуть быстрее, но не 20Гц как предполагает опрос в 50мс.
Тем не менее сегодня попробую перекроить состав устройств. О результате сообщу.
Угу. И получается, что ради распределённости автор перемутил, а теперь мучается.
Если ляжет ПЛК - то надо иметь его горячую замену. Не думаю, что ПЛК110 стоит прям вот дороже айпада или самого щита.
В общем, я за свой концепт. И за то, чтобы Автор наконец-то глянул трафик в сетке сниффером! Вот тогда-то и будет ясно, кто тормозит.
Филоненко Владислав
26.03.2021, 08:53
1. Один мастер за один раз может опросить один модуль. Учитывая что в нём 44 модуля, в самом наидеальном случае (мгновенный ответ, минимальный цикл опроса ВСЕХ модулей будет 44 мс). В реале учитывая дискретность времени, даже минимальные задержки ответов в 1 мс - уже около 100 мс.
2. Непонятно для чего пишутся значения в выхода и они же считываются. Зачем? Узнать что запись не произошла можно по коду ошибки. А еще надёжнее поставить режим both, поставив период принудительной записи несколько секунд.
3. Все опросы по периоду вынести в отдельный мастер(ы)
4. Если ожидается одновременная смена значений у нескольких модулей и хочется быстроты реакции - разделить из по разным мастерам.
Филоненко Владислав
26.03.2021, 08:55
Потому что мне так сказала тех поддержка несколько лет назад. Когда я делал на каждое устройство отдельный мастер у меня валились ошибки связи. Я звонил в тех поддержку, мне сказали, что надо сделать одного мастера на интерфейс, что одним интерфейсом может управлять только один мастер и в него уже надо пихать все устройства подключенные к интерфейсу, в противном случае мастеры будут конфликтовать за право пользования интерфейсом, как-то так, почти дословно.
т.е. на каждое устройство надо создавать отдельного мастера? это ускорит обмен? но опять же, когда я только начинал работать с этими модулями, если мне память не изменяет, я добавил один модуль, чтобы проверить максимальную частоту считываемых импульсов в реальном времени, и она там была в пределах 5 Гц, чуть быстрее, но не 20Гц как предполагает опрос в 50мс.
Тем не менее сегодня попробую перекроить состав устройств. О результате сообщу.
Речь шла о 485!!!
2. Непонятно для чего пишутся значения в выхода и они же считываются. Зачем? Узнать что запись не произошла можно по коду ошибки. А еще надёжнее поставить режим both, поставив период принудительной записи несколько секунд.
Это сделано с целью синхронизации состояния выходов, т.к. управление приборами производится с разных мест, то можно на айпаде включить свет, а выключателем выключить, плк мониторит фактическое состояние выходов на модуле вывода и при нажатии клавиши инвертирует его, в противном случае пришлось бы нажимать выключатель дважды ведь плк бы изначально полагал, что канал выключен. А с учетом того, что идёт перезапись регистра целиком, то складывалась очень забавная ситуация. Ходишь по дому, включаешь свет с айпада, и тут термостатный блок решил открыть термоголовку и весь свет потух, т.к. перезаписался целиком регистр точнее два в которых включена только термоголовка, а свет выключен, теперь же всё работает корректно. Можно включать и выключать свет исходя из фактического состояния светильника.
По делу, вывел один модуль ввода в отдельный мастер, прописал ему время опроса 10 мс таймаут 50мс. Всё наладилось, все осечки по нажатиям исчезли, как бы быстро я не тыкал клавишу. Выключатель работает будто аналоговый ни намёка на задержку по нажатию. Буду делать для каждого устройства теперь мастер. Ошибок по обмену данными также не фиксируется.
Филоненко Владислав
26.03.2021, 13:04
Это сделано с целью синхронизации состояния выходов, т.к. управление приборами производится с разных мест, то можно на айпаде включить свет, а выключателем выключить, плк мониторит фактическое состояние выходов на модуле вывода и при нажатии клавиши инвертирует его, в противном случае пришлось бы нажимать выключатель дважды ведь плк бы изначально полагал, что канал выключен. А с учетом того, что идёт перезапись регистра целиком, то складывалась очень забавная ситуация. Ходишь по дому, включаешь свет с айпада, и тут термостатный блок решил открыть термоголовку и весь свет потух, т.к. перезаписался целиком регистр точнее два в которых включена только термоголовка, а свет выключен, теперь же всё работает корректно. Можно включать и выключать свет исходя из фактического состояния светильника.
По делу, вывел один модуль ввода в отдельный мастер, прописал ему время опроса 10 мс таймаут 50мс. Всё наладилось, все осечки по нажатиям исчезли, как бы быстро я не тыкал клавишу. Выключатель работает будто аналоговый ни намёка на задержку по нажатию. Буду делать для каждого устройства теперь мастер. Ошибок по обмену данными также не фиксируется.
Для каждого не надо! Надо только для тех, у кого важна скорость реакции.
Для каждого не надо! Надо только для тех, у кого важна скорость реакции.
Естественно, не для каждого, а для каждого, для которого надо. Не имеет смысла все модули форсить по 10 мс. Короче модули ввода перевел под мастеры свет начал летать :rolleyes:
Всем спасибо, все свободны. :)
Филоненко Владислав
26.03.2021, 16:45
Каких битовых функций в Модбасе Вам, Валенок, не хватает?
И это оптимизируется легко. Читать "для показать" можно редко (1..4 сек) и оно же кипалив.
По входам можно читать именно счетчики (не смотрел проект). Реагировать на факт и четноть изменения.
Тогда и входам можно 50..100мс
Какой-то режим "переключения" - это случайно не инверсия конкретного выхода ?
Смотреть счётчики слишком мудрёно, поэтому и хотел сделать максимально по "тупому" просто мониторить в реальном времени состояния входов, по счётчикам я уже делал на другом объекте, слишком громоздко получается, тут я считываю с одного модуля 32 бита, а то пришлось бы считывать 20х32 бита чтобы каждый канал мониторить, а таких модулей 8 штук, короче в 20 раз бы вырос трафик и количество обрабатываемых данных, нафиг оно надо. Когда мне нужен был именно частотомер для импульсов вращения барабана нории, я читал счётчики каждые полсекунды, это было точно и меня устраивало.
Тут же бытовые выключатели, такой изврат ни к чему. 10мс меня вполне устраивает. Как бы я ни старался долбить по клавише ни одной осечки по входящему импульсу у меня не получилось сделать, считаю цель достигнутой, а метод оправданным.
e.filatov
26.03.2021, 17:59
Лично я на 110-х по Ethernet работаю только через библиотеки.
А так, после разработки ПЛК200 - перешёл на них. Там всяко проще 3-4 кликами разнести опрос по разным потокам
Повеселили. Хоть про размер eth-пакетов посмотрели. Но раз устраивает - и норм.
Мне ? Мне пофиг. Чтоб чего там синхронизировать а то "термостатный блок решил открыть термоголовку и весь свет потух" в многопортовом полном дуплексе устраивают голимый поллинг.
Не понимаю сарказма.
Если есть возможность обрабатывать и считывать 20 битов вместо 20-ти 32-битовых модулей и обрабатывать их самым примитивным образом (false/true) на кой тогда городить огород из чётности/нечётности и сравнении счётчиков? В моём конкретном случае порядка 160 счётчиков вместо 160 Битов.
Когда мне надо было мониторить частоту вращения барабана нории по датчику импульсов, я использовал счётчики, здесь же в этом смысла нет никакого. Это касаемо модулей ввода.
Про синхронизацию тоже не понял к чему эти ухмылки, в сети организовано мультимастерное управление. Как контроллер должен понять, в каком состоянии сейчас находятся выходы модуля вывода, если их в любой момент может поменять другой мастер?
Объясняю ситуацию на пальцах: все выходы допустим изначально выключены, потом я с айпада включаю 5 первых выходов (свет), но контроллер об этом не знает. Тыкаю на клавишу, завязанную на плк, включить 6 выход. И плк благополучно перезаписывает весь модуль с одним включенным 6 выходом, потому что "думает", что надо включить только 6 выход, т.к. контроллером в модуль вывода я пишу по изменению модуль 32 бита.
Чтобы таких ситуаций не происходило я контроллером постоянно считываю фактическую битовую маску выходов и перезаписываю модуль с учётом имеющейся фактической картины. И на команду включить 6 выход, контроллер перезаписывает модуль с включенными первыми пятью и ещё одним 6 выходом. Что я делаю неправильно?
Также есть ещё такие устройства как замки, краны, привод ворот, которые управляются также с разных мест, разноименными сигналами, и считывание фактической битовой маски позволяет исключить одновременное закрытие и открытие крана/ворот/штор/замков и т.п.
Если есть какой-то боле простой и правильный способ это благополучно делать без чтения фактической маски выходов из модуля, мне было бы очень интересно узнать этот способ.
Объясняю ситуацию на пальцах: все выходы допустим изначально выключены, потом я с айпада включаю 5 первых выходов (свет), но контроллер об этом не знает. Тыкаю на клавишу, завязанную на плк, включить 6 выход. И плк благополучно перезаписывает весь модуль с одним включенным 6 выходом, потому что "думает", что надо включить только 6 выход, т.к. контроллером в модуль вывода я пишу по изменению модуль 32 бита. .
возможно Вы уже высказывались, но я вот не пойму, чем не устраивают регистры с 340по 363, концепция не нарушится, изменятся будет состояние только одного выхода
Ну хотя бы тем, что вместо чтения/записи четырёх регистров (2х32Bit) надо будет читать/писать 24 регистра. И вместо булевых функций оперировать числовыми. А суть останется та же, мониторим обратную связь выхода по регистру и по обратной связи конкретного регистра задаём новую уставку исходя из реальной на данный момент. Режим работы выходов надо будет перевести в ШИМ, и с другого мастера также писать числовые уставки и там также придётся поменять булевую логику на числовую.
В следствие чего такая простая конструкция типа: dword1.0:=(dword1.1 or dword2.2) and not(dword3.3); превращается в полноценное "трёхэтажное" условие.
Филоненко Владислав
27.03.2021, 17:17
Не ругайте Валенка, он дело говорит. Если есть счётчики по входам - надо их использовать, тогда правильно настроив фильтрацию по входам модулей можно и дребезга не боятся и не надо так часто опрашивать,опасаясь пропустить событие.
А можно немного подробнее почему в моём случае надо использовать счётчики и не надо так часто опрашивать? Что не так? Или что может произойти? Цикл выполняется за 2-3 мс почему бы не опрашивать каждые 10мс, если оборудование позволяет это делать? Ошибок по обмену нет, совсем, сеть для этого оборудования выделена отдельная, чисто физически между щитами проложены отдельные линии. Почему вы мне так явно навязываете счётчики? Если у меня всего по 20-50 нажатий в сутки, но случиться они могут в любое время. Почему все так усердно пытаются навязать какую-то альтернативу, которая больше, сложнее, неудобнее, а результат тот же?
Когда тогда надо использовать битовую маску входов? И есть ли какие-то критерии использования тех или иных способов учёта входящих сигналов? Я вот, допустим, думаю, что если частота входящего импульса больше 10 Гц, то следует использовать счётчики, всё что ниже - битовая маска.
Parovoz Я делаю на счётчиках весь опрос кнопок.
Кайф этого решения в том, что даже если будут потери связи, то нажатие по счётчику не потеряется никогда.
Это работает так, что даже если ткнуть на кнопку ОЧЕНЬ быстро (я - барабанщик, я могу быстро ткнуть), то нажатие всё равно отлавливается.
Я смотрю текущее число счётчика импульсов и предыдущее и сравниваю. Если разница по модулю > 1 - то было нажатие.
Дополню. Если у нас отвалилась связь (например, потеряли несколько пакетов с данными из-за лага сети), а кнопку нажимали - то потом мы всё равно про это узнаем.
Cs-Cs ну да, из-за дребезга контакта выключателя у вас пришел счетчик > на 2 - что вы должны сделать? включить свет и выключить свет или ничего не делать ? :)
melky Так я отлавливаю >1. А дальше имитирую R_TRIG, и после обработки (в задаче, может раз в 100 мсек) привожу всё в исходное состояние.
Я не знаю, как пояснить... ну, высчитали дельту по модулю. Если она > 0 - пошли в ветку обработки нажатия и что-то сделали.
И там же сказали, что countPrevious := countCurrent;, после чего дельта снова равна нулю. Так как мы это делаем после обработки, то пока идёт обработка - хоть обнажимайся - пофиг.
Поэтому если это будет ситуация вида "ни фига не было, а тут раз - и 25 импульсов", то обработается как однократное одинарное нажатие.
Если же будет так, что только-только моя задача обработала нажатие, и снова дельта > 0 - то обработает как второе нажатие.
А если подразниться - дык во всех модулях IO у ОВЕНа есть защита от дребезга, которую я всегда включаю.
Parovoz Я делаю на счётчиках весь опрос кнопок.
Кайф этого решения в том, что даже если будут потери связи, то нажатие по счётчику не потеряется никогда.
Это работает так, что даже если ткнуть на кнопку ОЧЕНЬ быстро (я - барабанщик, я могу быстро ткнуть), то нажатие всё равно отлавливается.
Я смотрю текущее число счётчика импульсов и предыдущее и сравниваю. Если разница по модулю > 1 - то было нажатие.
Дополню. Если у нас отвалилась связь (например, потеряли несколько пакетов с данными из-за лага сети), а кнопку нажимали - то потом мы всё равно про это узнаем.
Я не барабанщик, но с опросом в 10мс у меня ни разу не получилось ткнуть кнопку так, чтобы было потеряно нажатие, я это делал специально, неспециально это вообще нереально сделать. Ради интереса поставлю завтра счётчик ошибок по опросу. Чтобы проверить возникают они или нет, если за сутки не наберётся ни одной, могу констатировать метод счётчиками неоправданно сложным.
А так у меня товарищ есть с подобным подходом к делу, который вместо одного микрокомпьютера Raspberry PI воткнул два полноценных системника, запитанных от бесперебойника, на одном из которых завёл резервное копирование первого системника. После некоторой беседы о целесообразности использования средств соразмерно решаемой задаче оптимизировали состав оборудования и пришли к одной "малине" и простой флешке на которую скидываются бекапы. При этом за 3 года работы она так и не понадобилась.
Я считаю, что средства решения задачи должны быть соразмерны самой задаче. Нет смысла палить из пушки по воробьям.
Народ, хэлп ми! В общем те же груши только в профиль. Такая проблема: расшарил на контроллере 50 регистров, всё работало даже вроде неплохо, добавил ещё десяток регистров и пропала какая-либо возможность читать регистры из контроллера по модбас тср, просто ошибка при подключении и таймаут, что при чтении орс-сервером, что при чтении другим устройством, тупо нет связи, методом тыка убавлял регистры по одному, дошел обратно до 50 и все снова заработало. Таймауты и время опроса выставлял разное от 10мс до 20с толку нет.
Все регистры в одном слейв-модбас-девайсе, проект выше.
В общем сколько регистров может быть в одном слейве?
Сколько может быть слейвов? Можно ли создать несколько слейвов разбросать их по портам, адресам и в каждый подобавлять ещё регистры?
Ещё такой нюанс: при первой попытке опроса ответ приходит очень долго, а потом всё работает относительно быстро, что я сделал не так?
Почти тыща если через конфигурацию. Это - пушка по воробьям, но я из нее палю чтоб до пива добраться побыстрее.
))
Тогда я не понимаю, что происходит... При добавлении регистров свыше 50 напрочь отсутствует связь по MBTCP. Причём связь обрубается ещё на попытке создания соединения OPC-сервером, т.е. даже до запросов дело не доходит.
В общем, что бы я не пытался делать (сбрасывать плк, очищать проект, заливать другой заведомо рабочий проект) свзяи по MBTCP, где ПЛК был в роли слейва не было, при этом плк стабильно и без проблем управлял другими устройствами по MBTCP, при этом при перезаливке проекта случалось и такое, что кодесис не подключался к плк, при этом плк также работал и всем управлял. Перезагрузка по питанию также не спасала ситуацию. Приходилось сбрасывать с помощью тумблера и снова заливать.
Помогла только прошивка с 1.0.12 до актуальной. И все регистры сразу же откликнулись без задержек, ошибок и таймаутов, время ответа 20-30 мс. Добавил ещё 30 регистров, перезалил проект и новые регистры без проблем заработали.
И всё бы ничего, но при перепрошивке поменялся адрес плк, причем не на дефолтный, а на какой-то другой. что-то типа 10.0.2.11. Хоть бы в инструкции указали этот момент, а то ночь на дворе USB-кабеля нет, связи нет, тех. поддержка молчит. Что делать непонятно...
В общем ситуация вроде как решилась, что было - непонятно.
A.Simonov
16.04.2021, 10:27
В общем, что бы я не пытался делать (сбрасывать плк, очищать проект, заливать другой заведомо рабочий проект) свзяи по MBTCP, где ПЛК был в роли слейва не было, при этом плк стабильно и без проблем управлял другими устройствами по MBTCP, при этом при перезаливке проекта случалось и такое, что кодесис не подключался к плк, при этом плк также работал и всем управлял. Перезагрузка по питанию также не спасала ситуацию. Приходилось сбрасывать с помощью тумблера и снова заливать.
Помогла только прошивка с 1.0.12 до актуальной. И все регистры сразу же откликнулись без задержек, ошибок и таймаутов, время ответа 20-30 мс. Добавил ещё 30 регистров, перезалил проект и новые регистры без проблем заработали.
И всё бы ничего, но при перепрошивке поменялся адрес плк, причем не на дефолтный, а на какой-то другой. что-то типа 10.0.2.11. Хоть бы в инструкции указали этот момент, а то ночь на дворе USB-кабеля нет, связи нет, тех. поддержка молчит. Что делать непонятно...
В общем ситуация вроде как решилась, что было - непонятно.
На 129 странице в РП (https://owen.ru/uploads/249/rp_plk1hh_m02__1-ru-75044-1.32_a4.pdf) есть инфа об этом IP.
Это IP который ставится если удаляется файл сетевых настроек.
IP 10.2.11.119
GATE 10.2.1.1
MASK 255.255.0.0
На 129 странице в РП (https://owen.ru/uploads/249/rp_plk1hh_m02__1-ru-75044-1.32_a4.pdf) есть инфа об этом IP.
Это IP который ставится если удаляется файл сетевых настроек.
IP 10.2.11.119
GATE 10.2.1.1
MASK 255.255.0.0
Так а почему бы об этом не сделать краткое упоминание в инструкции по перепрошивке..? Я, как и многие не читали руководство целиком, а обращаются к нему по мере необходимости. Есть руководство по прошивке, где об этом ни слова, неужели так сложно туда добавить эту информацию, если уж вы не удосуживаетесь отвечать на звонки на вашу горячую линию 24/7?
A.Simonov
16.04.2021, 12:25
Так а почему бы об этом не сделать краткое упоминание в инструкции по перепрошивке..? Я, как и многие не читали руководство целиком, а обращаются к нему по мере необходимости. Есть руководство по прошивке, где об этом ни слова, неужели так сложно туда добавить эту информацию, если уж вы не удосуживаетесь отвечать на звонки на вашу горячую линию 24/7?
При перепрошивке на другие версии сетевые параметры не сбрасывались.
Обновим инструкцию.
UPD: Поправил инструкцию.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot