Просмотр полной версии : Modbas-master. Признак окончания сеанса опроса регистра.
ПЛК110. Задача последовательно опросить несколько регистров типа state одного устройства в режиме By Command.
Необходимо отследить момент окончания сеанса опроса любого из опрашиваемых регистров.
Что-то по части обнуления LastAddress перед запросом уже было здесь: http://www.owen.ru/forum/showthread.php?t=10961&highlight=LastAddress.
Однако остается непонятным сам момент появления значения адреса опрашиваемого устройства в переменной LastAddress. В "Программирование программируемых логических контроллеров ОВЕН ПЛК110 и ПЛК160. Руководство пользователя. Версия 1.9" указано:
LastAddress – адрес последнего опрошенного Modbus (Slave) устройства. Модуль запрашивает устройство, и, соответственно, тут же меняется значение: показывается значение адреса последнего запроса.
Я это понимаю так, что запись адреса в LastAddress производится одновременно с посылкой запроса, а хотелось бы иметь какой-то признак окончания запроса.
Кто, что посоветует? Или я чего-то не догоняю и LastAddress все-таки пишется уже по окончании запроса?
изучите из чего состоит сам протокол https://ru.wikipedia.org/wiki/Modbus, в ответах всегда приходит адрес ответившего устройства (как в прочем и в самом запросе есть адрес слейва) и потом уже либо данные либо ошибка
изучите из чего состоит сам протокол https://ru.wikipedia.org/wiki/Modbus, в ответах всегда приходит адрес ответившего устройства (как в прочем и в самом запросе есть адрес слейва) и потом уже либо данные либо ошибка
И что, в описании протокола есть информация о том, в какой момент производится запись адреса опрашиваемого устройства в LastAddress контроллера ПЛК110? Может забьемся на флакон мерзости типа Hennessy, что в указанной Вами ссылке эта инфа отсутствует напрочь?
я ссыль давал на протокол, а не на конфигуратор. Продолжайте дальше осваивать то, что легко можно сделать через библиотеку и даже не заморачиваясь на все стоящие перед Вами вопросы
А сколько по времени вам критично?
Ну допустим вы послали через команду, тут же запускаете таймер на 50-100мс и если за это время нет ошибки, то работаете со следующим.
Вопрос конечно хороший, интересны и другие решения.
Нету признака. По крайней мере Владислав из Овена конкретно не ответил: см. посты 2, 3, 4 в теме Конфигуратор vs modbus.lib (http://www.owen.ru/forum/showthread.php?t=21940&p=178374&viewfull=1#post178374).
я ссыль давал на протокол, а не на конфигуратор. Продолжайте дальше осваивать то, что легко можно сделать через библиотеку и даже не заморачиваясь на все стоящие перед Вами вопросы
Вы про OSCAT библиотеку?
я давно не использовал конфигуратор в качестве мастера, но раз предлагал как то следить за изменением последнего адреса и одновременно ошибки, то выходит что параметр обновляется после прихода ответа и это легко проверить если послать запрос на не подключенный прибор, по таймауты выскочит ошибка и будет ясно до этого момента уже стоял адрес запрашиваемого слейва или нет
Насколько я знаю, Last Address и Last Error для определения конца передачи бесполезны в _общем_ случае, т.е. когда нет гарантии, что на каждый слейв будет поочерёдно идти по одному запросу. Также они гарантированно бесполезны в частных случаях с одним слейвом, если я правильно понимаю, как всё это работает.
ну разве это не еще один повод перейти на библиотеку
Может быть. Только тема не об этом.
А сколько по времени вам критично?
В том-то и беда, что хочется ужаться по-минимуму. А у меня уже при идеальном распределении запросов получается сеанс до 130 мс.
Только тема не об этом.
ну тогда может стоить исходить из того что конфигуратор разрабатывал не глупый человек и раз есть переменная LastError значит анализ ведется по приходу ответа и если есть более одного опрашиваемого устройства, то определить признак можно следя за изменениями этих переменных
В том-то и беда, что хочется ужаться по-минимуму. А у меня уже при идеальном распределении запросов получается сеанс до 130 мс.
Да, event'ы должны быть по хорошему.
Вам спасибо, в принципе, то, что Вы показали - то только утвердили мои сомнения в возможности оптимизации опроса с помощью конфигуратора. Остается еще попробовать операции со строками. Они у меня раньше неплохо получались для одного-трех устройств с двумя десятками регистров. А сейчас у меня девять устройств и по два-три различных регистров. Вот и кручусь.
Так и не увидел я Ваших ответов по существу своих вопросов, как по Modbus, так и по Hennessy. Ну, а по поводу работы библиотек Modbus.lib, то года три назад, я здорово обжигался на работе с ними. Где-то у них косяк в части активации сеанса связи и здесь на форуме по этому поводу было много высказано претензий. Я проверил последнее руководство по работе с этой библиотекой. Оно нисколько не исправлено. Мне что, по новой биться головой об эту стену?
Так и не увидел я Ваших ответов по существу своих вопросов, как по Modbus, так и по Hennessy. Ну, а по поводу работы библиотек Modbus.lib, то года три назад, я здорово обжигался на работе с ними. Где-то у них косяк в части активации сеанса связи и здесь на форуме по этому поводу было много высказано претензий. Я проверил последнее руководство по работе с этой библиотекой. Оно нисколько не исправлено. Мне что, по новой биться головой об эту стену?
я написал как бы проверял признак через конфигуратор, я написал как протестировать если есть сомнение, про свой коньяк ни в первый раз небыло смешно ни второй, где Вы там нашли отсылку искать проблему, не понимаю
Филоненко Владислав
31.03.2016, 18:59
Если опрашивать разные регистры одного устройства - то признака нет. Вариантов решения несколько:
1. Опрашивать разные устройства по очереди
2. Опрашивать существующие регистры и отсутствующие регистры по очереди - тогда переход от кода ошибки к 0 - признак завершения.
3. Выставить минимальный таймаут, превышающий время ответа и если через таймаут+1мс не появилась ошибка - значит все ок.
4. Ну и хакерский трюк - взять адрес last error и по указателю туда писать не 0 перед подачей команды на обмен.
Выбирайте :)
взять адрес last error и по указателю туда писать не 0 перед подачей команды на обмен.
:)
Спасибо+++.
Powered by vBulletin® Version 4.2.3 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot