С уважением, Ревака Юрий.
Инженер группы технической поддержки компании "ОВЕН"
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
Возможно это связано с тем, что кроме возможности быстро ответить, необходимо еще что-то выдать в этот ответ, и вот то что необходимо выдать и занимает время на преобразование и расчет, и в итоге получается время ответа от 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
Все же хочется знать возможности устройства, чтобы понимать, что от него можно получить. Повторю вопрос. Какое минимально возможное время опроса одного регистра у ПР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
Хочу добавить к своей теории немного соображений из практики. Года два назад делал для своих личных нужд адаптер
типа АС4. В адаптере использовал процессор микрочиповский 16F628 с юартом на борту и классический MAX485. Прибор опрашивал МВ110-8АС. После передачи команды ( програмно отслеживал освобождение буфера передатчика) и по его освобождении ,моментально (один такт просессора) переключался на прием. По моим наблюдениям ответные данные приходи
ли через 13 мс после того,как переключился на прием. Учитывая результаты этого эксперимента,следующие адаптеры делал без
применения микропроцессора. Вместо него поставил тупо 555 таймер посхеме ждущего мультивибратора,который управлял
переключением прием-передача МАХ485. Время задающая цепочка ждущего мультивибратора 10мс. При помощи этого адаптера
снимал информацию с ТРМ 138 без проблем. Что касается ПР 200, что могу только предполагать( реверс-инженеринг ему не де
дал). Разработчики этого прибора Вам могут ответить через сколько времени прийдёт ответ только в том случае,если входные
данные вызывают прерывание. Тогда можна говорить о конкретном времени ответа. Если же механизм прерывания в этом
приборе отсутствует, то время ответа будет переменным и будет зависеть от времени цикла основной программы.
Я не понимаю одного. Как по этой спецификации передать паузу. Конец паузы это понятно -начало информационных бит,а нача
ло где? Что является маркером начала? Первый раз слышу об этих 1750мс. А как же я раньше работал на последней стандартной
скорости и все было чики пики, даже не предполагая таких ньансов.
Не мсек, мксек. Разница в 1000 раз. Пауза начинается через 750 мкс после конца передачи последнего байта http://www.modbus.org/docs/Modbus_ov...line_V1_02.pdf
Диа фрэнд,что в переводе с английского - любый друже. От Вы мне дали ссылку на чисто моем родном языке. Пролистал я
это пе де фе. И понял,что ото Вы неправильно его перевели и тем боллее неправильно истолковали написанное. Наконец то я понял
,что Вы понимали под паузой в 1750мкс. Так я об этой паузе знал и раньше. Если бы об этой паузе я не знал,то вряд ли у меня получилось вести диалог с устройствами например на скорости 115200. А то Вы меня испугали и я уже был в сомнении,как же так
спокойно работаю и не знаю как. Мне не жалко и Вам обяснить,чтоб и Вы больше никого не пугали. Если я работаю на высокой скорости,то мне плевать на эту паузу,когда я передаю команду ВУ. Я передал эту команду тупо и все. А уже ВУ само должно угадать
закончился мой пакет или нет. И чтоб не ошибится в своих намерениях отсчитывает время молчания абонента. И если абонент за
молчал на время о котором Вы говорите,а именно 1750мкс,то внешнее устройство истолковывает это молчание ,как признак того
что абонент все сказал. И лишь после этого начинает обрабатывать Ваше письмо. Сколько внешнее устройство будет обрабаты
вать Ваш пакет, сколько захочет столько и будет. Ваше дело как абонента свинячее, подставить корзину и ждать ответа. Если Вам
повезло и Вы начали получать ответ ,запихивайте его в корзину и по мере запихивайте, следите опять же за Вашей паузой в 1750
мкс. Если такую получили, то делайте вывод- ВУ поставило точку в ответе. Такой механизм общения характерен только для modbus
К протоколу Овен и DCON это не относится. Начало и конец сообщений определяются маркерами,а не временными интервалами. Лично для меня,как программиста это удобнее. Но от модбаса тоже никуда не денешься. Если вы не программист,то
у Вас вообще не должна болеть голова по этому поводу. Об этих проблемах позаботится ОРС и библиотеки. На месте человека,кото
рый опубликовал этот вопрос и который не владеет программированием на физическом уровне я бы сделал следующее. Поставил
бы минимальную паузу между запросами,при котором получаю достоверные данные. И всех делов.
Я бы раз так сделать, да по условию задачи не проходит. 100% достоверные данные получаются при времени между запросами 130 мс, а мне надо минимум в 2 раза чаще. Я хочу понять, реле не успевает опрашивать, или модуль отдает с перебоями. Еще не так давно сопрягал ПР200 с модулем ICP, у которого период опроса 100 мс и была такая же проблема с пропусками, которые исчезали при тех же 130 мс. Наводит на размышления. Сформулирую вопрос по другому. Какое минимально возможное время опроса может обеспечить реле, при условии, что модуль будет отвечать вовремя? При времени цикла 1, 2 и 4 мс.
Где найти подробное описание работы ПР200 по RS485, чтобы учитывать все факторы?
Если по истечении времени опроса сетевая переменная не изменилась, можно ли узнать - модуль ответил вовремя и вернул такое же значение, или запрос (ответ) не прошел?
Попробуйте следующее. 1. Проделайте любые сетевые манипуляции с другим прибором из серии Овен, о котором Вы говорили.
Ecли будет та же ситуация, то на 90% есть вероятность что с ПР что то не Але. Может даже не на физическом уровне. Для
выяснения этого запишите в ПР программу ,которая кроме обслуживания модбаса больше ничем не занимается,чтобы до миниму
ма сократить время внутреннего цикла. И будем посмотреть.