Вид для печати
https://ru.wikipedia.org/wiki/Modbus ознакомтесь сколько байт нужно передать в запросе и ответе, а прогу вызывайте хоть каждую миллисекунду, пока комплит не покажет положительный фронт, запрашиваемые данные не пришли. При 110 мс если данные пришли на 111 минуте, Вы будете ждать еще 109мс чтоб их получить и обработатьЦитата:
Сообщение от SKV
Capzap, Вы не внимательно читаете, то что я пишу. Программу с обработкой ФБ модулей я предлагаю вызывать каждые 10 мс, т.е. с промежутком времени достаточным для запроса и ответа к одному модулю. Раз в 110 мс обрабатывать основную программу. Мысль моя такова - за 100 мс обрабатываю все модули, затем имея свежие данные исполняю логику управления, затем снова обрабатываю все модули и так далее.
если честно, я хотел написать одним словом ответ - бред, а теерь еще больший бред, какая разница для основной программы изменились данные или "застыли" на месте, почему она должна работать так медленно, от того что каждую цикл( в районе миллисекунды) неизмененное значение не привысит какой нибудь порог логика программы не нарушитсяЦитата:
Сообщение от SKV
Я думаю, Вы просто не вчитываетесь в идею. Могу сказать, что выполнять логику программы зная, что у меня не изменились значения входов и выходов не имеет особого смысла. Если свести пример до элементарного, то представть себе код:Цитата:
Сообщение от capzap
if IX0.0 then
делай что-то
end_if;
Исполнять его заведомо зная, что IX0.0 не мог измениться бессмысленно.
Насколько я могу судить по темам в форуме, Вы пользуетесь библиотекой modbus.lib. Расскажите как Вы организуете обмен в плане архитектуры. Какие времена циклов и периоды опроса у Вас получаются.
не забывайте что это система реального времени, следуя Вашим умозаключениям здесь 90% кода бессмысленыЦитата:
Сообщение от SKV
а опрос у меня как у всех, регулярное чтение оперативных параметров, один раз загрузка/выгрузка рецептурных параметров, при наступлении события приоритетная запись.
период опроса меня устраивает и 50мс на одно устройство
Речь идет не о бессмысленности кода, а о бессмысленности его исполнения в некоторых случаях. Так, например, выше был разговор о том, что модули МВ110-8А обновляют данные своих регистров раз в 600-900 мс на канал. Опрашивать их чаще бессмысленно, потому что мы будем получать старые значения с модуля. Здесь логика таже. Нет смысла выполнять логику управления чаще, чем изменяются входные сигналы и выдаются управляющие воздействия. Другое дело, что еще нужно учитывать общение с уровнем оператора. Но для него 110 мс выше крыши.Цитата:
Сообщение от capzap
Это чтение не вынесено в отдельную задачу?Цитата:
Сообщение от capzap
Как реализована приоритетная запись. Хотелось бы конкретней, если возможно.
как Вас конкретизировать, если Вы не приемлете бессмысленный код. Может Вы и будете получать старые значения, но тогда и об аварийной ситуации Вы узнаете не своевременно
по приоритетности изучите полезный блок семафор, выходы разных семафоров через IF...ELSIF будут распределять что выполнить в первую очередь и ни каких отдельных задач не нужно
Бессмысленно с точки зрения общей реакции системы — да. С точки зрения простоты и стабильности опрашивающего кода — нет, не бессмысленно. Покуда хватает пропускной способности, экономить на такой ерунде не стоит. Лучше равномерный опрос с «бессмысленными» чтениями, чем быстрый опрос с запинками.Цитата:
МВ110-8А обновляют данные своих регистров раз в 600-900 мс на канал. Опрашивать их чаще бессмысленно
Другое дело, если не хватает времени на опрос остальных модулей. Допустим, есть один 8АС и пять штук 8А, при этом с 8АС надо читать как можно быстрее. Естественно, в этом случае уже принимаем во внимание период обновления 8А и выстраиваем очередь вот так: 8АС - 8А_1 - 8АС - 8А_2 - 8АС - 8А_3 <...> 8А_5. Эта очередь будет проходить быстрее 500 мс, но нас это не волнует — мы просто добиваемся стабильной частоты опроса самого быстрого модуля.
Не надо бояться лишний раз что-то вызвать на ПЛК. Он под это заточен. Те же функции чтения/записи порта сделаны так, что можно обходиться вообще без таймеров и нигде ничего не выжидать. Отправили запрос, поменяли состояние автомата, на следующем проходе программы уже начинаем делать SysComRead способом накопления в буфер — пофигу, что данные ещё не пришли. Как только счётчик буфера достиг нужного значения, интерпретируем данные в буфере и сразу переводим автомат в режим отправки запроса. На очередном проходе уже вызывается SysComWrite и дальше снова всё то же самое. Быстро, просто, надёжно, пусть и не экономно в каком-то смысле.
Ожидать, что ожидаемые 10 байт ответа придут и как только придёт 10 байт- это ответ а не мусор - это очень опасно.
Надо принимать байт, сразу его логически обрабатывать (заголовочный символ, адрес и т.п.) И когда звезды в машине разбора сошлись - проверять CRC и новый запрос.
А не набираем 10 байт - вот он ответ. Возможен мусор на линии.
Самое непредсказуемое в разных Modbus Slave - это таймауты. Обработка в Slave в идеале должна делаться именно так, как Вы описали. В этом случае Slave не теряли бы ни одного запроса и могли бы вовремя ответить. Но реально так не получается, приходится экспериментальным путём подбирать в Master таймауты, многократно превосходящие стандартные.Цитата:
Сообщение от Филоненко Владислав