Страница 3 из 16 ПерваяПервая 1234513 ... ПоследняяПоследняя
Показано с 21 по 30 из 157

Тема: Конфигуратор vs modbus.lib

  1. #21
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,390

    По умолчанию

    Цитата Сообщение от SKV Посмотреть сообщение
    Запрос включает: адрес уст-ва (1 байт) + номер функции (1 байт) + адрес регистра (2 байта) + кол-во регистров (1 байт) + CRC (2 байта) = 7 байт. Ответ включает: адрес уст-ва (1 байт) + номер функции (1 байт) + данные в int (16 байт) + CRC (2 байта) = 20 байт. Итого передать по сети туда-обратно нужно 27 байт. На скорости 115200 бит/сек для этого необходимо: 27*8/115200 = 0,0019 секунды или 1,9 мс.
    https://ru.wikipedia.org/wiki/Modbus ознакомтесь сколько байт нужно передать в запросе и ответе, а прогу вызывайте хоть каждую миллисекунду, пока комплит не покажет положительный фронт, запрашиваемые данные не пришли. При 110 мс если данные пришли на 111 минуте, Вы будете ждать еще 109мс чтоб их получить и обработать
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

  2. #22
    Пользователь
    Регистрация
    10.11.2014
    Адрес
    Санкт-Петербург
    Сообщений
    646

    По умолчанию

    Capzap, Вы не внимательно читаете, то что я пишу. Программу с обработкой ФБ модулей я предлагаю вызывать каждые 10 мс, т.е. с промежутком времени достаточным для запроса и ответа к одному модулю. Раз в 110 мс обрабатывать основную программу. Мысль моя такова - за 100 мс обрабатываю все модули, затем имея свежие данные исполняю логику управления, затем снова обрабатываю все модули и так далее.

  3. #23
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,390

    По умолчанию

    Цитата Сообщение от SKV Посмотреть сообщение
    Capzap, Вы не внимательно читаете, то что я пишу. Программу с обработкой ФБ модулей я предлагаю вызывать каждые 10 мс, т.е. с промежутком времени достаточным для запроса и ответа к одному модулю. Раз в 110 мс обрабатывать основную программу. Мысль моя такова - за 100 мс обрабатываю все модули, затем имея свежие данные исполняю логику управления, затем снова обрабатываю все модули и так далее.
    если честно, я хотел написать одним словом ответ - бред, а теерь еще больший бред, какая разница для основной программы изменились данные или "застыли" на месте, почему она должна работать так медленно, от того что каждую цикл( в районе миллисекунды) неизмененное значение не привысит какой нибудь порог логика программы не нарушится
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

  4. #24
    Пользователь
    Регистрация
    10.11.2014
    Адрес
    Санкт-Петербург
    Сообщений
    646

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    если честно, я хотел написать одним словом ответ - бред, а теерь еще больший бред, какая разница для основной программы изменились данные или "застыли" на месте, почему она должна работать так медленно, от того что каждую цикл( в районе миллисекунды) неизмененное значение не привысит какой нибудь порог логика программы не нарушится
    Я думаю, Вы просто не вчитываетесь в идею. Могу сказать, что выполнять логику программы зная, что у меня не изменились значения входов и выходов не имеет особого смысла. Если свести пример до элементарного, то представть себе код:
    if IX0.0 then
    делай что-то
    end_if;
    Исполнять его заведомо зная, что IX0.0 не мог измениться бессмысленно.

    Насколько я могу судить по темам в форуме, Вы пользуетесь библиотекой modbus.lib. Расскажите как Вы организуете обмен в плане архитектуры. Какие времена циклов и периоды опроса у Вас получаются.

  5. #25
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,390

    По умолчанию

    Цитата Сообщение от SKV Посмотреть сообщение
    Исполнять его заведомо зная, что IX0.0 не мог измениться бессмысленно.
    не забывайте что это система реального времени, следуя Вашим умозаключениям здесь 90% кода бессмыслены

    а опрос у меня как у всех, регулярное чтение оперативных параметров, один раз загрузка/выгрузка рецептурных параметров, при наступлении события приоритетная запись.
    период опроса меня устраивает и 50мс на одно устройство
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

  6. #26
    Пользователь
    Регистрация
    10.11.2014
    Адрес
    Санкт-Петербург
    Сообщений
    646

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    не забывайте что это система реального времени, следуя Вашим умозаключениям здесь 90% кода бессмыслены
    Речь идет не о бессмысленности кода, а о бессмысленности его исполнения в некоторых случаях. Так, например, выше был разговор о том, что модули МВ110-8А обновляют данные своих регистров раз в 600-900 мс на канал. Опрашивать их чаще бессмысленно, потому что мы будем получать старые значения с модуля. Здесь логика таже. Нет смысла выполнять логику управления чаще, чем изменяются входные сигналы и выдаются управляющие воздействия. Другое дело, что еще нужно учитывать общение с уровнем оператора. Но для него 110 мс выше крыши.

    Цитата Сообщение от capzap Посмотреть сообщение
    а опрос у меня как у всех, регулярное чтение оперативных параметров, один раз загрузка/выгрузка рецептурных параметров, при наступлении события приоритетная запись.
    период опроса меня устраивает и 50мс на одно устройство
    Это чтение не вынесено в отдельную задачу?
    Как реализована приоритетная запись. Хотелось бы конкретней, если возможно.

  7. #27
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,390

    По умолчанию

    как Вас конкретизировать, если Вы не приемлете бессмысленный код. Может Вы и будете получать старые значения, но тогда и об аварийной ситуации Вы узнаете не своевременно
    по приоритетности изучите полезный блок семафор, выходы разных семафоров через IF...ELSIF будут распределять что выполнить в первую очередь и ни каких отдельных задач не нужно
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

  8. #28
    Пользователь
    Регистрация
    13.10.2011
    Адрес
    Златоуст
    Сообщений
    1,405

    По умолчанию

    МВ110-8А обновляют данные своих регистров раз в 600-900 мс на канал. Опрашивать их чаще бессмысленно
    Бессмысленно с точки зрения общей реакции системы — да. С точки зрения простоты и стабильности опрашивающего кода — нет, не бессмысленно. Покуда хватает пропускной способности, экономить на такой ерунде не стоит. Лучше равномерный опрос с «бессмысленными» чтениями, чем быстрый опрос с запинками.

    Другое дело, если не хватает времени на опрос остальных модулей. Допустим, есть один 8АС и пять штук 8А, при этом с 8АС надо читать как можно быстрее. Естественно, в этом случае уже принимаем во внимание период обновления 8А и выстраиваем очередь вот так: 8АС - 8А_1 - 8АС - 8А_2 - 8АС - 8А_3 <...> 8А_5. Эта очередь будет проходить быстрее 500 мс, но нас это не волнует — мы просто добиваемся стабильной частоты опроса самого быстрого модуля.

    Не надо бояться лишний раз что-то вызвать на ПЛК. Он под это заточен. Те же функции чтения/записи порта сделаны так, что можно обходиться вообще без таймеров и нигде ничего не выжидать. Отправили запрос, поменяли состояние автомата, на следующем проходе программы уже начинаем делать SysComRead способом накопления в буфер — пофигу, что данные ещё не пришли. Как только счётчик буфера достиг нужного значения, интерпретируем данные в буфере и сразу переводим автомат в режим отправки запроса. На очередном проходе уже вызывается SysComWrite и дальше снова всё то же самое. Быстро, просто, надёжно, пусть и не экономно в каком-то смысле.
    Последний раз редактировалось Yegor; 19.08.2015 в 22:03.

  9. #29

    По умолчанию

    Ожидать, что ожидаемые 10 байт ответа придут и как только придёт 10 байт- это ответ а не мусор - это очень опасно.
    Надо принимать байт, сразу его логически обрабатывать (заголовочный символ, адрес и т.п.) И когда звезды в машине разбора сошлись - проверять CRC и новый запрос.
    А не набираем 10 байт - вот он ответ. Возможен мусор на линии.
    Тролль-наседка, добрый, нежный и ласковый

  10. #30
    Пользователь
    Регистрация
    20.02.2008
    Адрес
    Тверь
    Сообщений
    505

    По умолчанию

    Цитата Сообщение от Филоненко Владислав Посмотреть сообщение
    Ожидать, что ожидаемые 10 байт ответа придут и как только придёт 10 байт- это ответ а не мусор - это очень опасно.
    Надо принимать байт, сразу его логически обрабатывать (заголовочный символ, адрес и т.п.) И когда звезды в машине разбора сошлись - проверять CRC и новый запрос.
    А не набираем 10 байт - вот он ответ. Возможен мусор на линии.
    Самое непредсказуемое в разных Modbus Slave - это таймауты. Обработка в Slave в идеале должна делаться именно так, как Вы описали. В этом случае Slave не теряли бы ни одного запроса и могли бы вовремя ответить. Но реально так не получается, приходится экспериментальным путём подбирать в Master таймауты, многократно превосходящие стандартные.

Страница 3 из 16 ПерваяПервая 1234513 ... ПоследняяПоследняя

Похожие темы

  1. Библиотеки MODBUS.LIB и OWENNET.LIB
    от desperadoes в разделе ПЛК1хх
    Ответов: 7
    Последнее сообщение: 30.01.2014, 20:15
  2. Modbus.lib и МДВВ
    от ПРОЕКТ-П в разделе ПЛК1хх
    Ответов: 11
    Последнее сообщение: 17.05.2013, 15:04
  3. Ответов: 4
    Последнее сообщение: 18.09.2012, 22:16
  4. ПЛК100 и Modbus.lib
    от Slev в разделе ПЛК1хх
    Ответов: 14
    Последнее сообщение: 19.03.2012, 08:22
  5. RTE + Modbus.lib
    от K.I.V. в разделе ПЛК3хх
    Ответов: 10
    Последнее сообщение: 09.07.2008, 10:30

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •