Страница 2 из 28 ПерваяПервая 123412 ... ПоследняяПоследняя
Показано с 11 по 20 из 280

Тема: Разброс во времени опроса по RS-485.

  1. #11

    По умолчанию

    Цитата Сообщение от Mike HG Посмотреть сообщение
    Интересно, почему лучше 1 мс и не стоит делать 0? В описании на модуль ничего не сказано про время ответа. Есть частота опроса 30 Гц, только не уточняется, для каждого канала или делится на 4. В техподдержке тоже озвучили цифру 20, которую они реально получили при испытаниях. У меня, если поставить период опроса 50 мс, получается 14-18. То есть от 2 до 6 запросов значения повторяются. Вообще непонятно, как в цифровых устройствах могут получаться большие разбросы временных интервалов? Кстати, у ПР200 какое минимально возможное время опроса одного регистра, есть данные? И зависит ли оно от времени цикла? Если например сложная программа и время цикла 4 мс, будет ли время опроса больше? В INT16 пробовал, почти тоже самое. При периоде опроса 100 мс мне показалось, что пропусков немного меньше, при 65 мс примерно также. Вообще этот модуль 24-х разрядный, и при передаче результатов в INT16 это преимущество теряется.
    По 1ms, описал выше. ПР200 все таки не контроллер, и опрос переменных производится в выделенный интервал времени, который еще зависит от времени цикла, и в дополнение к этому, одна переменная в каждом сеансе обмена, эти факторы необходимо учитывать.
    С уважением, Ревака Юрий.
    Инженер группы технической поддержки компании "ОВЕН"
    e-mail: yu.revaka@owen.ru

    Шаблон описания ошибки ПР или OL http://ftp-ow.owen.ru/softupdate/OWE...s/Shablon.docx
    Видео уроки по ПР200 и OWEN Logic http://edu.owen.ru/series/pr200_rev/
    Другие видеоролики по тематике ПР https://www.youtube.com/channel/UCj4...H5H3d_t6iDlQOQ

  2. #12

    По умолчанию

    Цитата Сообщение от rwg Посмотреть сообщение
    Может быть кто-то не знает, для справки. По спецификации Modbus-IDA.ORG "Modbus over serial line V1.02"для RTU на скорости выше 19200 признаком начала запроса или ответа является пауза перед посылкой первого байта более 1750 мкс. Приёмник обязан услышать запрос к нему, если была пауза более 1750мкс и не должен отвечать на него раньше, чем через 1750 мкс по окончании приёма команды. К почти всеобщему огромному сожалению, верхняя граница этой паузы не определена, чем пользуются неумелые программисты, увеличивающие задержку ответа своих устройств в десятки и сотни раз. Подобрать таймаут для таких устройств можно только путём длительных наблюдений.
    Возможно это связано с тем, что кроме возможности быстро ответить, необходимо еще что-то выдать в этот ответ, и вот то что необходимо выдать и занимает время на преобразование и расчет, и в итоге получается время ответа от 20 ms. Это я все к тому, что осциллограф из ПР200 по RS не лучшая идея.
    С уважением, Ревака Юрий.
    Инженер группы технической поддержки компании "ОВЕН"
    e-mail: yu.revaka@owen.ru

    Шаблон описания ошибки ПР или OL http://ftp-ow.owen.ru/softupdate/OWE...s/Shablon.docx
    Видео уроки по ПР200 и OWEN Logic http://edu.owen.ru/series/pr200_rev/
    Другие видеоролики по тематике ПР https://www.youtube.com/channel/UCj4...H5H3d_t6iDlQOQ

  3. #13

    По умолчанию

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

  4. #14

    По умолчанию

    Цитата Сообщение от Mike HG Посмотреть сообщение
    Все же хочется знать возможности устройства, чтобы понимать, что от него можно получить. Повторю вопрос. Какое минимально возможное время опроса одного регистра у ПР200? И как оно зависит от времени цикла?
    Я же выше описал, время самого пакета данных зависит от скорости, дальше необходимо знать за сколько модуль обработает посылку, вложит туда рассчитанные данные и вернет обратно. От времени цикла зависит не время опроса, а частота опроса. У меня нет в наличии вашего модуля для проверки, если бы он был, я бы начал с проверки с ПК ModbusPoll, подобрал бы минимальное время скана, при котором нет ошибок, и перенес бы его в ПР200, и откорректировал таймаут ответа, должен быть больше, кол-во повторов установил бы в "1". Если у Вас время цикла 4 ms, тогда нужно подбирать на месте, можно вывести ошибки обмена на экран и смотреть когда они пропадут.
    С уважением, Ревака Юрий.
    Инженер группы технической поддержки компании "ОВЕН"
    e-mail: yu.revaka@owen.ru

    Шаблон описания ошибки ПР или OL http://ftp-ow.owen.ru/softupdate/OWE...s/Shablon.docx
    Видео уроки по ПР200 и OWEN Logic http://edu.owen.ru/series/pr200_rev/
    Другие видеоролики по тематике ПР https://www.youtube.com/channel/UCj4...H5H3d_t6iDlQOQ

  5. #15

    По умолчанию

    Цитата Сообщение от Ревака Юрий Посмотреть сообщение
    Одесса, очень хорошо что вы подробно вникаете в суть вопроса, и делаете выкладки по расчетам, которых иногда очень не хватает. Но, я писал не про период опроса, а про интервал между опросами, это другой параметр и отвечает он за паузу на переключение с режима приема на передачу. А если мы говорим за период опроса, то прибавить 1ms, как Вы советуете, это будет маловато даже на 115200. Если нет данных на модуль по времени ответа, нужно подбирать.
    Хочу добавить к своей теории немного соображений из практики. Года два назад делал для своих личных нужд адаптер
    типа АС4. В адаптере использовал процессор микрочиповский 16F628 с юартом на борту и классический MAX485. Прибор опрашивал МВ110-8АС. После передачи команды ( програмно отслеживал освобождение буфера передатчика) и по его освобождении ,моментально (один такт просессора) переключался на прием. По моим наблюдениям ответные данные приходи
    ли через 13 мс после того,как переключился на прием. Учитывая результаты этого эксперимента,следующие адаптеры делал без
    применения микропроцессора. Вместо него поставил тупо 555 таймер посхеме ждущего мультивибратора,который управлял
    переключением прием-передача МАХ485. Время задающая цепочка ждущего мультивибратора 10мс. При помощи этого адаптера
    снимал информацию с ТРМ 138 без проблем. Что касается ПР 200, что могу только предполагать( реверс-инженеринг ему не де
    дал). Разработчики этого прибора Вам могут ответить через сколько времени прийдёт ответ только в том случае,если входные
    данные вызывают прерывание. Тогда можна говорить о конкретном времени ответа. Если же механизм прерывания в этом
    приборе отсутствует, то время ответа будет переменным и будет зависеть от времени цикла основной программы.

  6. #16

    По умолчанию

    Цитата Сообщение от rwg Посмотреть сообщение
    Может быть кто-то не знает, для справки. По спецификации Modbus-IDA.ORG "Modbus over serial line V1.02"для RTU на скорости выше 19200 признаком начала запроса или ответа является пауза перед посылкой первого байта более 1750 мкс. Приёмник обязан услышать запрос к нему, если была пауза более 1750мкс и не должен отвечать на него раньше, чем через 1750 мкс по окончании приёма команды. К почти всеобщему огромному сожалению, верхняя граница этой паузы не определена, чем пользуются неумелые программисты, увеличивающие задержку ответа своих устройств в десятки и сотни раз. Подобрать таймаут для таких устройств можно только путём длительных наблюдений.
    Я не понимаю одного. Как по этой спецификации передать паузу. Конец паузы это понятно -начало информационных бит,а нача
    ло где? Что является маркером начала? Первый раз слышу об этих 1750мс. А как же я раньше работал на последней стандартной
    скорости и все было чики пики, даже не предполагая таких ньансов.

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

    По умолчанию

    Цитата Сообщение от Одесса Посмотреть сообщение
    Как по этой спецификации передать паузу. Конец паузы это понятно -начало информационных бит,а нача
    ло где? Что является маркером начала? Первый раз слышу об этих 1750мс. А как же я раньше работал на последней стандартной
    скорости и все было чики пики, даже не предполагая таких ньансов.
    Не мсек, мксек. Разница в 1000 раз. Пауза начинается через 750 мкс после конца передачи последнего байта http://www.modbus.org/docs/Modbus_ov...line_V1_02.pdf

  8. #18

    По умолчанию

    Цитата Сообщение от rwg Посмотреть сообщение
    Не мсек, мксек. Разница в 1000 раз. Пауза начинается через 750 мкс после конца передачи последнего байта http://www.modbus.org/docs/Modbus_ov...line_V1_02.pdf
    Диа фрэнд,что в переводе с английского - любый друже. От Вы мне дали ссылку на чисто моем родном языке. Пролистал я
    это пе де фе. И понял,что ото Вы неправильно его перевели и тем боллее неправильно истолковали написанное. Наконец то я понял
    ,что Вы понимали под паузой в 1750мкс. Так я об этой паузе знал и раньше. Если бы об этой паузе я не знал,то вряд ли у меня получилось вести диалог с устройствами например на скорости 115200. А то Вы меня испугали и я уже был в сомнении,как же так
    спокойно работаю и не знаю как. Мне не жалко и Вам обяснить,чтоб и Вы больше никого не пугали. Если я работаю на высокой скорости,то мне плевать на эту паузу,когда я передаю команду ВУ. Я передал эту команду тупо и все. А уже ВУ само должно угадать
    закончился мой пакет или нет. И чтоб не ошибится в своих намерениях отсчитывает время молчания абонента. И если абонент за
    молчал на время о котором Вы говорите,а именно 1750мкс,то внешнее устройство истолковывает это молчание ,как признак того
    что абонент все сказал. И лишь после этого начинает обрабатывать Ваше письмо. Сколько внешнее устройство будет обрабаты
    вать Ваш пакет, сколько захочет столько и будет. Ваше дело как абонента свинячее, подставить корзину и ждать ответа. Если Вам
    повезло и Вы начали получать ответ ,запихивайте его в корзину и по мере запихивайте, следите опять же за Вашей паузой в 1750
    мкс. Если такую получили, то делайте вывод- ВУ поставило точку в ответе. Такой механизм общения характерен только для modbus
    К протоколу Овен и DCON это не относится. Начало и конец сообщений определяются маркерами,а не временными интервалами. Лично для меня,как программиста это удобнее. Но от модбаса тоже никуда не денешься. Если вы не программист,то
    у Вас вообще не должна болеть голова по этому поводу. Об этих проблемах позаботится ОРС и библиотеки. На месте человека,кото
    рый опубликовал этот вопрос и который не владеет программированием на физическом уровне я бы сделал следующее. Поставил
    бы минимальную паузу между запросами,при котором получаю достоверные данные. И всех делов.

  9. #19

    По умолчанию

    Я бы раз так сделать, да по условию задачи не проходит. 100% достоверные данные получаются при времени между запросами 130 мс, а мне надо минимум в 2 раза чаще. Я хочу понять, реле не успевает опрашивать, или модуль отдает с перебоями. Еще не так давно сопрягал ПР200 с модулем ICP, у которого период опроса 100 мс и была такая же проблема с пропусками, которые исчезали при тех же 130 мс. Наводит на размышления. Сформулирую вопрос по другому. Какое минимально возможное время опроса может обеспечить реле, при условии, что модуль будет отвечать вовремя? При времени цикла 1, 2 и 4 мс.
    Цитата Сообщение от Ревака Юрий Посмотреть сообщение
    ПР200 все таки не контроллер, и опрос переменных производится в выделенный интервал времени, который еще зависит от времени цикла, и в дополнение к этому, одна переменная в каждом сеансе обмена, эти факторы необходимо учитывать.
    Где найти подробное описание работы ПР200 по RS485, чтобы учитывать все факторы?
    Если по истечении времени опроса сетевая переменная не изменилась, можно ли узнать - модуль ответил вовремя и вернул такое же значение, или запрос (ответ) не прошел?

  10. #20

    По умолчанию

    Цитата Сообщение от Mike HG Посмотреть сообщение
    Я бы раз так сделать, да по условию задачи не проходит. 100% достоверные данные получаются при времени между запросами 130 мс, а мне надо минимум в 2 раза чаще. Я хочу понять, реле не успевает опрашивать, или модуль отдает с перебоями. Еще не так давно сопрягал ПР200 с модулем ICP, у которого период опроса 100 мс и была такая же проблема с пропусками, которые исчезали при тех же 130 мс. Наводит на размышления. Сформулирую вопрос по другому. Какое минимально возможное время опроса может обеспечить реле, при условии, что модуль будет отвечать вовремя? При времени цикла 1, 2 и 4 мс.

    Где найти подробное описание работы ПР200 по RS485, чтобы учитывать все факторы?
    Если по истечении времени опроса сетевая переменная не изменилась, можно ли узнать - модуль ответил вовремя и вернул такое же значение, или запрос (ответ) не прошел?
    Попробуйте следующее. 1. Проделайте любые сетевые манипуляции с другим прибором из серии Овен, о котором Вы говорили.
    Ecли будет та же ситуация, то на 90% есть вероятность что с ПР что то не Але. Может даже не на физическом уровне. Для
    выяснения этого запишите в ПР программу ,которая кроме обслуживания модбаса больше ничем не занимается,чтобы до миниму
    ма сократить время внутреннего цикла. И будем посмотреть.

Страница 2 из 28 ПерваяПервая 123412 ... ПоследняяПоследняя

Похожие темы

  1. ПЛК 110 и скорость опроса
    от Fudz в разделе ПЛК1хх
    Ответов: 1
    Последнее сообщение: 07.11.2013, 21:20
  2. трм251 разброс пид 30 градусов
    от Мастер бит в разделе Эксплуатация
    Ответов: 6
    Последнее сообщение: 04.07.2012, 14:40
  3. Ответов: 7
    Последнее сообщение: 30.05.2011, 09:33

Ваши права

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