Просмотр полной версии : Разброс во времени опроса по RS-485.
Здравствуйте. Опрашиваю на ПР200 модуль аналогового ввода WAD-AIK-BUS компании "Акон" протокол ModBus RTU, скорость 115200, расположены рядом. Модуль имеет четыре канала, значения в формате float. Для двух каналов нужна скорость опроса минимум 15 Гц. Устанавливаю период опроса 65 мс, таймаут ответа 10 мс. Измеряю и вывожу на дисплей время между изменениями сетевой переменной для одного из каналов. От 3 до 10 запросов проходят нормально, примерно 65 мс, потом пропуск - время 130 мс. Если увеличить период опроса, то пропуски становятся реже. При 100 мс пропуски через 2-5 сек. При 130 мс пропусков нет. От количества опрашиваемых каналов не зависит. Опрашивал один к***** два и четыре - результат одинаковый. Как определить кто виноват? Реле не успевает опрашивать, модуль не успевает обновлять значения в регистрах, или я что-то не так настроил? Время цикла 1 мс. На этой же линии висит модуль МУ110-225.6У, но он пока не опрашивается, адреса разные. По идее мешать не должен.
Филоненко Владислав
07.09.2018, 08:29
Судя по временам, у вас периодически нет ответа на запрос либо ПР не успевает формировать запросы. Снифер подскажет где проблемы.
Также можно протестировать ПР с эмулятором slave на PC.
Ревака Юрий
07.09.2018, 10:40
Здравствуйте. Опрашиваю на ПР200 модуль аналогового ввода WAD-AIK-BUS компании "Акон" протокол ModBus RTU, скорость 115200, расположены рядом. Модуль имеет четыре канала, значения в формате float. Для двух каналов нужна скорость опроса минимум 15 Гц. Устанавливаю период опроса 65 мс, таймаут ответа 10 мс. Измеряю и вывожу на дисплей время между изменениями сетевой переменной для одного из каналов. От 3 до 10 запросов проходят нормально, примерно 65 мс, потом пропуск - время 130 мс. Если увеличить период опроса, то пропуски становятся реже. При 100 мс пропуски через 2-5 сек. При 130 мс пропусков нет. От количества опрашиваемых каналов не зависит. Опрашивал один к***** два и четыре - результат одинаковый. Как определить кто виноват? Реле не успевает опрашивать, модуль не успевает обновлять значения в регистрах, или я что-то не так настроил? Время цикла 1 мс. На этой же линии висит модуль МУ110-225.6У, но он пока не опрашивается, адреса разные. По идее мешать не должен.
Добрый день, нужны скрины настроек, есть еще в настройках "Интервал между запросами" его можно уменьшить до 1-2 ms, таймаут ответа лучше увеличить.
"Интервал между запросами" стоит 0. Вообще каких либо изменений от этого параметра не заметил. Таймаут ответа подобрал экспериментально - меньше 4 начинает терять данные, выше 4 никаких изменений нет. Вот скрины.
38651 38652
Ревака Юрий
07.09.2018, 15:31
"Интервал между запросами" стоит 0. Вообще каких либо изменений от этого параметра не заметил. Таймаут ответа подобрал экспериментально - меньше 4 начинает терять данные, выше 4 никаких изменений нет. Вот скрины.
38651 38652
Нулевое значение может и не стоит делать, я бы 1 ms оставил, получается Ваш модуль отвечает за ~4 ms, что в описании на него по этому поводу сказано?
Ревака Юрий
07.09.2018, 15:43
А если читать в INT16, если я правильно понял, там есть и такие регистры. Когда-то было подобное обращение по этим же модулям, у клиента около 20 выборок получалось.
Интересно, почему лучше 1 мс и не стоит делать 0? В описании на модуль ничего не сказано про время ответа. Есть частота опроса 30 Гц, только не уточняется, для каждого канала или делится на 4. В техподдержке тоже озвучили цифру 20, которую они реально получили при испытаниях. У меня, если поставить период опроса 50 мс, получается 14-18. То есть от 2 до 6 запросов значения повторяются. Вообще непонятно, как в цифровых устройствах могут получаться большие разбросы временных интервалов? Кстати, у ПР200 какое минимально возможное время опроса одного регистра, есть данные? И зависит ли оно от времени цикла? Если например сложная программа и время цикла 4 мс, будет ли время опроса больше? В INT16 пробовал, почти тоже самое. При периоде опроса 100 мс мне показалось, что пропусков немного меньше, при 65 мс примерно также. Вообще этот модуль 24-х разрядный, и при передаче результатов в INT16 это преимущество теряется.
Добрый день, нужны скрины настроек, есть еще в настройках "Интервал между запросами" его можно уменьшить до 1-2 ms, таймаут ответа лучше увеличить.
Разрешите с Вами не согласиться. Представьте себе, я поставлю интервал между как Вы рекомендуете 1mc. Скорость
115200, т.е в секунду передается 11520 байт. Для простоты расчета округляем до 10000 байт/сек. Т.е. 1 байт передается за 100
МКС. Запрос состоит,как минимум из 8 байт- 6 байтов команды+2 байта контрольной суммы. Итого 8 байт запроса. Время прохож
дения запроса = 8х100=800мкс= 0.8 мс. Служебные биты не учитываю. Т.е. время на прохождение запроса стоит на грани времени
между запросами. В результате описанная ситуация. Даллее. Нужно время для получения ответа. Рассчитываем его. Так,как формат
флоат, а это 4 байта. В ответе присутствует на 1 байт больше чем в запросе т.е. 9 байт. Всего 8+9=17 байт. На запрос и получение
ответа необходимо 17х100мкс=1700 МКС= 1.7мс. И это при условии ,что устроство ответит мгновенно. Но такого в реальной жизни
не бывает. Поэтому прибавьте ,как минимум 1мс. Получаетя,как минимум 3мс. А Вы ему собираетесь лупить запросы каждую
миллисекунду. А ,если прибор вообще задумчивый и миллисекунд 40 соображает(что похоже по описанию автора) Вот пусть автор
Вопроса и ставит свои 130мс и не морочит себе голову. Единственное решение для задающего вопрос по уменьшению времени
опроса-это разобраться с ответчиком,почему он так долго отвечает. Во многих приборах Овен, время ответа можно изменять в кон
фигураторе. Может и его устройство имеет такое свойство.
Т.е нужно сделать наоборот,как Вы советуете. Интервал между запросами увеличить, а тайм
акт ответа уменьшить.
Ревака Юрий
10.09.2018, 09:44
Разрешите с Вами не согласиться. Представьте себе, я поставлю интервал между как Вы рекомендуете 1mc. Скорость
115200, т.е в секунду передается 11520 байт. Для простоты расчета округляем до 10000 байт/сек. Т.е. 1 байт передается за 100
МКС. Запрос состоит,как минимум из 8 байт- 6 байтов команды+2 байта контрольной суммы. Итого 8 байт запроса. Время прохож
дения запроса = 8х100=800мкс= 0.8 мс. Служебные биты не учитываю. Т.е. время на прохождение запроса стоит на грани времени
между запросами. В результате описанная ситуация. Даллее. Нужно время для получения ответа. Рассчитываем его. Так,как формат
флоат, а это 4 байта. В ответе присутствует на 1 байт больше чем в запросе т.е. 9 байт. Всего 8+9=17 байт. На запрос и получение
ответа необходимо 17х100мкс=1700 МКС= 1.7мс. И это при условии ,что устроство ответит мгновенно. Но такого в реальной жизни
не бывает. Поэтому прибавьте ,как минимум 1мс. Получаетя,как минимум 3мс. А Вы ему собираетесь лупить запросы каждую
миллисекунду. А ,если прибор вообще задумчивый и миллисекунд 40 соображает(что похоже по описанию автора) Вот пусть автор
Вопроса и ставит свои 130мс и не морочит себе голову. Единственное решение для задающего вопрос по уменьшению времени
опроса-это разобраться с ответчиком,почему он так долго отвечает. Во многих приборах Овен, время ответа можно изменять в кон
фигураторе. Может и его устройство имеет такое свойство.
Т.е нужно сделать наоборот,как Вы советуете. Интервал между запросами увеличить, а тайм
акт ответа уменьшить.
Одесса, очень хорошо что вы подробно вникаете в суть вопроса, и делаете выкладки по расчетам, которых иногда очень не хватает. Но, я писал не про период опроса, а про интервал между опросами, это другой параметр и отвечает он за паузу на переключение с режима приема на передачу. А если мы говорим за период опроса, то прибавить 1ms, как Вы советуете, это будет маловато даже на 115200. Если нет данных на модуль по времени ответа, нужно подбирать.
Может быть кто-то не знает, для справки. По спецификации Modbus-IDA.ORG "Modbus over serial line V1.02"для RTU на скорости выше 19200 признаком начала запроса или ответа является пауза перед посылкой первого байта более 1750 мкс. Приёмник обязан услышать запрос к нему, если была пауза более 1750мкс и не должен отвечать на него раньше, чем через 1750 мкс по окончании приёма команды. К почти всеобщему огромному сожалению, верхняя граница этой паузы не определена, чем пользуются неумелые программисты, увеличивающие задержку ответа своих устройств в десятки и сотни раз. Подобрать таймаут для таких устройств можно только путём длительных наблюдений.
Ревака Юрий
10.09.2018, 09:51
Интересно, почему лучше 1 мс и не стоит делать 0? В описании на модуль ничего не сказано про время ответа. Есть частота опроса 30 Гц, только не уточняется, для каждого канала или делится на 4. В техподдержке тоже озвучили цифру 20, которую они реально получили при испытаниях. У меня, если поставить период опроса 50 мс, получается 14-18. То есть от 2 до 6 запросов значения повторяются. Вообще непонятно, как в цифровых устройствах могут получаться большие разбросы временных интервалов? Кстати, у ПР200 какое минимально возможное время опроса одного регистра, есть данные? И зависит ли оно от времени цикла? Если например сложная программа и время цикла 4 мс, будет ли время опроса больше? В INT16 пробовал, почти тоже самое. При периоде опроса 100 мс мне показалось, что пропусков немного меньше, при 65 мс примерно также. Вообще этот модуль 24-х разрядный, и при передаче результатов в INT16 это преимущество теряется.
По 1ms, описал выше. ПР200 все таки не контроллер, и опрос переменных производится в выделенный интервал времени, который еще зависит от времени цикла, и в дополнение к этому, одна переменная в каждом сеансе обмена, эти факторы необходимо учитывать.
Ревака Юрий
10.09.2018, 09:59
Может быть кто-то не знает, для справки. По спецификации Modbus-IDA.ORG "Modbus over serial line V1.02"для RTU на скорости выше 19200 признаком начала запроса или ответа является пауза перед посылкой первого байта более 1750 мкс. Приёмник обязан услышать запрос к нему, если была пауза более 1750мкс и не должен отвечать на него раньше, чем через 1750 мкс по окончании приёма команды. К почти всеобщему огромному сожалению, верхняя граница этой паузы не определена, чем пользуются неумелые программисты, увеличивающие задержку ответа своих устройств в десятки и сотни раз. Подобрать таймаут для таких устройств можно только путём длительных наблюдений.
Возможно это связано с тем, что кроме возможности быстро ответить, необходимо еще что-то выдать в этот ответ, и вот то что необходимо выдать и занимает время на преобразование и расчет, и в итоге получается время ответа от 20 ms. Это я все к тому, что осциллограф из ПР200 по RS не лучшая идея.
Все же хочется знать возможности устройства, чтобы понимать, что от него можно получить. Повторю вопрос. Какое минимально возможное время опроса одного регистра у ПР200? И как оно зависит от времени цикла?
Ревака Юрий
10.09.2018, 11:09
Все же хочется знать возможности устройства, чтобы понимать, что от него можно получить. Повторю вопрос. Какое минимально возможное время опроса одного регистра у ПР200? И как оно зависит от времени цикла?
Я же выше описал, время самого пакета данных зависит от скорости, дальше необходимо знать за сколько модуль обработает посылку, вложит туда рассчитанные данные и вернет обратно. От времени цикла зависит не время опроса, а частота опроса. У меня нет в наличии вашего модуля для проверки, если бы он был, я бы начал с проверки с ПК ModbusPoll, подобрал бы минимальное время скана, при котором нет ошибок, и перенес бы его в ПР200, и откорректировал таймаут ответа, должен быть больше, кол-во повторов установил бы в "1". Если у Вас время цикла 4 ms, тогда нужно подбирать на месте, можно вывести ошибки обмена на экран и смотреть когда они пропадут.
Одесса, очень хорошо что вы подробно вникаете в суть вопроса, и делаете выкладки по расчетам, которых иногда очень не хватает. Но, я писал не про период опроса, а про интервал между опросами, это другой параметр и отвечает он за паузу на переключение с режима приема на передачу. А если мы говорим за период опроса, то прибавить 1ms, как Вы советуете, это будет маловато даже на 115200. Если нет данных на модуль по времени ответа, нужно подбирать.
Хочу добавить к своей теории немного соображений из практики. Года два назад делал для своих личных нужд адаптер
типа АС4. В адаптере использовал процессор микрочиповский 16F628 с юартом на борту и классический MAX485. Прибор опрашивал МВ110-8АС. После передачи команды ( програмно отслеживал освобождение буфера передатчика) и по его освобождении ,моментально (один такт просессора) переключался на прием. По моим наблюдениям ответные данные приходи
ли через 13 мс после того,как переключился на прием. Учитывая результаты этого эксперимента,следующие адаптеры делал без
применения микропроцессора. Вместо него поставил тупо 555 таймер посхеме ждущего мультивибратора,который управлял
переключением прием-передача МАХ485. Время задающая цепочка ждущего мультивибратора 10мс. При помощи этого адаптера
снимал информацию с ТРМ 138 без проблем. Что касается ПР 200, что могу только предполагать( реверс-инженеринг ему не де
дал). Разработчики этого прибора Вам могут ответить через сколько времени прийдёт ответ только в том случае,если входные
данные вызывают прерывание. Тогда можна говорить о конкретном времени ответа. Если же механизм прерывания в этом
приборе отсутствует, то время ответа будет переменным и будет зависеть от времени цикла основной программы.
Может быть кто-то не знает, для справки. По спецификации Modbus-IDA.ORG "Modbus over serial line V1.02"для RTU на скорости выше 19200 признаком начала запроса или ответа является пауза перед посылкой первого байта более 1750 мкс. Приёмник обязан услышать запрос к нему, если была пауза более 1750мкс и не должен отвечать на него раньше, чем через 1750 мкс по окончании приёма команды. К почти всеобщему огромному сожалению, верхняя граница этой паузы не определена, чем пользуются неумелые программисты, увеличивающие задержку ответа своих устройств в десятки и сотни раз. Подобрать таймаут для таких устройств можно только путём длительных наблюдений.
Я не понимаю одного. Как по этой спецификации передать паузу. Конец паузы это понятно -начало информационных бит,а нача
ло где? Что является маркером начала? Первый раз слышу об этих 1750мс. А как же я раньше работал на последней стандартной
скорости и все было чики пики, даже не предполагая таких ньансов.
Как по этой спецификации передать паузу. Конец паузы это понятно -начало информационных бит,а нача
ло где? Что является маркером начала? Первый раз слышу об этих 1750мс. А как же я раньше работал на последней стандартной
скорости и все было чики пики, даже не предполагая таких ньансов.
Не мсек, мксек. Разница в 1000 раз. Пауза начинается через 750 мкс после конца передачи последнего байта http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
Не мсек, мксек. Разница в 1000 раз. Пауза начинается через 750 мкс после конца передачи последнего байта http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
Диа фрэнд,что в переводе с английского - любый друже. От Вы мне дали ссылку на чисто моем родном языке. Пролистал я
это пе де фе. И понял,что ото Вы неправильно его перевели и тем боллее неправильно истолковали написанное. Наконец то я понял
,что Вы понимали под паузой в 1750мкс. Так я об этой паузе знал и раньше. Если бы об этой паузе я не знал,то вряд ли у меня получилось вести диалог с устройствами например на скорости 115200. А то Вы меня испугали и я уже был в сомнении,как же так
спокойно работаю и не знаю как. Мне не жалко и Вам обяснить,чтоб и Вы больше никого не пугали. Если я работаю на высокой скорости,то мне плевать на эту паузу,когда я передаю команду ВУ. Я передал эту команду тупо и все. А уже ВУ само должно угадать
закончился мой пакет или нет. И чтоб не ошибится в своих намерениях отсчитывает время молчания абонента. И если абонент за
молчал на время о котором Вы говорите,а именно 1750мкс,то внешнее устройство истолковывает это молчание ,как признак того
что абонент все сказал. И лишь после этого начинает обрабатывать Ваше письмо. Сколько внешнее устройство будет обрабаты
вать Ваш пакет, сколько захочет столько и будет. Ваше дело как абонента свинячее, подставить корзину и ждать ответа. Если Вам
повезло и Вы начали получать ответ ,запихивайте его в корзину и по мере запихивайте, следите опять же за Вашей паузой в 1750
мкс. Если такую получили, то делайте вывод- ВУ поставило точку в ответе. Такой механизм общения характерен только для modbus
К протоколу Овен и DCON это не относится. Начало и конец сообщений определяются маркерами,а не временными интервалами. Лично для меня,как программиста это удобнее. Но от модбаса тоже никуда не денешься. Если вы не программист,то
у Вас вообще не должна болеть голова по этому поводу. Об этих проблемах позаботится ОРС и библиотеки. На месте человека,кото
рый опубликовал этот вопрос и который не владеет программированием на физическом уровне я бы сделал следующее. Поставил
бы минимальную паузу между запросами,при котором получаю достоверные данные. И всех делов.
Я бы раз так сделать, да по условию задачи не проходит. 100% достоверные данные получаются при времени между запросами 130 мс, а мне надо минимум в 2 раза чаще. Я хочу понять, реле не успевает опрашивать, или модуль отдает с перебоями. Еще не так давно сопрягал ПР200 с модулем ICP, у которого период опроса 100 мс и была такая же проблема с пропусками, которые исчезали при тех же 130 мс. Наводит на размышления. Сформулирую вопрос по другому. Какое минимально возможное время опроса может обеспечить реле, при условии, что модуль будет отвечать вовремя? При времени цикла 1, 2 и 4 мс.
ПР200 все таки не контроллер, и опрос переменных производится в выделенный интервал времени, который еще зависит от времени цикла, и в дополнение к этому, одна переменная в каждом сеансе обмена, эти факторы необходимо учитывать.
Где найти подробное описание работы ПР200 по RS485, чтобы учитывать все факторы?
Если по истечении времени опроса сетевая переменная не изменилась, можно ли узнать - модуль ответил вовремя и вернул такое же значение, или запрос (ответ) не прошел?
Я бы раз так сделать, да по условию задачи не проходит. 100% достоверные данные получаются при времени между запросами 130 мс, а мне надо минимум в 2 раза чаще. Я хочу понять, реле не успевает опрашивать, или модуль отдает с перебоями. Еще не так давно сопрягал ПР200 с модулем ICP, у которого период опроса 100 мс и была такая же проблема с пропусками, которые исчезали при тех же 130 мс. Наводит на размышления. Сформулирую вопрос по другому. Какое минимально возможное время опроса может обеспечить реле, при условии, что модуль будет отвечать вовремя? При времени цикла 1, 2 и 4 мс.
Где найти подробное описание работы ПР200 по RS485, чтобы учитывать все факторы?
Если по истечении времени опроса сетевая переменная не изменилась, можно ли узнать - модуль ответил вовремя и вернул такое же значение, или запрос (ответ) не прошел?
Попробуйте следующее. 1. Проделайте любые сетевые манипуляции с другим прибором из серии Овен, о котором Вы говорили.
Ecли будет та же ситуация, то на 90% есть вероятность что с ПР что то не Але. Может даже не на физическом уровне. Для
выяснения этого запишите в ПР программу ,которая кроме обслуживания модбаса больше ничем не занимается,чтобы до миниму
ма сократить время внутреннего цикла. И будем посмотреть.
Ревака Юрий
11.09.2018, 11:01
Я бы раз так сделать, да по условию задачи не проходит. 100% достоверные данные получаются при времени между запросами 130 мс, а мне надо минимум в 2 раза чаще.
Вы так и не ответили на каком проекте значения периода 130 ms, на "чистом" или с временем цикла 4 ms? приложите его в тему.
Я хочу понять, реле не успевает опрашивать, или модуль отдает с перебоями.
Используйте переменные статуса для модуля и переменных, для контроля обмена.
Еще не так давно сопрягал ПР200 с модулем ICP, у которого период опроса 100 мс и была такая же проблема с пропусками, которые исчезали при тех же 130 мс. Наводит на размышления. Сформулирую вопрос по другому. Какое минимально возможное время опроса может обеспечить реле, при условии, что модуль будет отвечать вовремя? При времени цикла 1, 2 и 4 мс.
Период опроса или все же время ответа, если у модуля время ответа 100ms, то и тайм аут и период опроса должны быть больше этого значения.
Время на прием одного пакета будет: время пачки на запрос+ "вовремя"+время пачки на ответ+ 3.5 симовла на соответствующей скорости.
Где найти подробное описание работы ПР200 по RS485, чтобы учитывать все факторы?
Если по истечении времени опроса сетевая переменная не изменилась, можно ли узнать - модуль ответил вовремя и вернул такое же значение, или запрос (ответ) не прошел?
В руководстве пользователя есть информация, но она не настолько глубокая, как хотелось бы. Вы так и не ответили на каком проекте значения периода 130 ms, на "чистом" или с временем цикла 4 ms? приложите его в тему.
Вы так и не ответили на каком проекте значения периода 130 ms, на "чистом" или с временем цикла 4 ms? приложите его в тему.
Так Вы об этом не спрашивали. Полный проект большой, время цикла 4 мс. Пока провожу эксперименты по получению данных на "чистом" проекте, с временем 1 мс, 130 мс на "чистом". Вот проект. Измерения делаются в циклах. С переменными статуса пробовал. Статус модуля всегда в 1. Если какой-то запрос не пройдет, он наверное падает в 0, но на следующем запросе снова встает в 1. Как увидеть 0? По статусу переменной вообще непонятно, там целое число, и у меня всегда было 0. Как с ним обращаться? Сколько кстати сохраняется статус, до следующего запроса или ответа?
Ревака Юрий
11.09.2018, 17:10
Так Вы об этом не спрашивали. Полный проект большой, время цикла 4 мс. Пока провожу эксперименты по получению данных на "чистом" проекте, с временем 1 мс, 130 мс на "чистом". Вот проект. Измерения делаются в циклах. С переменными статуса пробовал. Статус модуля всегда в 1. Если какой-то запрос не пройдет, он наверное падает в 0, но на следующем запросе снова встает в 1. Как увидеть 0? По статусу переменной вообще непонятно, там целое число, и у меня всегда было 0. Как с ним обращаться? Сколько кстати сохраняется статус, до следующего запроса или ответа?
Ок, если завтра время позволит, проверю обмен на наших модуляx расширения, по умолчанию у них время ответа 2 ms.
Ок, если завтра время позволит, проверю обмен на наших модуляx расширения, по умолчанию у них время ответа 2 ms.
После проверки отпешитесь пожалуйста. Потому ,что любопытная ситуация. Я предполагаю ,что у Овеновских модулей все
получится. Для интереса посмотрел модули ,которые автор цепляет к ПР ,так у них сложный алгоритм обработки аналогового
сигнала. Предполагаю,что этот специфический алгоритм занимает много времени и в результате такой долгий ответ. Предполагаю
также,что автор сам задал эту длительную обаботку аналогового сигнала, хотя производители этих модулей предлагают и короткую
обработку,чем автор вопроса не воспользовался. Ставлю 3 к 1.,что на Овеновских модулях все будет ОК.
С этого момента можно по подробнее? Что за длительная или короткая обработка, и где она задается?
Ревака Юрий
12.09.2018, 13:01
И так, провел серию опытов, еще вчера для быстрой проверки настроил ПР200 мастером, и через AC4 подключил к эмулятору слейва на ПК:
http://www.owen.ru/forum/attachment.php?attachmentid=38704&d=1536744201
Видно опрос 2 float, по адресу 512 и 514, так как группового запроса нет, идет 2 запроса подряд. Ставил минимальное время 10 ms, таймаут ответа поставил 100 ms. Обмен стабильный, ошибок нет.
Затем, уже сегодня подключившись анализатором, посмотрел, за какое время приходят ответы. Видно, что от ПК с симулятором ответ приходит через ~30ms, сами посылки запрос/ответ на этом фоне занимают очень мало времени, ~0,7ms. Весь пакет запроса одного регистра занимает ~35ms. Запрос на чтение следующего регистра идет через ~ 20 ms.
http://www.owen.ru/forum/attachment.php?attachmentid=38705&d=1536744784
Таким образом, за секунду получается 28 запросов.
http://www.owen.ru/forum/attachment.php?attachmentid=38706&d=1536744809
Далее, нагрузил логику до времени цикла 7ms, можем видеть, что запросы стали реже, за 1 сек. получаем 17 запросов.
http://www.owen.ru/forum/attachment.php?attachmentid=38707&d=1536744972
Сетевые настройки делал минимальными.
http://www.owen.ru/forum/attachment.php?attachmentid=38708&d=1536745101
Меняя значения и сравнивая результаты, у сделал следующие выводы:
-интервал между запросами при значениях <8ms, не оказывает влияния на обмен, т.е это минимально возможное значение
-период опроса аналогично, чаще чем 10 ms у меня не получилось опрашивать, это без логики в программе, т.е. только опрос 2 переменных.
-таймаут ответа, если значение будет низким, будут ошибки, если кол-во попыток >1, еще и перезапросы, обмен завалится. Лучше ставить с запасом 100-500 ms.
Соответственно, при времени цикла в программе 7 ms, обработка одной посылки занимает 40 ms. Прибавляем сюда немного увеличившийся период опроса, получаем около 17-18 опросов в секунду.
Далее, симулятор, заменяем реальным модулем ввода MB110-2AC, сменяем значение регистров на 264 и 267, для чистоты эксперимента, так же читаем 2 float, в модуле ставим время ответа 2 ms.
Видим, что модуль отвечает за 2,64ms, и за секунду можем сделать около 90 запросов регистров в формате float. Время одного пакета запрос/ответ ~3,5 ms.
http://www.owen.ru/forum/attachment.php?attachmentid=38710&d=1536745903
При времени цикла 7 ms, за секунду получаем ~(17-18) запросов
Надеюсь что ответил на большинство Ваших вопросов.
И так, провел серию опытов, еще вчера для быстрой проверки настроил ПР200 мастером, и через AC4 подключил к эмулятору слейва на ПК:
http://www.owen.ru/forum/attachment.php?attachmentid=38704&d=1536744201
Видно опрос 2 float, по адресу 512 и 514, так как группового запроса нет, идет 2 запроса подряд. Ставил минимальное время 10 ms, таймаут ответа поставил 100 ms. Обмен стабильный, ошибок нет.
Затем, уже сегодня подключившись анализатором, посмотрел, за какое время приходят ответы. Видно, что от ПК с симулятором ответ приходит через ~30ms, сами посылки запрос/ответ на этом фоне занимают очень мало времени, ~0,7ms. Весь пакет запроса одного регистра занимает ~35ms. Запрос на чтение следующего регистра идет через ~ 20 ms.
http://www.owen.ru/forum/attachment.php?attachmentid=38705&d=1536744784
Таким образом, за секунду получается 28 запросов.
http://www.owen.ru/forum/attachment.php?attachmentid=38706&d=1536744809
Далее, нагрузил логику до времени цикла 7ms, можем видеть, что запросы стали реже, за 1 сек. получаем 17 запросов.
http://www.owen.ru/forum/attachment.php?attachmentid=38707&d=1536744972
Сетевые настройки делал минимальными.
http://www.owen.ru/forum/attachment.php?attachmentid=38708&d=1536745101
Меняя значения и сравнивая результаты, у сделал следующие выводы:
-интервал между запросами при значениях <8ms, не оказывает влияния на обмен, т.е это минимально возможное значение
-период опроса аналогично, чаще чем 10 ms у меня не получилось опрашивать, это без логики в программе, т.е. только опрос 2 переменных.
-таймаут ответа, если значение будет низким, будут ошибки, если кол-во попыток >1, еще и перезапросы, обмен завалится. Лучше ставить с запасом 100-500 ms.
Соответственно, при времени цикла в программе 7 ms, обработка одной посылки занимает 40 ms. Прибавляем сюда немного увеличившийся период опроса, получаем около 17-18 опросов в секунду.
Далее, симулятор, заменяем реальным модулем ввода MB110-2AC, сменяем значение регистров на 264 и 267, для чистоты эксперимента, так же читаем 2 float, в модуле ставим время ответа 2 ms.
Видим, что модуль отвечает за 2,64ms, и за секунду можем сделать около 90 запросов регистров в формате float. Время одного пакета запрос/ответ ~3,5 ms.
http://www.owen.ru/forum/attachment.php?attachmentid=38710&d=1536745903
При времени цикла 7 ms, за секунду получаем ~(17-18) запросов
Надеюсь что ответил на большинство Ваших вопросов.
Спасибо Юрий за кропотливый труд и за то что подтвердили мои теоретические предположения в последнем моем посте.
К Вашему исследованию с симулятором отношусь с недоверием,т.к. показания симмулятора переносятся с головы автора этого
симмулятора на симмулятора,а что там в голове автора одному богу известно. А вот второй части Вашего исследования охотно
верю. И вывод я сделал однозначный- если ПР управляет Овеновскими ВУ ,то все в порядке. Если же к ПР цеплять ВУ других производителей,то это нужно делать с осторожностью ,вникая в их индивидуальные алгоритмы работы.
Спасибо.
Aviator_VZh
12.09.2018, 15:10
Спасибо. Юрий.
Очень интересно и познавательно.
С этого момента можно по подробнее? Что за длительная или короткая обработка, и где она задается?
Мне лень повторно поднимать документацию на Ваш прибор,но по памяти помню,что обработка аналогового входного сигнала
Вашим прибором имеет два решения. 1. Упрощённая обработка,как у Овна и сложная с разными интерполяциями и интеграциями.
И выбор делаете Вы ,между этими двумя методами,установив какой то там флажок. Я не знаю и не работал с Вашими приборами.
И не могу утверждать,что моя гипотеза верна. Но не допускаете ли Вы,что на эту интерполяцию аналогового сигнала и уходит много
времени ,которого вам не хватает для боллее частого снятия информации. Повторяю-я это не удтверждаю,а только предполагаю.
Для интереса посмотрел модули ,которые автор цепляет к ПР ,так у них сложный алгоритм обработки аналогового
сигнала. Предполагаю,что этот специфический алгоритм занимает много времени и в результате такой долгий ответ.
В моём понимании, получив запрос на содержимое ячеек, Модбас-слейв должен тут же несмотря ни на что с минимальной задержкой передать мастеру их значения. Но авторы протокола поступили мудрее и предусмотрели ситуацию, когда данные в этих ячейках ещё не готовы. В этом случае слейв вместо содержимого ячеек шлёт сообщение об ошибке 05 ACKNOWLEDGE. "Слейв принял запрос и обрабатывает его, но ему требуется много времени. Этот ответ возвращается для предупреждения ошибки тайм-аута мастера" . Или 06 SLAVE DEVICE BUSY "Слейв обрабатывает долго выполняемую команду. Мастер должен повторно передать запрос позже, когда слейв освободится"
Мне лень повторно поднимать документацию на Ваш прибор,но по памяти помню,что обработка аналогового входного сигнала
Вашим прибором имеет два решения. 1. Упрощённая обработка,как у Овна и сложная с разными интерполяциями и интеграциями.
И выбор делаете Вы ,между этими двумя методами,установив какой то там флажок. Я не знаю и не работал с Вашими приборами.
И не могу утверждать,что моя гипотеза верна. Но не допускаете ли Вы,что на эту интерполяцию аналогового сигнала и уходит много
времени ,которого вам не хватает для боллее частого снятия информации. Повторяю-я это не удтверждаю,а только предполагаю.
Кажется понял, о чем Вы. Сбила с толку Ваша терминология. Там действительно есть опции, которые можно включить - входной фильтр (стандартная фича для многих модулей, задается постоянная времени и частота среза) и полином пользователя (математическая обработка значений). Все это отключено.
В моём понимании, получив запрос на содержимое ячеек, Модбас-слейв должен тут же несмотря ни на что с минимальной задержкой передать мастеру их значения. Но авторы протокола поступили мудрее и предусмотрели ситуацию, когда данные в этих ячейках ещё не готовы. В этом случае слейв вместо содержимого ячеек шлёт сообщение об ошибке 05 ACKNOWLEDGE. "Слейв принял запрос и обрабатывает его, но ему требуется много времени. Этот ответ возвращается для предупреждения ошибки тайм-аута мастера" . Или 06 SLAVE DEVICE BUSY "Слейв обрабатывает долго выполняемую команду. Мастер должен повторно передать запрос позже, когда слейв освободится"
А в моем понимании этот механизм должен работать так. Сам являюсь автором многих микропроцессорных систем и в своих
разработках применяю следующий алгоритм решения подобных проблем.Крутиться к примру у меня какая то задача в системе. При
этом пришел любой байт из вне . Немедленно по этому прерыванию приостанавливаю выполнение основной программы и обрабатываю запрос. Выплюнув абоненту данные,продолжаю программу. При этом учитываю приоритет абонентов. И если во время ответа абонента приходит запрос боллее приоритетного абонента- прерываю сеанс с первым абонентом, обслуживаю второго абонента,потом перехожу к продолжению сеанса с первым абонентом и только после этого перехожу в основной цыкл
программы. По результатам эксперимента Юрия делаю вывод,что у Овна похожий алгоритм ответа абонента. А вот у Внешнего устройства ,который применяет автор вопроса алгоритм этот " Как хочу так и дро....делаю"
И ещё. Для таких задач применяют DSP процессоры. Эти процессоры ,в отличие от цыфровых, именно ускоряют в том числе ,обработку аналоговых сигналов. К сожалению разработчики Овна от этого далеки.
И ещё. Для таких задач применяют DSP процессоры. Эти процессоры ,в отличие от цыфровых, именно ускоряют в том числе ,обработку аналоговых сигналов. К сожалению разработчики Овна от этого далеки.
Сейчас для решения любых задач используют DSP и ARM. Лет 20 назад те же задачи решались на тогдашних процессорах. Например имитацию термометра DS1820 успешно делали сперва на atmel 89c51, потом на ATTiny15 с тактовой частотой 900 кГц при требуемом времени обработки состояния связного выхода - 3 мкс. Задача измерения 2 раза в секунду двух температур и передачи результатов измерения по Modbus загрузит самый захудалый восьмибитный процессор на 1-10% его мощности, в зависимости от способностей программиста.
Ревака Юрий
12.09.2018, 17:51
И ещё. Для таких задач применяют DSP процессоры. Эти процессоры ,в отличие от цыфровых, именно ускоряют в том числе ,обработку аналоговых сигналов. К сожалению разработчики Овна от этого далеки.
Мы говорим о разных линейках устройств, там где это необходимо, применяют DSP, там и железо и цена соответствующая.
Сейчас для решения любых задач используют DSP и ARM. Лет 20 назад те же задачи решались на тогдашних процессорах. Например имитацию термометра DS1820 успешно делали сперва на atmel 89c51, потом на ATTiny15 с тактовой частотой 900 кГц при требуемом времени обработки состояния связного выхода - 3 мкс. Задача измерения 2 раза в секунду двух температур и передачи результатов измерения по Modbus загрузит самый захудалый восьмибитный процессор на 1-10% его мощности, в зависимости от способностей программиста.
Та не что то Вы не того. Щас я Вас душить буду за слова Ваши неправдивые. 1. Время измерения температуры Ds1820 -750 mc.
Без четверти секунда. В любом букваре почитайте. И какой бы супер процессор не использовали, то по любому ему ждать прийдёт
ся и скромно молчать придется до тех пор пока эта медлительная принцеса 1820. ему температуру предоставит. Теперь вторая
Ваша врака. Процессоры о которых Вы говорите на частоте 900 кГц. Округляем до 1мгц. Следовательно на выполнение одной
элементарной команды такому процессору понадобится 4 МКС. Вопрос-о каких 3 МКС Говорите? За это время даже одну элементарную операцию не выполнит. Ни один элементарный ключ в его потрохах за такое время не поменяет своего состояния.
Ну и третья Ваша врака о том,что сейчас для решения любых задач используется DSP. Где например у Овна Вы видили его примене
ние. Хотя задач у него много,а DSP в их концепсию не вписывается.
Я не всегда верю на слово, поэтому и в корень зрю.
Та не что то Вы не того. Щас я Вас душить буду за слова Ваши неправдивые. 1. Время измерения температуры Ds1820 -750 mc.
Без четверти секунда. В любом букваре почитайте. И какой бы супер процессор не использовали, то по любому ему ждать прийдёт
ся и скромно молчать придется до тех пор пока эта медлительная принцеса 1820. ему температуру предоставит. Теперь вторая
Ваша врака. Процессоры о которых Вы говорите на частоте 900 кГц. Округляем до 1мгц. Следовательно на выполнение одной
элементарной команды такому процессору понадобится 4 МКС. Вопрос-о каких 3 МКС Говорите? За это время даже одну элементарную операцию не выполнит. Ни один элементарный ключ в его потрохах за такое время не поменяет своего состояния.
Ну и третья Ваша врака о том,что сейчас для решения любых задач используется DSP. Где например у Овна Вы видили его примене
ние. Хотя задач у него много,а DSP в их концепсию не вписывается.
Я не всегда верю на слово, поэтому и в корень зрю.
Всего 2 промаха. Речь шла не об измерении температуры, а об эмуляции протокола MicroLan (1Wire). Для приёма бита мастер на 1 мкс замыкает линию связи на 0, а эмулирующее устройство должно это обнаружить и при необходимости передачи нуля также замкнуть линию, но на большее время. Пауза после передачи каждого бита тоже 1 мкс. Всего битов 64. Во вторых у Attiny15 один такт - одна операция, правда я проверил, тактовая частота не 900 кГц, а примерно 1,6МГц, там RC-генератор. И в третьих, насчёт DSP я действительно приукрасил. Я знаком с двумя разработчиками, которые по прежнему решают свои задачи на AVR. Но тех, кто мне непонятно зачем заменил в своих проектах AVR на ARM и DSP без изменения остальных характеристик - четверо.
Мы говорим о разных линейках устройств, там где это необходимо, применяют DSP, там и железо и цена соответствующая.
Я прекрасно понимаю ,что разные линейки. Хотя могу привести пример,где эти линейки совмещены например процессор
фирмы Microchip DS30. На одном чипе и цифровой и dsp процессор. И с ценой 3-копеечной все в порядке. Я о другом почему
Овен это чудо юдо не использует, хотя обяснить можно,что приборам Овен по его функциональности такие скорости не нужны.
Если я слышу слово прибор Овен и частота 100кгц я себе говорю ОГО. Я не имею ввиду частоты задающих генераторов процес
соров в Овеновских коробочках.
Юрий, спасибо за Ваш ответ. Очень полезная информация. Главное, я убедился, что реле может работать с необходимой мне скоростью. Правда вопросы еще есть. Вы пишите:
Весь пакет запроса одного регистра занимает ~35ms. Запрос на чтение следующего регистра идет через ~ 20 ms.
35+20=55 мс. Тогда как получается 28 запросов в секунду? Да и на осцилограмме на 20 мс ни где не похоже, опечатка?
Непонятно с таймаутом ответа. Вы предлагаете ставить его больше времени опроса. Я понимаю так - если устройство отвечает вовремя, то это не имеет значения, запросы идут через установленное время, а если устройство задержало ответ, то мастер будет его ждать, и время до следующего запроса будет больше установленного периода опроса. Например - период опроса 50 мс, время ожидания ответа 100 мс, устройство ответило через 75 мс. Тогда следующий запрос пойдет сразу после ответа, и фактический период получится 75 мс, или через следующие 50 мс, и период получится 100 мс?
И остались вопросы по переменным статусов. В какой момент они обновляются, сколько времени сохраняется значение? Какие значения может принимать статус переменной и что они означают?
Я тоже провел подобный эксперимент, только в качестве Slave устройства подключил другое реле. Написал программу, которая каждый цикл изменяет значение двух сетевых переменных и попробовал их читать. У меня получилось минимальное время периода опроса 50 мс для 2-х float и 25 мс для 2-х int. Таймаут ответа у меня был 10 мс и ошибок не было. Просто при уменьшении времени периода опроса фактическое время не уменьшалось. Получается те же 12-13 мс на один регистр.
Ревака Юрий
13.09.2018, 09:59
Юрий, спасибо за Ваш ответ. Очень полезная информация. Главное, я убедился, что реле может работать с необходимой мне скоростью. Правда вопросы еще есть. Вы пишите:
35+20=55 мс. Тогда как получается 28 запросов в секунду? Да и на осцилограмме на 20 мс ни где не похоже, опечатка?
Непонятно с таймаутом ответа. Вы предлагаете ставить его больше времени опроса. Я понимаю так - если устройство отвечает вовремя, то это не имеет значения, запросы идут через установленное время, а если устройство задержало ответ, то мастер будет его ждать, и время до следующего запроса будет больше установленного периода опроса. Например - период опроса 50 мс, время ожидания ответа 100 мс, устройство ответило через 75 мс. Тогда следующий запрос пойдет сразу после ответа, и фактический период получится 75 мс, или через следующие 50 мс, и период получится 100 мс?
И остались вопросы по переменным статусов. В какой момент они обновляются, сколько времени сохраняется значение? Какие значения может принимать статус переменной и что они означают?
Тот скриншот, был для чтения из ПК, адреса 512-514, там ответ более долгий, соответственно там получится меньше запросов, а вот картинку для периода 1 сек. я видимо привел для реального прибора, сейчас уже сложно вспомнить, делал много скриншотов, может что-то не туда прилепил, или период в настройках был больше выставлен.
С тайм аутом все запутано, более менее картина ясна для простого опроса одного регистра, без повторов и с одним устройством. Если ответ приходит тайм аут заканчивается, когда ответ пришел + 3,5 символа, и он никак не влияет на период, если не ответит, возникнет пауза t мс, далее будут опрашиваться другие, если есть, устройства. Потом запрос к этому слейву повторится и опять пауза. Если установлено несколько попыток, алгоритм еще усложняется. Если подвести итог, то большой таймаут, может затормозить обмен, когда со связью проблемы.
По статусам, есть описание в РП, есть статус самого устройства на шине, белевая переменная, и есть статус переменной, там целочисленное значение, в нем могут передаваться флаги от устройства по данному запросу, пример можно посмотреть в шаблонах для модулей аналогового ввода, через данный регистр передаются состояния канала (включен, КЗ, обрыв и т.д).
Ревака Юрий
13.09.2018, 10:04
Та не что то Вы не того. Щас я Вас душить буду за слова Ваши неправдивые. 1. Время измерения температуры Ds1820 -750 mc.
Без четверти секунда.
Так же там написано, что время преобразования может быть уменьшено до 93.75, потеряв немного в точности, которой для большинства приложений хватит более чем.
Так же там написано, что время преобразования может быть уменьшено до 93.75, потеряв немного в точности, которой для большинства приложений хватит более чем.
Я это знаю. И вообще эта теория слишком теоретическая. И я давно некоторые вещи написанные в паспорте на прибор не восп
ринимаю близко к сердцу. Вот я например пишу о времени 750мс. Вы уточняете и говорите о времени 100мс. Теперь я беру крутой
электронный термометр и измеряю температуру. Допустим покаывает он температуру окружающего воздуха 25 гр. Подношу к это
му датчику спичку и жду температуры 40 он. При достижении температуры спичку убираю. Ещё секунды три после этого тепература
будет расти и потом 3 миуты понадобится для достижения первоначальной температуры. А мы с Вами говорим о миллисекундах.
Я могу быстро измерять температуру,но зачем мне это надо, если инерционность кристалла херит все мои старания.
Далеко ходить не надо. Возьмём к примеру Ваш прибор МВ110-8АС. 8 аналоговых входов. Для каждого нужно сделать преобра
зование, потом закинуть готовые данные в буфер. Для этого нужно много времени. И когда клиент по модбаса вытягивает эти дан
ные, то эти данные уже позавчерашние. И вот последний вопрошающий был очень расстроен, что данные слишком долго вытаски
каются аж 130 мс. А ему нужны данные посвежее, в чем.Вы ему и помогли. И клиенту пофиг, что данные ,вытащенные намного быс
трее,являются позавчерашние.
P.S Для меня ds1820 есть предел совершенства инженерной мысли. Веселят высказывания
некоторых участников форума,например Мелки,который хочет что то там придумать маленькое
на LM(каком то), а к ds1820 относится саркастически. Если бы даласевцы всунули в свой транзис
тор ещё и rs485, вместо шины 1wire, то все равно нашлись бы критики типа Мелки.
Aviator_VZh
13.09.2018, 14:35
Я это знаю. И вообще эта теория слишком теоретическая. И я давно некоторые вещи написанные в паспорте на прибор не восп
ринимаю близко к сердцу. Вот я например пишу о времени 750мс. Вы уточняете и говорите о времени 100мс. Теперь я беру крутой
электронный термометр и измеряю температуру. Допустим покаывает он температуру окружающего воздуха 25 гр. Подношу к это
му датчику спичку и жду температуры 40 он. При достижении температуры спичку убираю. Ещё секунды три после этого тепература
будет расти и потом 3 миуты понадобится для достижения первоначальной температуры. А мы с Вами говорим о миллисекундах.
Я могу быстро измерять температуру,но зачем мне это надо, если инерционность кристалла херит все мои старания.
Далеко ходить не надо. Возьмём к примеру Ваш прибор МВ110-8АС. 8 аналоговых входов. Для каждого нужно сделать преобра
зование, потом закинуть готовые данные в буфер. Для этого нужно много времени. И когда клиент по модбаса вытягивает эти дан
ные, то эти данные уже позавчерашние. И вот последний вопрошающий был очень расстроен, что данные слишком долго вытаски
каются аж 130 мс. А ему нужны данные посвежее, в чем.Вы ему и помогли. И клиенту пофиг, что данные ,вытащенные намного быс
трее,являются позавчерашние.
P.S Для меня ds1820 есть предел совершенства инженерной мысли. Веселят высказывания
некоторых участников форума,например Мелки,который хочет что то там придумать маленькое
на LM(каком то), а к ds1820 относится саркастически. Если бы даласевцы всунули в свой транзис
тор ещё и rs485, вместо шины 1wire, то все равно нашлись бы критики типа Мелки.
Будем считать, что еще раз прокукарекали.
Будем считать, что еще раз прокукарекали.
Тут люди рассуждают о серьезных вещах. Ищут пути решения возникших проблем. Для проявления эмоций и оскорблений
есть другие ветки о которых Вы прекрасно знаете. Вы б туда сходили и помогли человеку,который ведёт диалог сам с собой.
Хотя и Ваши эммоции не помешают.Сейчас нет дефицита туалетной бумаги. Но ваши эммоци
будут ей достойной заменой.
С тайм аутом все запутано, более менее картина ясна для простого опроса одного регистра, без повторов и с одним устройством. Если ответ приходит тайм аут заканчивается, когда ответ пришел + 3,5 символа, и он никак не влияет на период, если не ответит, возникнет пауза t мс, далее будут опрашиваться другие, если есть, устройства...
Другие устройства будут опрашиваться сразу после паузы t мс, или с начала следующего периода?
По статусам, есть описание в РП, есть статус самого устройства на шине, белевая переменная, и есть статус переменной, там целочисленное значение, в нем могут передаваться флаги от устройства по данному запросу, пример можно посмотреть в шаблонах для модулей аналогового ввода, через данный регистр передаются состояния канала (включен, КЗ, обрыв и т.д).
Посмотрел свежее РП. Ничего нового там нет.
Статус (переменной) - позволяет назначить любую целочисленную переменную (int), в которую будет записан код ошибки в случае ее появления
Где посмотреть возможные коды ошибок? В какой момент обновляется статус, как долго сохраняется значение? Можно ли с помощью статуса определить момент получения ответа? И каким образом там могут передаваться состояния канала или флаги от устройства? Если статус привязан к какому-то регистру, то он должен показывать состояние получения данных из этого регистра?
Далеко ходить не надо. Возьмём к примеру Ваш прибор МВ110-8АС. 8 аналоговых входов. Для каждого нужно сделать преобра
зование, потом закинуть готовые данные в буфер. Для этого нужно много времени. И когда клиент по модбаса вытягивает эти дан
ные, то эти данные уже позавчерашние. И вот последний вопрошающий был очень расстроен, что данные слишком долго вытаски
каются аж 130 мс. А ему нужны данные посвежее, в чем.Вы ему и помогли. И клиенту пофиг, что данные ,вытащенные намного быс
трее,являются позавчерашние.
Прибор МВ110-24/220.8АС Время опроса одного входа не более 5 мс. По идее он и по RS-485 должен отдавать с такой же частотой, иначе этот параметр не имеет смысла. Вы хотите сказать, что полученный от него вовремя ответ будет содержать значение, бывшее на входе >15 мс назад? Интересно, что на это скажет Юрий? А мне свежесть действительно пофигу. Потому что сигнал передается на ПК и записывается в массив за определенный период времени (около 1 минуты), а потом анализируется. Высокая частота опроса нужна потому, что у сигнала могут быть очень короткие всплески, и нужно поймать максимум.
Высокая частота опроса нужна потому, что у сигнала могут быть очень короткие всплески, и нужно поймать максимум.
По моему для такой задачи больше подходит ПР200. Быстро опросит, вычислит максимум и передаст в нужное время.
Прибор МВ110-24/220.8АС Время опроса одного входа не более 5 мс. По идее он и по RS-485 должен отдавать с такой же частотой, иначе этот параметр не имеет смысла. Вы хотите сказать, что полученный от него вовремя ответ будет содержать значение, бывшее на входе >15 мс назад? Интересно, что на это скажет Юрий? А мне свежесть действительно пофигу. Потому что сигнал передается на ПК и записывается в массив за определенный период времени (около 1 минуты), а потом анализируется. Высокая частота опроса нужна потому, что у сигнала могут быть очень короткие всплески, и нужно поймать максимум.
У прибора 8 входов. На опрос одного 5mc. 8- 40 mc. Прибор опрашивает все входы и результат закидывает в буфер. Вы же при запросе получаете ответ из буфера адресуемого канала. Подумайте сами,если Вы запросили сразу 8 каналов и ответ получили
к примеру за 5мс. Как можно получить ответ с 8 каналов за 5mc, если на обработку одного канала нужно 5 mc. так быстро ответ можно получить только с буфера. А Вы говорите о всплесках,которые произошли 50 мс назад. Для того,чтобы такие всплески отлавливать нужны
другие приборы.
Я просто привел пример. Ладно согласен, получилось неудачно. МВ110-224.2АС - 2 входа по 5 мс, итого 10 мс. Тоже хорошая скорость. Какой давности будут данные, считанные из регистра по RS-485?
Я не знаю сколько времени нужно для ответа,но у автора вопроса по этой ветке ,ответ был 130мс,что его не устраивало.
Юрий помог сократить время ,как я понял до 20мс. У Вас данные будут примерно такой же давновности. 5+5+5(резерв на обстоятельства) +5 на ответ. Я так предполагаю.
Mike HG вы путаете время обработки АЦП и время опроса по сети. Это совершенно разные вещи...
Сам прибор опрашивает входы по 5мс то есть все входы 5*8=40 мс это будут НОВЫЕ данные каждые 40 мс, сколько бы не занял опрос по сети, вы у себя получите те данные, которые были с меткой времени время опроса АЦП минус время опроса по сети назад ...
По моему для такой задачи больше подходит ПР200. Быстро опросит, вычислит максимум и передаст в нужное время.
Что опросит? Его собственные входы "слабоваты". Иначе зачем бы мне все эти танцы с бубном и экзотическими модулями. Сигнал может иметь значение от десятых долей мВ до примерно 8 В. Нужен АЦП не менее 16 разрядов. И как в ПР200 записать сигнал в течении минуты с дискретностью ну хотя бы 100 мс? Это 600 значений!
Ревака Юрий
14.09.2018, 09:47
Прибор МВ110-24/220.8АС Время опроса одного входа не более 5 мс. По идее он и по RS-485 должен отдавать с такой же частотой, иначе этот параметр не имеет смысла. Вы хотите сказать, что полученный от него вовремя ответ будет содержать значение, бывшее на входе >15 мс назад? Интересно, что на это скажет Юрий? А мне свежесть действительно пофигу. Потому что сигнал передается на ПК и записывается в массив за определенный период времени (около 1 минуты), а потом анализируется. Высокая частота опроса нужна потому, что у сигнала могут быть очень короткие всплески, и нужно поймать максимум.
Чем больше каналов, тем дольше надо ждать для того, чтобы получить в пакете значения всех каналов, 8 каналов*5ms, соответственно быстрее чем один раз в 40 ms нет смысла опрашивать, 1 канал 5ms. Очень короткие это сколько?
Я не знаю сколько времени нужно для ответа,но у автора вопроса по этой ветке ,ответ был 130мс,что его не устраивало.
Юрий помог сократить время ,как я понял до 20мс. У Вас данные будут примерно такой же давновности. 5+5+5(резерв на обстоятельства) +5 на ответ. Я так предполагаю.
Я и есть автор этой ветки. Юрий не помог сократить время, а лишь помог убедиться, что ПР200 способно обеспечить такую скорость. Значит вопрос к модулю. Сейчас разбираемся с ним.
У ПР200 период обновления всех 4 каналов не более 10 мс + время цикла программы, когда значения попадут в буфер + время опроса, когда вы получите значнения, которые были минус время опроса назад во времени.
Ревака Юрий
14.09.2018, 09:56
У ПР200 период обновления всех 4 каналов не более 10 мс + время цикла программы, когда значения попадут в буфер + время опроса, когда вы получите значнения, которые были минус время опроса назад во времени.
"от десятых долей мВ до примерно 8 В" вот где может быть проблема, опросить можно, но там будет шум на таких уровнях.
я ПР200 читаю датчик LM335, у него диапазон 2,315 - 3,375 В и потом масштабирую в температуру. Вполне отлично получается и очень бюджетно :)
Так что не думаю, что тут будет проблема, ну если конечно не цеплять датчик на сопли 0,22 мм2
плюс экран кабеля никто не отменял.
Чем больше каналов, тем дольше надо ждать для того, чтобы получить в пакете значения всех каналов, 8 каналов*5ms, соответственно быстрее чем один раз в 40 ms нет смысла опрашивать, 1 канал 5ms. Очень короткие это сколько?
Это я понимаю. Я просто придрался к термину Одессы "Позавчерашние данные", и уточняю, что он имеет ввиду. Сигналы выглядят примерно вот так: 38731 Вершина меньше 1 секунды. Ступеньки на графике - это как раз пропуски, или повторы. На подъеме или спуске еще не страшно, убирается сглаживанием, а если попадает на вершину, то она обрезается. В этом случае сглаживание может еще подрезать.
"от десятых долей мВ до примерно 8 В" вот где может быть проблема, опросить можно, но там будет шум на таких уровнях.
Именно здесь и проблема. 10 В/4096 шагов = дискретность 2,44 мВ. Для самых слабых сигналов мы используем 500 мВ/16 или 24 разрядов. Если сигнал растет выше, то ПР оперативно переключает предел измерения на модуле. Почему Овен не производит быстрых модулей с хорошей разрядностью?
Ревака Юрий
14.09.2018, 10:28
я ПР200 читаю датчик LM335, у него диапазон 2,315 - 3,375 В и потом масштабирую в температуру. Вполне отлично получается и очень бюджетно :)
Так что не думаю, что тут будет проблема, ну если конечно не цеплять датчик на сопли 0,22 мм2
плюс экран кабеля никто не отменял.
так тут узкий диапазон, и сигналы не мВ, тут понятно проблем не будет.
Высокая частота опроса нужна потому, что у сигнала могут быть очень короткие всплески, и нужно поймать максимум.
Сигнал может иметь значение от десятых долей мВ до примерно 8 В. Нужен АЦП не менее 16 разрядов. И как в ПР200 записать сигнал в течении минуты с дискретностью ну хотя бы 100 мс? Это 600 значений!
Не видите разницы в постановке задачи? В ходе дискуссии поступают всё новые вводные. Сперва вам был нужен только максимум обычного сигнала, теперь весь сигнал диапазоном более 60 дб, 600 значений.
Почему Овен не производит быстрых модулей с хорошей разрядностью?
Потому что эти модули производятся другими производителями и имеют нишевое применение.
Ревака Юрий
14.09.2018, 10:50
Не видите разницы в постановке задачи? В ходе дискуссии поступают всё новые вводные. Сперва вам был нужен только максимум обычного сигнала, теперь весь сигнал диапазоном более 60 дб, 600 значений.
:D аппетит растет во время еды. Где-то пол года назад ко мне обращались с примерно такой-же задачей, и кажется таким же типом модуля. Помню что тоже динамически менялся диапазон, в зависимости от поступающего сигнала на вход ПР200. Так же боролись за 20 измерений в секунду. Насколько помню, задачу решили, может конечно условия были не такие жесткие. По памяти основные моменты были в том что сигнал на переключение диапазона выдавало ПР200, и для уменьшения нагрузки на сеть, работали по флагам чтения записи.
Сигналы выглядят примерно вот так: 38731 Вершина меньше 1 секунды. Ступеньки на графике - это как раз пропуски, или повторы. На подъеме или спуске еще не страшно, убирается сглаживанием, а если попадает на вершину, то она обрезается. В этом случае сглаживание может еще подрезать.
Похоже на сигнал хроматографа. Их обычно никто по Модбасу не гоняет. Ставят 24битное АЦП, к нему собственный процессор, который управляет измерением и всё обрабатывает в реальном масштабе времени. Или хотя бы складывает в буфер для неспешной передачи наверх по Ehernet. В старинных приборах - по RS232 или RS422.
Ревака Юрий а внутри диапазона не мВ ? :)
Ревака Юрий
14.09.2018, 12:48
Ревака Юрий а внутри диапазона не мВ ? :)
Сомневаюсь, что при помощи LM выводится 3 знака после запятой, для температуры.
Причем здесь аппетит и новые вводные. Изначально был вопрос про сопряжение ПР200 с конкретным модулем и период опроса. И это и есть основная задача - как получить данные без потерь и за нужное время. Что с этими данными делается дальше, к теме отношения не имеет. Спросили - почему нужно именно так, я ответил. С возможностями реле разобрались, за это спасибо. Теперь я пытаюсь разобраться с модулем. Для этого мне нужно прояснить еще кое-какие моменты в работе ПР. Но эти вопросы почему-то игнорируются. Советуют смотреть РП, в котором ответов нет. А некоторые ответы расходятся с информацией в РП. По прежнему актуальны вопросы из постов 39 и 46.
Ревака Юрий выводить я могу и больше знаков, только зачем ? 10 мВ на градус у данного датчика, как при масштабировании скажете сколько знаков, столько и покажет. Датчик полностью аналоговый
Mike HG для задач реального времени подобная техника не предназначена.
А если брать постоянный опрос в цикле, то время опроса можно игнорировать, так как вы получите скользящее окно данный с задержкой на время опроса начиная от первого пинка.
Вам просто необходимо понять простую вещь - МВ раньше чем через 40 мс не обновит данные и даже если вы успеете их прочитать за это время дважды, вы получите те же самые значения из буфера прибора. Если вам надо быстрее - ищите другой модуль ввода аналоговых сигналов, который быстрее.
Если вам надо быстрее и обработкой занимается ПР200, смотрите когда к нему выпустят модули AI и какова будет их скорость.
На ПР модули цепляются по внутренней шине.
Ну или меняйте ПР на другое, у которого так же модули цепляются по внутренней шине.
Ревака Юрий выводить я могу и больше знаков, только зачем ? 10 мВ на градус у данного датчика, как при масштабировании скажете сколько знаков, столько и покажет. Датчик полностью аналоговый
У ПР 12-разрядный АЦП - соответственно шаг оцифровки 2,44 мВ или 0,24 градуса. Точнее не получится.
Тоже измеряю температуру с пощью реле, но от этих датчиков отказался. С термисторами на 3 кОм получается точность до 0,01 градуса.
Mike HG та для дома достаточно и такой точности, не производство же. кто ж такие датчики применяет в производстве ?
melky Вы видимо не внимательно читаете тему. Меня вполне устроит 40 мс, даже 65 нормально. И задержка в получении не пугает. Главное, чтобы данные передавались с нужной частотой и без потерь.
Ревака Юрий
14.09.2018, 14:04
Решил проверить, взял калибратор, подал на вход 0-10В сигнал с дискретностью 1 mV, параллельно завел внутренний генератор с частотой 1 сек. На каждый тик внутренней переменной, добавлял 1 mV внешнего сигнала, не всегда получалось попасть точно в такт, но до 300 mV дошел, результаты прикрепляю. С дискретностью 1-2 mV легко регистрируется изменения сигнала.
Ревака Юрий
14.09.2018, 14:13
Причем здесь аппетит и новые вводные. Изначально был вопрос про сопряжение ПР200 с конкретным модулем и период опроса. И это и есть основная задача - как получить данные без потерь и за нужное время. Что с этими данными делается дальше, к теме отношения не имеет. Спросили - почему нужно именно так, я ответил. С возможностями реле разобрались, за это спасибо. Теперь я пытаюсь разобраться с модулем. Для этого мне нужно прояснить еще кое-какие моменты в работе ПР. Но эти вопросы почему-то игнорируются. Советуют смотреть РП, в котором ответов нет. А некоторые ответы расходятся с информацией в РП. По прежнему актуальны вопросы из постов 39 и 46.
Вопросы игнорируются по причине того, что на них уже есть ответы в документации, более глубоко лезть в тайминги обмена, просто нет времени, какие значение может принимать тот или иной бит статуса, можно проверить открыв лоджик и посмотрев какой тип переменной назначается в данном конкретном окне. Что касается состояния канала и их значения, то это поддерживается на уровне модулей ввода МВ, и кажется не для всех, в РЭ на МВ описаны все состояния и значения кодов, есть даже соответствующий макрос, но это работает с модулями которые отдают эти значения, есть еще универсальные ошибки Modbus, эти значения есть в описании на протокол.
Вот вот, если прибор выдает в какой-то переменной ошибку, или в самом float ее генерит, когда ошибка. + статус + ошибки Modbus.
сделайте макрос со счетчиком на увеличение и поставьте на опрос на Н-ное время. Если счетчики будут тикать, значит происходили ошибки.
Сомневаюсь, что при помощи LM выводится 3 знака после запятой, для температуры.
Господа о каких 3 знаках идёт речь? Из любопытства нырнул в букварь по LM335. Так там погрешность 1 градус Цельсия
на весь диапазон измерения. И диапазон весь 100 градусов.
Господа о каких 3 знаках идёт речь? Из любопытства нырнул в букварь по LM335. Так там погрешность 1 градус Цельсия
на весь диапазон измерения. И диапазон весь 100 градусов.
Спросите у господ, чем погрешность отличается от разрешения. Я подозреваю, что версий будет немного.
Одесса, ну будет датчик показывать 25,358 градусов, когда реальные 24,783 и че ?
Одесса, ну будет датчик показывать 25,358 градусов, когда реальные 24,783 и че ?
Та ни че. Как в врал на 0,999 градуса + -. 0,001 градуса так и будет врать.
Одесса в не видели как Pt1000 врет на овеновских ПЛК, до 6 градусов как с куста.... так что дешево и сердито подойдет и такой датчик.
у DS18B20 если что точность +-0,5 гр.
Aviator_VZh
14.09.2018, 22:07
... Pt1000 врет на овеновских ПЛК, до 6 градусов как с куста....
А можно, пожалуйста, поподробнее. Это на краю диапазона? У меня в проекте на ПР200 заложен Pt1000 и я очень рассчитывал на 1 градус для комнатной температуры.
Одесса в не видели как Pt1000 врет на овеновских ПЛК, до 6 градусов как с куста.... так что дешево и сердито подойдет и такой датчик.
у DS18B20 если что точность +-0,5 гр.
Мелки не против lLM. А вот насчёт DS Вы малость недоинформированы. Работает он по двум алгоритма. По первому алгоритму
0,5 по второму 0,1 он. Разница во времени измерения 90мс. и 750мс. и
Был неделю в отпуске. Теперь вышел и продолжил опыты с модулем. Выяснил, что модуль отвечает стабильно за 20 мс, ошибок в ответах нет. Есть только повторы, то есть не обновляются значения в регистрах. Но с ПР тоже не все гладко. Отладил небольшую тестовую прошивку со временем цикла 1 мс, получил 15-18 запросов в секунду, жить можно. Начал постепенно добавлять в прошивку разные функции и заметил, что скорость опроса начинает падать. С добавлением 2-3 логических элементов падает до 13-16 в секунду, а с добавлением одного таймера сразу упала до 8-10 запросов в секунду. Долго разбирался, пытаясь понять зависимость, а потом добавил сразу большой узел, время цикла увеличилось до 2 мс и скорость опроса выросла до 18-19 в секунду. Это что же получается? Если сложность прошивки укладывается в какой-то период, а на опрос интерфейса времени не остается, то идет зарубание опроса?
Ревака Юрий
27.09.2018, 11:05
Про это я и писал в начале темы, что если программа усложняется и растет время цикла, то обмен будет происходить в выделенные временные промежутки.
Не представляю, чем можно его озадачить, чтобы получить время цикла 15 мс? Я пока дошел только до 4, и в схеме уже можно заблудиться. Юрий где-то писал, что на запрос выделяется часть времени цикла. Время 1 мс, допустим на обработку схемы тратится 0,5 мс, остальное время он ждет или работает с интерфейсами. Что можно успеть за это время? Если не успел, то продолжает в следующий цикл. А если на схему тратится 0,9 мс, то на интерфейс вообще ничего не остается? Когда на схему тратится 1,2 мс, то увеличивается время цикла до 2 мс. И тогда на работу с интерфейсами выделяется 0,8 мс времени. И скорость возрастает. Я алгоритм примерно так представляю. При 15 мс наверное и групповой запрос существенно не улучшит ситуацию. Мне кажется, что на работу с интерфейсами нужно выделять фиксированное количество времени, и если времени цикла не хватает - увеличивать его, даже если основная схема этого не требует. А при большом времени цикла выделять периоды внутри цикла.
Про это я и писал в начале темы, что если программа усложняется и растет время цикла, то обмен будет происходить в выделенные временные промежутки.
Так почему эти временные промежутки уменьшаются в разы при относительно небольшом усложнении программы, пока время цикла не выросло, и резко уменьшаются, если 1 мс прибавилась?
Ревака Юрий
27.09.2018, 11:58
Так почему эти временные промежутки уменьшаются в разы при относительно небольшом усложнении программы, пока время цикла не выросло, и резко уменьшаются, если 1 мс прибавилась?
Этот момент не понятен пока, не сталкивался с подобным, а какие именно блоки добавляются?
Например ТР (Импульс включения заданной длительности).
Ревака Юрий
27.09.2018, 12:29
Например ТР (Импульс включения заданной длительности).
Так и думал, и времена наверное минимальные?
Время от 20 до 250 мс. И что не так? Влияет сам факт добавления блока. Не зависимо от того запускается он или нет.
Ревака Юрий
27.09.2018, 13:40
Время от 20 до 250 мс. И что не так? Влияет сам факт добавления блока. Не зависимо от того запускается он или нет.
Думал, может установлены минимальные значения. То что блок не запущен, не значит что он не оказывает влияния на время цикла, при старте программы время рассчитывается исходя из худших условий, благодаря этому получаем время цикла независимое от того запущен узел логики или нет, как-то так, возможно и таймер так считается, и так как его минимальное время 1ms, то это влияет на общий цикл, а это время в свою очередь на обмен по сети. Этот момент требует уточнения.
Возможно Вы не поняли. У меня ПР200 мастер опрашивает один модуль. Частота опросов падает у мастера по мере усложнения программы. Когда программа усложняется настолько, что время цикла увеличивается на 1 мс - частота опросов восстанавливается. При дальнейшем усложнении программы все повторяется. По крайней мере до 4 мс. Влияют как раз таймеры и счетчики. Описывал выше, что при добавлении одного блока частота опросов уменьшалась почти в 2 раза.
Какой период запросов стоит на мастере?
65535 мс.:) Переменную "Запуск чтения" ставлю в 1. Запросы идут с минимально возможным периодом.
Как измеряете частоту ответов?
Считываю сетевую переменную, сравниваю ее с нулем, если не равна нулю, значит пришел ответ, запоминаю результат, переменную обнуляю. Замеряю количество циклов между ответами, умножаю на время цикла. Отдельно считаю количество ответов за 1 сек. Засекаю по внутренним часам. Все результаты вывожу на дисплей.
Вообще-то добавление блока не может заметно изменить время цикла.
Реле устанавливает время цикла в зависимости от сложности программы с дискретностью 1 мс. Поэтому по мере добавления элементов время цикла не меняется, а потом с добавлением очередного элемента сразу увеличивается на 1. А вот период опроса с добавлением элементов возрастает, почти пропорционально. На самой границе, когда до увеличения времени цикла остается добавить один элемент - вообще зависает!
Думаю попадают, просто не понимают в чем дело. Когда я только начинал использовать в ПР 485 интерфейс, у меня было подобное. Без всякой видимой причины останавливался опрос. Мог проработать 30 сек, а мог несколько часов. Обращался в техподдержку, ничего конкретного не посоветовали. Заменить интерфейс, проверить все соединения, отключить все внешние устройства и подключать по одному, использовать экранированную витую пару для соединений (на длине линии 10 см:)). Если не поможет, отправить устройство в сервисный центр. Потом само рассосалось.
Период запроса именно такой. 38917 Поставил максимально возможное значение. Запросами управляю с помощью флага "Запуск чтения" переменная R_2. Это запрос конкретного регистра по требованию. Как я понял - исполняется немедленно при установке в 1 и имеет приоритет перед запросами по расписанию. При постоянной 1 запросы идут один за другим без всяких таймаутов. удобная функция, когда с одного устройства нужно запрашивать несколько регистров с разным периодом.
Ревака Юрий
28.09.2018, 07:42
65535 мс.:)
Считываю сетевую переменную, сравниваю ее с нулем, если не равна нулю, значит пришел ответ, запоминаю результат, переменную обнуляю. Замеряю количество циклов между ответами, умножаю на время цикла. Отдельно считаю количество ответов за 1 сек. Засекаю по внутренним часам. Все результаты вывожу на дисплей.
А она точно должна быть "0" если ответ не пришел? Не знаю как у Вас меняется сигнал, но для float можно попробовать сравнивать на неравенство предыдущему значению.
Если я ее обнуляю, то она 0. Способ работает. Поначалу пытался сравнивать с предыдущим. Для float нет функции сравнения на равенство. Приходится преобразовывать в int и использовать функцию EQ. При преобразовании в int отрезается дробная часть. А если сигнал меняется в 4 или 5 знаке после запятой? Значит сначала нужно умножить на 100000. И еще в начале темы я уже писал, что у меня модуль не всегда вовремя обновляет данные в регистре, и я просто на очередной запрос получаю такое же значение, и спрашивал, как с этим разобраться. Таким способом я не могу определить - не пришел ответ, или пришел с таким же значением. Теперь момент ответа фиксируется четко. Для измерения сделал на втором ПР "генератор сигнала". С помощью ЦАП на аналоговом выходе сигнал постоянно меняется в заданном диапазоне. Либо смотрю шумы модуля. При 24 разрядном АЦП и отключенных фильтрах в 4-5 знаке шумит очень хорошо.
Ревака Юрий
28.09.2018, 09:43
Если я ее обнуляю, то она 0. Способ работает. Поначалу пытался сравнивать с предыдущим. Для float нет функции сравнения на равенство. Приходится преобразовывать в int и использовать функцию EQ. При преобразовании в int отрезается дробная часть. А если сигнал меняется в 4 или 5 знаке после запятой? Значит сначала нужно умножить на 100000. И еще в начале темы я уже писал, что у меня модуль не всегда вовремя обновляет данные в регистре, и я просто на очередной запрос получаю такое же значение, и спрашивал, как с этим разобраться. Таким способом я не могу определить - не пришел ответ, или пришел с таким же значением. Теперь момент ответа фиксируется четко. Для измерения сделал на втором ПР "генератор сигнала". С помощью ЦАП на аналоговом выходе сигнал постоянно меняется в заданном диапазоне. Либо смотрю шумы модуля. При 24 разрядном АЦП и отключенных фильтрах в 4-5 знаке шумит очень хорошо.
Не обязательно переводить в INT, как раз свойство float и поможет отличать старые значения от новых, нашел пример, делал расчет времени преобразования для модуля расширения, основан как раз на алгоритме задания нарастающего сигнала, момент преобразования фиксируется на fGT.
fGT - Сравнение на большее значение. Будет работать, только если сигнал будет изменятся в одну сторону - увеличиваться или уменьшаться. Но он же не может меняться до бесконечности, в конце концов выйдет за пределы диапазона. Поэтому я его меняю периодически вверх - вниз. С шумами тоже не прокатит.
Не про этот период спрашивал в настройках абонента (тут он неважен), а про тот что в общих свойствах мастера. "1" действительно включает приоритет, тоже этим пользуюсь, для регистров по которым неважно постоянно читать или надо читать по условию.
В общих свойствах мастера нет периода. Если Вы про интервал между запросами, то у меня там 0. Юрий здесь писал, что меньше 8 разницы нет, типа ограничения на уровне железа.
А как этот эффект может зависеть от количества абонентов? Может Вы просто не боролись за высокую частоту опроса?
Ревака Юрий
28.09.2018, 10:48
fGT - Сравнение на большее значение. Будет работать, только если сигнал будет изменятся в одну сторону - увеличиваться или уменьшаться. Но он же не может меняться до бесконечности, в конце концов выйдет за пределы диапазона. Поэтому я его меняю периодически вверх - вниз. С шумами тоже не прокатит.
Так меняйте его достаточно медленно, главное регистрировать изменение, как раз на возрастание я и работал. Но опять таки, если Вы пишите что модуль долго обновляет значения в регистре, тогда надо там что-то ускорить, ПР никак эту проблему не решит.
Ревака Юрий
28.09.2018, 10:49
Это новость... буду знать. Разницы и не было. Есть гипотеза что обсуждаемый эффект есть только если абонент один. У меня было множество вариаций и не попадал на подобное, но всегда был не один абонент.
Да, тогда работал именно с одним абонентом на шине. При наличии нескольких, возможно картина будет иная.
Так меняйте его достаточно медленно, главное регистрировать изменение, как раз на возрастание я и работал. Но опять таки, если Вы пишите что модуль долго обновляет значения в регистре, тогда надо там что-то ускорить, ПР никак эту проблему не решит.
не знаю всей "кухни" ОЛ, но если для сравнения вещественных использовать следующую дичь: принять как целочисленное и прогнать его через XOR с предыдущим значением, если будет единица в любом из разрядов или целочисленное больше нуля, значит можно фиксировать изменение
А как целочисленное прогнать через XOR? Оно туда не лезет!
Так меняйте его достаточно медленно, главное регистрировать изменение, как раз на возрастание я и работал. Но опять таки, если Вы пишите что модуль долго обновляет значения в регистре, тогда надо там что-то ускорить, ПР никак эту проблему не решит.
У меня скорость опроса 15 раз в секунду. Соответственно менять надо не реже. В конце концов я уже объяснил, почему я делаю именно так. Если надо поймать изменение float, то есть простой способ, я им тоже пользуюсь, когда нужно. 38932 Сейчас речь не о способе регистрации изменений и не о моем модуле, а о том, что в ПР200 выявлен существенный косяк в работе RS-485.
А как целочисленное прогнать через XOR? Оно туда не лезет!
От чего же?
Прекрасно "лезет"
38934
...в ПР200 выявлен существенный косяк в работе RS-485.
который проявляется только у Вас? Лог снифера можете приложить, где будут видны запросы-ответы с метками времени при всех этапах добавления блоков в проект
От чего же?
Прекрасно "лезет"
38934
Тогда я не понял.:confused: XOR - это исключающее ИЛИ. А что это такое у Вас?
У меня нет снифера. Все делаю на ПР его же средствами. Это становится заметно, когда борешься за высокую и стабильную частоту опроса.
Тогда я не понял.:confused: XOR - это исключающее ИЛИ. А что это такое у Вас?
Битовые элементы работают и с целочисленными ,выполняя побитывые операции .
Тогда я не понял.:confused: XOR - это исключающее ИЛИ. А что это такое у Вас?
У меня, верней в ОЛ, - по битный XOR, как и в других языках программирования
12345 == 11000000111001
12346 == 11000000111010
11000000111001 XOR 11000000111010 = 11 или 3 в дес.
У меня нет снифера. Все делаю на ПР его же средствами. Это становится заметно, когда борешься за высокую и стабильную частоту опроса.
так может не надо бороться, может все Ваши действи, ловли не понятно чего и приводят к искуственно созданным задержкам. Что значит нет снифера, RS485 позволяет держать на шине несколько устройств, подцепитесь к этой сети через конвертер с ПК и слушайте что в порту происходит, а ПР и модуль пусть работают так, как им положено, а не под "нагрузочным тестом"
Не нашел у себя в OL версия 1.12 такой функции. Есть только XOR, который работает с булевскими сигналами.
Не нашел у себя в OL версия 1.12 такой функции. Есть только XOR, который работает с булевскими сигналами.
Отдельного элемента нет ,те что есть универсальные ...Что подадите так и работает
В смысле у меня нет на ПК программы, которая может слушать и выводить результаты. Надо искать, разбираться. ПР вполне способно с помощью простеньких макросов измерить все, что нужно, и вывести результаты на дисплей. Не думаю, что будет существенная разница с ПК. В начале темы я задавал вопросы, как определить кто косячит реле или модуль. Юрий предоставил результаты измерений, которые показали, что реле способно обеспечивать нужную мне скорость. Я тоже провел подобные измерения, подтвердил эти результаты для себя. Стал разбираться с модулем. Определил его возможности и косяки. Научился опрашивать с нужной мне частотой и приемлемым количеством ошибок на "голом" реле. А когда начал реализовывать основную программу - все посыпалось. Как я уже писал, на каком-то этапе незначительные изменения в программе стали приводить к значительным изменениям в скорости опроса в обе стороны. Долго не мог понять зависимость. Потом взялся с самого начала. Постепенно добавлял элементы в программу, делал измерения и выявил данный эффект.
второй пост темы по содержанию идентичен моему предложению, давно можно было поставить и разобраться
Отдельного элемента нет ,те что есть универсальные ...Что подадите так и работает
Спасибо, дошло. В справке об этом ничего нет. Сам бы ни за что не догадался.
второй пост темы по содержанию идентичен моему предложению, давно можно было поставить и разобраться
Ну сейчас это уже не актуально. Уже разобрался. Способ значения не имеет.
Возникает вопрос, что с этим делать? Будут ли производители принимать какие-то меры по устранению проблемы?
Какой проблемы? Где то обещана гарантированная частота опроса?
Ну да. Если так рассуждать, то ни кто не гарантирует работу интерфейса вообще. Как можно гарантировать работу, если не нормированы основные параметры? Если функция заявлена, и за ее наличие берутся деньги, значит она должна обеспечивать хотя бы средние параметры, на уровне переферийных устройств того же производителя. Как минимум работать стабильно.
Ревака Юрий
01.10.2018, 13:07
Ну да. Если так рассуждать, то ни кто не гарантирует работу интерфейса вообще. Как можно гарантировать работу, если не нормированы основные параметры? Если функция заявлена, и за ее наличие берутся деньги, значит она должна обеспечивать хотя бы средние параметры, на уровне переферийных устройств того же производителя. Как минимум работать стабильно.
Так интерфейс работает, вот тема http://www.owen.ru/forum/showthread.php?t=25978 на готовые шаблоны для работы с устройствами производителя, так же нет никаких проблем при работе с устройствами других производителей. Ваша задача специфическая, одновременно "выжать" из ПР быстродействие по RS и сложный алгоритм не получится.
Получается, только при помощи танцев с бубном. Еще раз. Проблемы начинаются при совсем несложном алгоритме (опрос двух каналов, проверка на повторяемость полученных значений, переключение пределов измерения, измерение периода опроса, вывод результатов на дисплей), когда сложность близка к изменению времени цикла с 1 мс на 2 мс. На этом уровне буквально с каждым добавляемым элементом частота опроса падает вплоть до зависания и полной остановки! Как только сложность возрастает настолько, что реле увеличивает время цикла - частота опроса восстанавливается до максимума. При дальнейшем увеличении сложности программы процесс повторяется. Можно это назвать правильной работой?
Повторяю вопрос - а где гарантировали время опроса?
Ревака Юрий
01.10.2018, 15:39
Получается, только при помощи танцев с бубном. Еще раз. Проблемы начинаются при совсем несложном алгоритме (опрос двух каналов, проверка на повторяемость полученных значений, переключение пределов измерения, измерение периода опроса, вывод результатов на дисплей), когда сложность близка к изменению времени цикла с 1 мс на 2 мс. На этом уровне буквально с каждым добавляемым элементом частота опроса падает вплоть до зависания и полной остановки! Как только сложность возрастает настолько, что реле увеличивает время цикла - частота опроса восстанавливается до максимума. При дальнейшем увеличении сложности программы процесс повторяется. Можно это назвать правильной работой?
За этот момент уточню.
Повторяю вопрос - а где гарантировали время опроса?
Вы имеете отношение к производителю? Я Вам уже ответил в посте 129.
Ревака Юрий
01.10.2018, 17:15
Уточнил, действительно, данная особенность присутствует, связана с внутренними механизмами автоподстройки времени цикла программы, и работы всей многозадачной системы в целом.
То есть это просто особенность, о которой тактично умалчивается и проблемой не признается? Соответственно никаких мер принимать не планируется?
То есть это просто особенность, о которой тактично умалчивается и проблемой не признается? Соответственно никаких мер принимать не планируется?
а какие сложности, сперва отработайте логику программы, для этого специально введен режим симуляции, а потом уже готовый проект "обкатывайте" с внешними связями. Вы ведь не утверждаете, что запрос при одном состоянии наполнения программы не стабильный
Некоторые сложности имеются. Примерно так и делал. Как я уже писал, алгоритм опроса двух каналов с небольшой обработкой и отправкой команд на переключение пределов измерения модуля уже приводит к увеличению цикла на 1 мс. И при составлении и поэтапной отладке проходит все стадии от беспроблемной работы до неудовлетворительной. И вот представьте ситуацию, в предварительно отлаженный проект начинаю добавлять работу с модулем. Добавил операцию - работает нормально, добавил следующую - работает. Попутно приходится корректировать основной проект. На каком-то этапе начинаются перебои в связи. Начинаю разбираться. Естественно, что если до этого работало нормально, а добавленный фрагмент небольшой и время цикла не изменилось, то автоматом начинаю разбираться с добавленным фрагментом и с его интеграцией в проект. И небольшие изменения приводят то к улучшению, то к ухудшению ситуации, а зависимость выявить не удается. А тут еще представитель техподдержки приводит пример, что реле вполне способно работать с нужной мне скоростью и даже с запасом, при времени цикла 7 мс скорость немного падает, но в мои требования укладывается. Я то думаю, что с моими 4 мс цикла вообще все должно летать, а оно то летает, то начинает ползать. О специфической "особенности" умалчивается. Зато начинаются намеки, дескать модуль не той системы и вообще я хочу слишком много. В результате почти трех недель разбирательств докопался до сути, а оказывается да, есть такая "особенность", так и должно быть. Вот сейчас отлаженный проект с опросом попадает в неудачный диапазон. Время цикла 4 мс. Убираешь небольшую часть схемы - работает как надо, когда задействовано все, что нужно - работает на троечку. И что делать? Нагружать проект бесполезными узлами, чтобы дотянуть время цикла до 5 мс?
А почему бы и нет ? Раз уж докопались до такой особенности .Это будет быстрее ,чем ждать у моря погоды .Такова фича видать ...
Некоторые сложности имеются. Примерно так и делал. Как я уже писал, алгоритм опроса двух каналов с небольшой обработкой и отправкой команд на переключение пределов измерения модуля уже приводит к увеличению цикла на 1 мс. И при составлении и поэтапной отладке проходит все стадии от беспроблемной работы до неудовлетворительной. И вот представьте ситуацию, в предварительно отлаженный проект начинаю добавлять работу с модулем. Добавил операцию - работает нормально, добавил следующую - работает. Попутно приходится корректировать основной проект. На каком-то этапе начинаются перебои в связи. Начинаю разбираться. Естественно, что если до этого работало нормально, а добавленный фрагмент небольшой и время цикла не изменилось, то автоматом начинаю разбираться с добавленным фрагментом и с его интеграцией в проект. И небольшие изменения приводят то к улучшению, то к ухудшению ситуации, а зависимость выявить не удается. А тут еще представитель техподдержки приводит пример, что реле вполне способно работать с нужной мне скоростью и даже с запасом, при времени цикла 7 мс скорость немного падает, но в мои требования укладывается. Я то думаю, что с моими 4 мс цикла вообще все должно летать, а оно то летает, то начинает ползать. О специфической "особенности" умалчивается. Зато начинаются намеки, дескать модуль не той системы и вообще я хочу слишком много. В результате почти трех недель разбирательств докопался до сути, а оказывается да, есть такая "особенность", так и должно быть. Вот сейчас отлаженный проект с опросом попадает в неудачный диапазон. Время цикла 4 мс. Убираешь небольшую часть схемы - работает как надо, когда задействовано все, что нужно - работает на троечку. И что делать? Нагружать проект бесполезными узлами, чтобы дотянуть время цикла до 5 мс?
Я не могу представить, о чем Вы говорите. Тот выложенный проект можно вообще не рассматривать там не понятное запоминание циклов для чего то, если это попытка некого теста, то она провалится. В нем всего две читаемых переменных видимо из трмки, а то что Вы сейчас пишите, что у Вас там даже пределы пишутся, надеюсь они по команде выставлены, а не каждый цикл записывают, не знаю можно ли считать проектом, чтение двух значений с отображением на экране, какие Вы там операции добавляете - загадка. Тем более что увеличивается цикл аж до 7мс
оказывается да, есть такая "особенность", так и должно быть когда Вам пишут про некую особенность, это испорченный телефон, возможно ваши представления с разработчиком об интервале отличается на порядок или на два, какая бы у меня программа не была, если я выставляю опрос в 50мс, то с таким интервалом он и происходит, был бы не в командировке выгрузил бы лог, с различными по объему программами, хотя конечно вру, вряд ли я напишу проект с семью миллисекундами, но на меньших временах, запросы приходили стабильно, может в новых релизах что то изменилось, но это бы подтвердили уже давно другие пользователи, а пока Вы один
В том проекте запоминание не самих циклов, а количества циклов между изменениями сетевой переменной. По количеству циклов определял период опроса. Да это был тест, но тогда задачи были еще другие. Максимальное время цикла у меня 4 мс. 7 мс делал Юрий в своих тестах. Вернетесь из командировки, могу скинуть проект со временем цикла 1 мс, на котором при опросе двух регистров float минимальный период опроса получается 160-200 мс, и периодически вообще зависает.
Период опроса задаётся в мастере и только лог снифа покажет что запросы идут как положено или нет, ещё как вариант станет ясно что это модуль не может отдавать изменившуюся информацию с такой скоростью. Нелепый подсчёт циклов здесь не поможет выяснить истинную причину
Это все верно ...но вопрос как это связано со сложностью проекта ,точнее с временем что остается под обмен , ведь особенность действительно есть и не факт что разработчики будут что то менять .это же типа не баг ,а особенность
А Вы видели реально что происходит, может как обычно тут все в одну кучу собрали, а по факту, что оно типа этого http://www.owen.ru/forum/showthread.php?t=28281&p=272050&viewfull=1#post272050
Период опроса задаётся в мастере и только лог снифа покажет что запросы идут как положено или нет, ещё как вариант станет ясно что это модуль не может отдавать изменившуюся информацию с такой скоростью. Нелепый подсчёт циклов здесь не поможет выяснить истинную причину
Почему это не поможет? Все четко фиксируется и считает. Время цикла известно точно. Модуль тестировал отдельно, отдает за 20 мс. Не может же модуль зависеть от сложности программы ПР? И если с одной программой я получаю эти 20 мс, а с другой нет, то дело не в модуле. Да и Юрий подтвердил, что такая "особенность" имеет место быть. А скептики продолжают сомневаться. Или Вы тоже заинтересованы не признавать этот баг? Я считаю это именно багом. На основании того, что при незначительном изменении программы частота опроса меняется в 8 раз! И ни в одном документе эта "особенность" не описана. А техподдержка про нее не знает или скрывает.
Интересно - меняется только время опроса или могут быть случаи с потерей пакетов ???
Я контролировал переменную - Статус опроса. Она всегда была в 1. Можно это считать отсутствием потерь? Были случаи 100% потери, когда опрос зависал. Тогда статус падал в 0.
Хорошо бы ОПС сервером глянуть ,там и запросы и ответы видны ...и настройки по таймерам можно всякие выставить и количество циклов ....да и режимы работы задать (мастер ,слев) ....если будут потери и они будут зависить от времени цикла ПР и настроек RS485 ,то это досадный баг ,но нужны точные подтверждения ,прямые, а не косвенные ...
У меня сейчас нет такой возможности. Итак уже потратил на отладку слишком много времени. Прибор нужно запускать в работу. До этого я не занимался на таком глубоком уровне RS-485 сетями, у меня нет никаких диагностических средств и программ, и я не умею с ними работать. Поэтому для меня проще всего использовать средства самого ПР. А вообще на каком этапе Вы предполагаете потери? Если ПР не пошлет вовремя запрос - это будет увеличение времени опроса. А когда пошлет, то устройство по любому ответит, оно-то на время цикла не завязано. Остается вариант, что ПР не сможет (не успеет) обработать этот ответ. Но это извне не увидишь. Тут как раз нужна диагностика на уровне внутренней программы.
У меня сейчас нет такой возможности. Итак уже потратил на отладку слишком много времени. Прибор нужно запускать в работу. До этого я не занимался на таком глубоком уровне RS-485 сетями, у меня нет никаких диагностических средств и программ, и я не умею с ними работать. Поэтому для меня проще всего использовать средства самого ПР. А вообще на каком этапе Вы предполагаете потери? Если ПР не пошлет вовремя запрос - это будет увеличение времени опроса. А когда пошлет, то устройство по любому ответит, оно-то на время цикла не завязано. Остается вариант, что ПР не сможет (не успеет) обработать этот ответ. Но это извне не увидишь. Тут как раз нужна диагностика на уровне внутренней программы.
херней Вы занимались, а не отладкой и это еще мягко сказано, кому нужны данные со скоростью 65мс, передавать на верхний уровень, так у ПР оба интерфейса 485, можно напрямую опрос делать, отображать на экране, так человеческий глаз только после 200мс начинает различать незначительные изменения, а уж отреагировать тем более бессмысленно, он же не сидит не отрываясь от экрана, программная логика остается, так и здесь всевозможные регуляторы умеют предсказывать результат по выборке за несколько периодов и отдельные всплески они всё равно будут сглаживать.
Отдельно фраза: "ПР не сможет (не успеет) обработать этот ответ" это что вобще за бред, данные все полностью обрабатываются за цикл проекта, а запросы со слейвов приходят через несколько таких циклов
Чем бы он не занимался ,он выявил фичу ,как минимум .И разработчики ее подтвердили .То что вы говорите ,так должно быть ,но есть по другому .ТС может и не правильно выражается,делая выводы или предположения ,но здраво мыслит и находит фичи теми средствами что имеет и знает.Другие более опытные ее не выявили.Задачи есть разные и может в некоторых из них эта фича сказаться и не обязательно на глаза (мелькание).
Не надо использовать дешевое ПР как измерительное быстродействующее устройство. Для этого есть другие системы.
Я не слышал ни чего от разработчиков, Юрий передал слова и ни слова во сколько раз, не понятно что там задерживается, Тс утверждает что задержки увеличиваются в восемь раз, это запрос идёт в районе 500 мс, это можно заметить любому, а не отдельно взятому персонажу, логов не представлено, потому что их не будет, запросы как шли с валим чередом так и будут идти, а его предположения основываться на собственном чудо-коде
Я не слышал ни чего от разработчиков, Юрий передал слова и ни слова во сколько раз, не понятно что там задерживается,
Потому что сами разработчики не замеряли это время ,они просто знают об этой фичи и благодаря ТС об этом узнали и другие пользователи .Как мог так и измерил ,имхо .Поднял вопрос и то спасибо ,а дальше пусть разработчики проверяют ,измеряют ,документируют это не дело пользователей (хотя могут быть помошники) .
Не надо использовать дешевое ПР как измерительное быстродействующее устройство. Для этого есть другие системы.
Речь не об этом только ,а о том как связана скорость обмена с временем цикла ,точнее почему она меняется не линейно , а по пиле ...
Потому что сами разработчики не замеряли это время ,они просто знают об этой фичи и благодаря ТС об этом узнали и другие пользователи .Как мог так и измерил ,имхо .Поднял вопрос и то спасибо ,а дальше пусть разработчики проверяют ,измеряют ,документируют это не дело пользователей (хотя могут быть помошники) .
а как тогда мы такие счастливчики пишем программы и ни разу не разочаровываемся что опрос идет реже чем заданный в настройках, Вас вообще не удивляет, что немножко доработать можно цикл увеличить на одну миллисекунду
capzap. Вы либо невнимательно читаете тему, либо целенаправленно пытаетесь "замять" проблему и придираетесь к моим формулировкам. Для чего мне нужно такое время, я уже писал ранее. Да, для передачи на верхний уровень (ПК). И есть причины делать именно так. Фраза: "ПР не сможет (не успеет) обработать этот ответ" - прочитайте еще раз, по какому поводу я ее написал, если с первого не дошло. Самое быстрое время, которое мне удалось получить при опросе двух регистров float - 20 мс, а самое медленное - 190 мс. При этом в программу добавил всего 1 элемент и две константы. Могу выложить проекты, желающие могут проверить. Правда не факт, что на другом приборе, возможно с другой прошивкой точно совпадет. Но должно быть близко.
Не надо использовать дешевое ПР как измерительное быстродействующее устройство. Для этого есть другие системы.
А почему бы и нет? У него очень быстрые входы. В других системах использую. Просто у нас эти реле применяются для многих задач и весьма успешно. Появилась новая задача, немного посложнее, но по всем расчетам посильная, вот и применили то, что хорошо знакомо и есть под руками. Опять же унификация. Кстати на предыдущей задаче тоже был подобный косяк, только в меньших масштабах. Модуль ICP опрашивается всего один канал. Должен отдавать с периодом 100 мс. Как не бился, получил только 130 мс. Грешил на модуль и оставил как есть. Надо будет проверить еще раз с учетом последних наработок.
а как тогда мы такие счастливчики пишем программы и ни разу не разочаровываемся что опрос идет реже чем заданный в настройках, Вас вообще не удивляет, что немножко доработать можно цикл увеличить на одну миллисекунду
Костыли ни кто не отменял ,не об этом же речь. Не проверял ,но верю ТС - что цикл может резко увеличится вплодь до прекращения обмена .Не увеличение время обмена напрягает ,а не предсказуемость ,если она есть ...и ни какой симулятор главное не покажет это .Работает все прекрасно 50 сетевых перменных, время отклика 1 сек устраивает ,а тут внес изменение ,добавил макрос или ФБ и бац - 10сек ...кому понравиться ...
А почему бы и нет? У него очень быстрые входы. В других системах использую. Просто у нас эти реле применяются для многих задач и весьма успешно. Появилась новая задача, немного посложнее, но по всем расчетам посильная, вот и применили то, что хорошо знакомо и есть под руками.Потому что оно для этого не предназначено. Просто воспримите это как данность.
Ну здесь скорее наоборот, когда уберешь блок. Резко ухудшается, если время цикла реле уменьшается. Когда добавляешь элементы - ухудшается постепенно. А Вы проверяли, всегда ли переменные обновляются через 1000 мс? Хоть одну на выбор.
Если реле справляется с задачей, я это воспринимаю как данность. Когда не справиться, тогда посмотрим.
Могу выложить проекты, желающие могут проверить. Правда не факт, что на другом приборе, возможно с другой прошивкой точно совпадет.
ну так а чего еще не выложили, однозначно Вы конкуренцию ни кому не составите и Ваши интеллектуальная собственность не пострадает
Пока ни кто не проявил интереса. Про интеллектуальную собственность на простенькую тестовую программу - улыбнуло. :) Вот, пожалуйста, файл под номером 3 - опрос тормозит и зависает, файл под номером 6 - период опроса 20-25 мс. Измеряется количество циклов между изменениями сетевой переменной Сн2. На экран выводится минимальное, текущее и максимальное значение, количество изменений за 1 секунду. Текущее мелькает слишком быстро, поэтому сделал запоминание крайних значений.
неплохо было бы еще написать в какой версии делали
Последняя, доступная на сайте.
Да, вроде поставил, а у модуля есть имя
Жутко интересно что скажет электронищик будет продолжать противоречить мне или все же скажет что код близко не похож на тот который может находить проблемы.
При времени запросов в 65 секунд как можно понять задерживается опрос или нет, а ещё эта запись в каждый цикл нуля в переменную только для чтения
Время поставил такое специально, чтобы не мешало. Об этом тоже был разговор ранее. Запросы инициируются флагами R_1 и R_2. Кто сказал, что переменная только для чтения?
Как сетевая переменная она только читается, то что Вы туда ноль пишите постоянно это Ваше дело, что же касается переменных, а где периодичность запуска, я их видел на холсте, там им постоянно присваивается единица, т. е. каждый цикл посылается запрос, не успев ответить, а если логика в ОЛ по фронту, то только один раз, что тоже не подходит. А в настройках, у меня и ни влазят в окно, я их и не видел сперва и комментов нет возле них
Как сетевая, да. Но ни что не мешает записывать в нее значение изнутри. Таким образом фиксируется ответ. При ответе переменной присваивается значение с модуля, я его запоминаю и тут же переменная сбрасывается. Периодичность запуска не обязательна. Если флаг всегда в 1 - запросы идут с максимальной частотой. Об этом мне рассказали в техподдержке. Вы бы залили проект в устройство, подключили к нему любой модуль и посмотрели. Какой смысл критиковать просто так?
Как сетевая, да. Но ни что не мешает записывать в нее значение изнутри. Таким образом фиксируется ответ. При ответе переменной присваивается значение с модуля, я его запоминаю и тут же переменная сбрасывается. Периодичность запуска не обязательна. Если флаг всегда в 1 - запросы идут с максимальной частотой. Об этом мне рассказали в техподдержке. Вы бы залили проект в устройство, подключили к нему любой модуль и посмотрели. Какой смысл критиковать просто так?
вот с чем имеется возможность работать, то и обсуждаю, когда вернусь тогда и будут логи, где будет "каша" из запросов ответов, без всяких устройств это ясно. Какой смысл в этих принудительных запросах, если есть штатное средство работа по времени
Сейчас для чистоты эксперимента в проекте № 3 убрал переменные флагов и поставил период опроса 25 мс. Получил 8 запросов в секунду. Начал добавлять понемногу блоки. Частота снизилась до 5 запросов в секунду, а потом на очередном блоке подскочила до 40. Так что разницы в способе инициации запросов нет.
А смысл такой, что мне с одного модуля надо читать 2 канала с максимальной частотой, с которой может обновлять модуль. Это 65 мс. И еще 3 канала (2 с этого же модуля и один с другого) с небольшой частотой, ну где-то 1 раз за 1-2 сек, но не в ущерб первым двум. Вот это все я и разруливаю флагами. При точной подгонке удается прочитать 2 канала примерно за 40-50 мс и за оставшееся время прочитать еще один канал из 3-х, на следующем периоде читаю второй, и так по очереди. И в основном проекте флаги конечно работают по очереди. Просто для тестов не стал заморачиваться, так как разницы нет. Я думаю, что у мастера не такая уж глупая логика, и пока он не получит ответа от устройства, или не закончится таймаут, он не будет посылать следующий запрос на каждом цикле.
раз уж встал вопрос про критику просто так, объясните какую функцию выполняет макрос "Save f min", по моему мнению это более чем остальные адекватный макрос, но какую функциональность он выполняет я не разобрал
Этот макрос запоминает минимальное значение
каким образом, я подаю любое значение и оно появляется на выходе макроса, ни какого минимального я поймать не смог
Он работает совместно с элементом fGT. Значения надо подавать на верхний вход fGT и на вход Var макроса одновременно. Если значение на входе меньше, чем на выходе, то оно перезаписывается на выход. Если больше - то не перезаписывается. По переднему фронту на входе Reset выход устанавливается в 0. В проекте это происходит каждые пять секунд.
почему, если функция макроса запомнить значение, которое одновременно подается с импульсом сохранения, не повторяется в запоминании максимального значения?
почему тогда блинк а не ловец фронта?
почему в макросе не использовать fSEL, вместо "супового набора"?
Первый вопрос не понял вообще.
По второму тоже не понятно, какой фронт нужно ловить?
По третьему. Как придумал, так и сделал. Если у Вас есть идеи по оптимизации, покажите свою схему.
макросы максимума и минимума должны быть одинаковыми, и отличаться только подачей в нужный момент импульса, для каждого случая меняя подключение входов на fGT и так, как сейчас, искать ошибки требуется и там и там, а не в одном месте
по второму, это самое основное что может приводить к неверным результатам, блинк работает какое то заданное время с учетом времени цикла, оно может быть больше, поэтому управление с блинка на вход макроса происходит,вероятнее всего, в два цикла, следовательно есть шанс потерять нужное значение
схем запоминания значений через SEL великое множество на форуме, мне тут не стать оригинальным
макросы максимума и минимума должны быть одинаковыми, и отличаться только подачей в нужный момент импульса, для каждого случая меняя подключение входов на fGT и так, как сейчас, искать ошибки требуется и там и там, а не в одном месте
Кому это они должны? Я делал так, как мне удобно для своих потребностей. Изначально был просто макрос для запоминания числа float, скачанный из онлайн библиотеки. Чтобы он запоминал только максимальное значение, к нему пришлось добавить функцию fGT. А чтобы запоминать минимальное значение, пришлось еще доработать и сам макрос. Ну уж так получилось.
Блинк вообще имеет второстепенную функцию. По его переднему фронту оба макроса сбрасываются в 0, так как мне достаточно наблюдать значения в течении 5 сек. В макросах значения запоминаются автоматически, блинк в этом не участвует.
схем запоминания значений через SEL великое множество на форуме, мне тут не стать оригинальным
А мне вот попалась эта схема. С ней и работаю. Вы считаете, что она работает хуже?
Это только rovki хвастается что он схемы любые просчититывает и не только свои, из тех пару раз что я на схему смотрел, я не могу сказать однозначно правильная она или нет, надо тестировать, когда я поставлял различные значения, стало ясно что минимум формируется где то из вне либо схема не рабочая. Выйдя на главный холст бросается в глаза что fGT одинаковы для поиска противоположных значений, значит второй макрос написан по другому алгоритму, а раз его функция тоже запоминать значение, то ясно что Вы впустую тратите силы.
С блинком, если фронт ловит тот элемент который внутри макроса, ну замечательно если работает правильно, только в таком случае зачем возмущаться, что К Вам отношение скептическое
Для того, что бы составить пару макросов, недостатка сил не испытываю.:cool: С блинком никак не пойму, что Вы хотите сказать. Блинк не участвует в процессе запоминания, уберите его и все будет работать также. Блинк формирует 5 секундные интервалы, через которые обнуляются макросы. От его зависимости от времени цикла или ни жарко, ни холодно. То есть на выходах отображаются минимальное и максимальное значения, зафиксированные в интервале 5 сек. Потом по сигналу блинка выходы макросов устанавливаются в 0 и процесс повторяется.
https://www.modbustools.com/download/ModbusSlaveSetup64Bit.exe прога скачивается мгновенно, ставится меньше минуты, разбираться практически не надо, давно можно было выложить лог, с такими аргументами и предъявлять претензии разработчикам, а не придумывать что от количества блоков меняется опрос
простенькая программа опрашивающая каждый 40мс по установленному значению. Лог оставляет желать лучшего, видно что мастер старается придерживаться интервалов, но плохо у него получается, да есть провалы по времени у мастера, а так же следующие за этим склеивание двух запросов, на которые есть только один ответ
дополнительно скрин с другого программного слейва, там такая же картина, что запросы совершенно не хотят придерживаться очереди, лезут кому как вздумается, что чисто по штатному временному графику, что с помощью битов принудительной записи/чтения. Если долго заниматься, играя параметрами и поглядывая на Временная диаграмма опроса из справки можно добиться улучшения ситуации, но вывод один ПР не подходит для скоростных опросов, начиная где то со 150мс на запрос, уже всё нормально не вдаваясь в подробности
Ну тоесть подтверждаете особенности выявленные ТС , только более мошьным инструментов ???
Ну тоесть подтверждаете особенности выявленные ТС , только более мошьным инструментов ???
нет, ни какого отношения к количеству блоков отношение это не имеет
нет, ни какого отношения к количеству блоков отношение это не имеет
На тех скоростях ,что вы озвучили ,а если на тех ,что испытывал TC ?
На тех скоростях ,что вы озвучили ,а если на тех ,что испытывал TC ?
при чем тут скорости, во первых я не планирую работать на 115200, еще с времен когда "мышки были большими" (СОМ-овскими), во вторых если смотрели проект у меня есть куча бесполезных блоков, которые добавлялись после очередных прогонов, разницы особой нет, здесь не правильная работа мастера, который не справляется с очередью, если таковая существует, либо ее нет и всё построено на каких то внутренних таймерах, которые тестировались например только с одной переменной. Как на форуме уже писалось, ждем групповых запросов
ЗЫ Вот прикладываю скрин где все вырезал
А я пока не планирую ПР как мастер ;).Работаю исключитльно на 115200 (без проводов).Так вроде есть групповые запросы ,числом до 12 .
Во первых, у меня галка группового запроса не активна, во вторых я имел ввиду, то когда разработчики займутся в следующий раз рефакторингом/оптимизацией мастера. Для меня пока очевидно, что биты записи/чтения роли не играют, импульс это или постоянное состояние, все зависит от бита опрос, чем дольше он висит с потенциалом, тем больше ложных запросов проскакивает
Не поленился, тоже прогнал с эмулятором. Из тех программ, что выкладывал под номером 6. Запросы идут строго по очереди, интервалы между запросами 31-32 мс. С измерениями на самом ПР совпадает. ПР показывает время между запросами одного регистра 14-16 циклов при времени цикла 2 мс и 16 запросов в секунду.
А вот тест программы под номером 3 со временем цикла 1 мс. Очередность соблюдается, а вот время пляшет. ПР показывает интервал 88-113 мс и 5 запросов в секунду. Измерения эмулятора и ПР тоже совпадают.
А вот тест программы под номером 3 со временем цикла 1 мс. Очередность соблюдается, а вот время пляшет. ПР показывает интервал 88-113 мс и 5 запросов в секунду. Измерения эмулятора и ПР тоже совпадают.
Значит так у разработчиков устроенна микропрограмма, только они могут объяснить. А Вы можете сто лет эмулировать.
Можете конечно найти закономерность,но может случайно произойти событие,которое пойдет вразрез с Вашими наблюдениями.
А вот тест программы под номером 3 со временем цикла 1 мс. Очередность соблюдается, а вот время пляшет. ПР показывает интервал 88-113 мс и 5 запросов в секунду. Измерения эмулятора и ПР тоже совпадают.
Так Вы согласно диаграммы уменьшите время таймаута до 1мс и потом запускайте этот проект
Ничего не понял. Согласно какой диаграммы? И какое время таймаута? Имеется ввиду таймаут ответа в настройках мастера?
В справке доходите до работы мастера и где то на середине раздела есть график, как по времени идёт работа мастера. Вы поставили такое время, когда слейв в теории давно уже ответил, а ПР даже не приступила к прослушиванию интерфейса, это тоже влияет почему у Вас нет стабильности, опять же это лично моё мнение
Вы поставили такое время, когда слейв в теории давно уже ответил, а ПР даже не приступила к прослушиванию интерфейса...
Это как так? Мастер начинает слушать сразу после запроса и слушает либо до прихода ответа, либо до окончания таймаута. Я пробовал менять этот параметр. Менее 4 мс начинаются потери данных, 4 мс и более - никакой разницы нет. Юрий вообще советовал ставить таймаут с запасом 100-500 мс. А в справке... Предполагаю что там имеется ввиду таймаут ответа слейва.
Ну значит им надо менять документацию и справку, потому что определение в текстовом виде таймаута верное, а рисунок совсем другое предусматривает, некое подобие rs.DL в слевах. Зато, Вы выяснили что ответ от прибора приходит за 4мс,что сопоставимо с теми расчётами что были когда-то приведены в Википедии по модбас
Серёга Букашкин
08.10.2018, 21:02
Для меня пока очевидно, что биты записи/чтения роли не играют, импульс это или постоянное состояние, все зависит от бита опрос, чем дольше он висит с потенциалом, тем больше ложных запросов проскакивает
ПР200, мастер.Переменная управления чтением сетевого регистра управляет странно. Интуитивно кажется, что если она =0, то по этому регистру запросов быть не должно. Но по факту это не так, запросы всё равно идут, только реже чем когда она =1. Если периодически подавать в нее импульсы "1",то работает подобно как постоянно =1. Хотелось бы внятных пояснений как управлять при помощи этой переменной.
Когда переменая =0, запросы идут с периодичностью, установленной в поле "Период опроса". Отключить запросы по периоду опроса по моему невозможно. Можно только увеличить этот период. Максимально возможное значение 65535 сек. При установке переменной в 1 формируется запрос. capzap предполагает, что если 1 удерживать постоянно, то запросы будут формироваться чуть ли не каждый цикл. Мне кажется, что мастер до прихода ответа, или до истечения таймаута новые запросы не формирует. Но на 100% этот момент я еще не подтвердил. В тех поддержке мне когда-то говорили, что для инициации запроса нужно подавать 1 только в течении 1 цикла программы. При времени цикла в 1 мс у меня наблюдались сбои, при времени цикла 2 мс и более уже работает. Хотя тогда я еще плохо понимал, как это работает, может были и другие ошибки. Вообще все тонкостей не знают и в техподдержке, отсылают то к РЭ, то к описанию протокола Modbus.
согласно диаграммы уменьшите время таймаута до 1мс
почему я пришел к такому заключению, ну во первых в справке сам график можно трактовать как угодно, если не читать описание таймаута. Во вторых, выложенный здесь мой проект шлет запросы только с единицей в таймауте при условии что задана переменная в поле опрос, если значение больше то запросы не идут, убрав разрешение опроса, картина меняется, увеличив таймаут до адекватного значения я начинаю принимать значения регистров, с переменной в опросе ни разу не удалось отобразить на экране заданное значение в слейве, хотя лог говорит что слейв свою работу выполняет и отправляет ответы на запрос.
почему я пришел к такому заключению, ну во первых в справке сам график можно трактовать как угодно, если не читать описание таймаута. Во вторых, выложенный здесь мой проект шлет запросы только с единицей в таймауте при условии что задана переменная в поле опрос, если значение больше то запросы не идут, убрав разрешение опроса, картина меняется, увеличив таймаут до адекватного значения я начинаю принимать значения регистров, с переменной в опросе ни разу не удалось отобразить на экране заданное значение в слейве, хотя лог говорит что слейв свою работу выполняет и отправляет ответы на запрос.
Посмотрел внимательно ваш проект, погонял на симуляторе. Проект простой, скорее всего время цикла 1 мс. Похоже у Вас тот же эффект, что описал я. Длительность команды чтения (записи) в 1 мс недостаточна для адекватной работы. Как это связало с таймаутом, непонятно. Попробуйте увеличить длительность команды. Насколько - точно не скажу. У меня сейчас устойчиво работает при 5 мс, при меньшем времени на устойчивость не проверял. И не понятно, зачем Вы дергаете переменную опрос? Никакого практического смысла в этом не вижу, а глюков возможно добавляет.
чем дольше она включена тем больше дополнительных запросов приходит в слейв, обобщенно выставив 40мс в логе будут 4 запроса без ответа и на последний, пятый, будет ответ, ставлю 20мс два запроса без ответа, на третий отвечает, что то в этом роде. И я как раз говорю, что заметна не правильна работа, глюки. В идеальных условиях всё летает, сами же писали что Юрий предоставил подробное тестирование, но если чуть "шаг в строну" от этих условий мастер перестает нормально работать, это надо исправлять
От каких условий? Он их точно не обозначил. Я пытался добиться от него подробностей, но он ответил, что ему неохота лезть в тайминги. И послал меня изучать РЭ и протокол. Хотя при чем тут протокол, когда нужно знать логику работы конкретной железяки? А в РЭ ничего толком не описано. Исправлять надо, согласен. И писать толковое РЭ.
выставив 40мс в логе будут 4 запроса без ответа и на последний, пятый, будет ответ, ставлю 20мс два запроса без ответа, на третий отвечает
Так это как раз следствие малого таймаута ответа. Как только он истекает - мастер посылает новый запрос. Поставьте длительность команды 5-10 мс, а таймаут 10-20 мс.
Так это как раз следствие малого таймаута ответа.
я же не с единицы начал выставлять время, начинал наверное с 50, потом спускался вниз, здесь написал про вариант который не получилися с разумными временами и выложил проект когда хоть что то послалось в слейв. Повторю, при большем значении таймаута и наличии переменной в опросе запросы мастером не отправляются
У меня таймаут 15 мс, все запросы только с помощью переменных. Все отправляется и принимается. По прежнему думаю, что когда таймаут был большой длительность команды была 1 цикл, то есть 1 мс.
У меня таймаут 15 мс, все запросы только с помощью переменных. Все отправляется и принимается. По прежнему думаю, что когда таймаут был большой длительность команды была 1 цикл, то есть 1 мс.
ну так остался один шаг повторить мой проект, это вставить переменную в поле опрос, там где у меня выставлена переменная EnRequest, хоть на постоянно в TRUE
Уже нет такой возможности. Я свои опыты завершил в ПР залил окончательный проект и прибор пошел в дальнейшую настройку. Я добился всего, чего хотел. Опрашиваю 5 регистров float с двух модулей. При времени цикла 5 мс за 65 мс опрашивается 3 регистра. Два опрашиваются постоянно, третий с каждой серией запросов меняется. Главный инструмент настройщика ПР200 39071
И так было мутно, теперь тумана добавилось в этом таинстве. Зависимости от назначения периода опроса не замечено если он установлен меньше естественного периода. Общий период опроса может быть длинным когда много абонентов.
Туман развеялся, осталась легкая дымка. Зависит в основном от количества передаваемых регистров. Примерно 25-40 мс на 1 регистр. Опрашиваете к примеру 10 регистров - минимальный период опроса будет 250 мс. Поставите 500 мс - будет 500, поставите 250 мс - будет
250. Дальше уменьшаться не будет. Поставите 200, 100 или 50 - все равно останется 250 мс. Это если все переменные запись/чтение =0 или не выбраны.
Переменные работают, и пользоваться ими очень удобно, когда нужно опрашивать разные регистры с разной частотой. При большом времени периода опроса, когда оно не оказывает заметного влияния примерно так. При установке переменной в 1 идет запрос данного регистра. Если 1 не снять до получения ответа, то сразу же пойдет следующий запрос. Если установить в 1 сразу несколько переменных, то эти регистры будут опрашиваться по очереди с максимально возможной скоростью, без пауз. Вот как работает, когда и период опроса небольшой, и переменные в 1 - точно не скажу, не понял. Но ничего хорошего с такими настройками получить не смог. Сегодня был прецедент. Настроил опрос трех регистров с одного устройства, уложился в 65 мс. Период опроса максимальный 65535 мс, запросы инициируются с помощью переменных по тактовому генератору через 65 мс. Подключил второе устройство, у которого 2 регистра только на запись, период опроса 1000 мс, стоит галочка "Запись по изменению". Значения не меняются, соответственно писать в эти регистры не должен. На первом устройстве опрос перестал успевать, пошли пропуски. Деактивирую второе устройство, устанавливая в 0 переменную "Опрос", пропуски исчезают.
Серёга Букашкин
10.10.2018, 05:10
Переменные работают, и пользоваться ими очень удобно, когда нужно опрашивать разные регистры с разной частотой.
Я был уверен, ибо логично, что если переменная управления назначена сетевому регистру и она =0, то запросов по нему не будет. Оказалось это не так, они будут. Какое это тогда управление? Попытки проредить запросы одноцикловой 1 раз в 10с тоже не меняли ничего в темпе опроса. Объяснить принцип может только разработчик, а опыты только запутывают.
Я был уверен, ибо логично, что если переменная управления назначена сетевому регистру и она =0, то запросов по нему не будет. Оказалось это не так, они будут. Какое это тогда управление? Попытки проредить запросы одноцикловой 1 раз в 10с тоже не меняли ничего в темпе опроса. Объяснить принцип может только разработчик, а опыты только запутывают.
Так я об этом и раньше говорил. Разработчики Сейчас читают эту ветку и думают. Ну-ну. Экспериментируйте. И только нам
известен алгоритм. И мы и дальше будем хохотать над Вашими экспериментами.
Нормальный разработчик такие проблемы не решает загадочными методами. Есть общепринятые во всем мире алгоритмы
решения подобных проблем. Привожу Вам его. В процессе выполнения цикла, на каком бы этапе цикл не происходил, по запросу
цикл должен прерваться, обработать запрос и выдать данные запрос чему. После этого продолжить цикл до нового запроса. И
так все время. Потому ,что ответ на запрос есть задача приоритетная. Но разработчики данного прибора пошли против общепри
пятого алгоритма. И поэтому все беды нестабильности ответа по времени именно в этом и заключаются.
Короче угомонитесь. Загадка разгадана. Разработчики ПР пренебрегли классикой решения подобных задач. По ихнему алгоритму
пока не закончится цикл основной программы никаких запросов не обрабатывать. По окончанию цикла проверяется буфер с пос
ледники запросом. И именно на него даётся ответ. Сколько там запросов пришло ,во время основного цикла - не волнует. Ответ
даётся на последний запрос. И поэтому получается такая чуча- Вами наблюдаемая и мною объясняемая. Это есть четкая недоработка. Так что уважаемые дорабатывайте и не заставляйте людей лабораторные работы делать .
Ревака Юрий
10.10.2018, 18:17
Так я об этом и раньше говорил. Разработчики Сейчас читают эту ветку и думают. Ну-ну. Экспериментируйте. И только нам
известен алгоритм. И мы и дальше будем хохотать над Вашими экспериментами.
Вчера как раз обсуждали вопросы, которые необходимо более детально прояснить в Help по работе с сетью, надеюсь повысим информативность в этом вопросе.
Вчера как раз обсуждали вопросы, которые необходимо более детально прояснить в Help по работе с сетью, надеюсь повысим информативность в этом вопросе.
При чем здесь сеть?
Короче угомонитесь. Загадка разгадана. Разработчики ПР пренебрегли классикой решения подобных задач. По ихнему алгоритму
пока не закончится цикл основной программы никаких запросов не обрабатывать. По окончанию цикла проверяется буфер с пос
ледники запросом. И именно на него даётся ответ. Сколько там запросов пришло ,во время основного цикла - не волнует. Ответ
даётся на последний запрос. И поэтому получается такая чуча- Вами наблюдаемая и мною объясняемая. Это есть четкая недоработка. Так что уважаемые дорабатывайте и не заставляйте людей лабораторные работы делать .
Не пойму, Вы пишете про режим Slave? Так к нему претензий пока нет. Здесь обсуждаем ПР в режиме мастера.
Вчера как раз обсуждали вопросы, которые необходимо более детально прояснить в Help по работе с сетью, надеюсь повысим информативность в этом вопросе.
Это конечно хорошо. А планируете что-то делать с выявленной проблемой? Очень сильно мешает.
Не пойму, Вы пишете про режим Slave? Так к нему претензий пока нет. Здесь обсуждаем ПР в режиме мастера.
Я не пишу ни окаких режимах. Мне пофиг режимы. Я пишу о проблемах ,почему Вы в режиме мастер получаете информацию
Разную. И Вам я это объяснил.Внимателнее читайте.
Вчера как раз обсуждали вопросы, которые необходимо более детально прояснить в Help по работе с сетью, надеюсь повысим информативность в этом вопросе.
Вы есть человек уважаемый и участниками форума и мной лично. И участники форума воспринимают Ваш ответ,как окончательное решение своих проблем. Я хочу разочаровать участников форума . Дело в том ,что большинство участников
Форума не понимают субъективности Ваших объяснений. Вы есть представитель своего работадателя . И все пояснения
Ваши не являются объективными. И склоняются к поставленной задаче работодателя. Что есть правильным,с точки зрения
работодателя. Поэтому делаю вывод. Ваши рекомендации на форуме следует тщательно фильтровать.
К примеру обясняю Ваше необективное суждение по вопросу поднянтуе в этой ветке.
Единственное ,что Вы сделали это сняли временную диаграмму процесса и выложили . Большинство поверили в этот частный случай и восторгались Вашему доказательству.
Capzap пошел другим путем. И долго доказывал конкретными решениями. Что не убедило
партнёров.
И только я нашел истинную причину недоразумения. И выложил неопровержимые аргументы.
Аргументы следующие.Разработчики решили проблему решить так. Какие бы запросы не приходили на ПР ,хранить последний запрос в буфере запроса. И отвечать на него по окончании
Цыкла основной программы. И отвечать ПР будет на последний запрос,игнорируя кучу предыдущих.
И пусть попробует Сапзап и Реваки убедить меня в обратном.
Ревака Юрий
10.10.2018, 21:02
При чем здесь сеть?
При том, что часто встречаются вопросы связанные с настройками и особенностями сетевых интерфейсов, и не всегда есть на них ответы.
У меня цикл программы 5 мс. Какая куча запросов придет за это время? :confused:
Ревака Юрий
10.10.2018, 21:17
Разработчики Сейчас читают эту ветку и думают. Ну-ну. Экспериментируйте. И только нам
известен алгоритм. И мы и дальше будем хохотать над Вашими экспериментами.
Вы есть человек уважаемый и участниками форума и мной лично. И участники форума воспринимают Ваш ответ,как окончательное решение своих проблем. Я хочу разочаровать участников форума . Дело в том ,что большинство участников
Форума не понимают субъективности Ваших объяснений. Вы есть представитель своего работадателя . И все пояснения
Ваши не являются объективными. И склоняются к поставленной задаче работодателя. Что есть правильным,с точки зрения
работодателя.
:D Хватить уже фантазировать, Вы серьезно думаете что мне говорят то, как мне преподнести ту или иную проблему если она существует, или что-то скрыть если это работает не так?:)
:D Хватить уже фантазировать, Вы серьезно думаете что мне говорят то, как мне преподнести ту или иную проблему если она существует, или что-то скрыть если это работает не так?:)
Ну да. Так я и думаю,судя по Вашей аргументации. Вы очень убедительно и аргументированно
Отвечаете на вопросы.Но я не разу не видил,чтобы хоть один из Ваших аргументов шел вразрез
С техническими ошибками разработчиков компании Овен.Хотя с последним моим аргументом
Вы вряд ли можете поспорить и доказать,что я ни прав в своих суждениях.
. Так что с нетерпением жду Ваших конкретных аргументов по моим замечаниям
По поводу неправильного алгоритма работы ПР. Где разработчики допустили конкретный инженерный просчет.
Мало того. Если Вы не сможете убедить меня в моей неправоте,Ваш рейтинг на форуме резко может упасть.
С УВ. Одесса. Так что с нетерпением жду Ваших конкретных аргументов по моим замечаниям
По поводу неправильного алгоритма работы ПР. Где разработчики допустили конкретный инженерный просчет.
Вам же обьянили ,что имеются некоторые особенности режима МАСТЕРА (Пр200) и он ждет 1 ответа на 1 запрос от слейва, ни какой кучи ответов нет на 1 запрос .Другие слейвы сами ни чего не шлют ,только на запрос Мастера ... Цикл ПР не может быть больше ,чем цикл отправки данных Мастером .
Вам же обьянили ,что имеются некоторые особенности режима МАСТЕРА (Пр200) и он ждет 1 ответа на 1 запрос от слейва, ни какой кучи ответов нет на 1 запрос .Другие слейвы сами ни чего не шлют ,только на запрос Мастера ... Цикл ПР не может быть больше ,чем цикл отправки данных Мастером .
А где это я говорил о претензиях к мастеру? И его некоторых особенностях. Речь идёт именно о неправильном алгоритме
работы слева. Повторяю. Слейв должен бросить все свои дела,ответить мастеру и затем продолжать заниматься своими
проблемами. И задача по ответу мастеру должна быть приоритетной по отношению других задач слэйва.
Хочу добавить,что ядром последних ПР является процессор STM. Особенностью,которого является то ,что к его периферии можно достучаться вообще не прерывая основной цикл программы. Есть такой режим.
Вы наверное ошиблись темой. Здесь говорим о неправильном алгоритме мастера. По слейву вопросов нет.
Вы наверное ошиблись темой. Здесь говорим о неправильном алгоритме мастера. По слейву вопросов нет.
Ничего я не ошибся. При любом ,логичном алгоритме мастера слейв должен ему ответить,прервав свою работу. А он этого
не делает. И следствие такой работы Вы наблюдаете,обвиняя мастера в его неправильном алгоритме. Слэйв думает разное количество времени и от этого Ваши проблемы.
У меня ПР200 - мастер, а слейв просто модуль аналогового ввода. Он вообще не думает.
У меня ПР200 - мастер, а слейв просто модуль аналогового ввода. Он вообще не думает.
Напрасно вы пришли к такому выводу..Вашему модулю нужно время для обработки аналогового сигнала. И когда он его обра
батывает(думает) он думы должен свои бросить и немедленно ответить мастеру. Потому,что мастер начальник. А он плевать
хотел на начальника(ничего страшного подождёт) Вот и получаются из за такого подхода неприятности. В крайнем случае
выплюнуть начальнику ответ,хранящийся буфере.Чего он не делает-так его спроектировали.
Вообще-то он так и делает. Если мастер способен запрашивать через 15 мс, то он и отвечает за 15. А когда меняешь проект в мастере, период опроса увеличивается. Или смена проекта в мастере влияет на задумчивость слейва?
Вообще-то он так и делает. Если мастер способен запрашивать через 15 мс, то он и отвечает за 15. А когда меняешь проект в мастере, период опроса увеличивается. Или смена проекта в мастере влияет на задумчивость слейва?
Вы в мастере увеличили время опроса. А слейву пофиг. Он пока не обработает измеряемый параметр мастеру не ответит. Если
бы Вы наоборот частоту опроса уменьшили и слэйв успевал,тогда было бы все в порядке, что и подтверждают Ваши наблюдения.
Серёга Букашкин
11.10.2018, 11:01
Вы в мастере увеличили время опроса. А слейву пофиг. Он пока не обработает измеряемый параметр мастеру не ответит. Если
бы Вы наоборот частоту опроса уменьшили и слэйв успевал,тогда было бы все в порядке, что и подтверждают Ваши наблюдения.
Полностью согласен и ранее уже на это жаловался. Слейв должен сразу отвечать из буфера, разработчики пошли по пути как попроще, чтобы не связываться с обновлением буфера по окончании цикла. У меня из-за этого проблемы общего темпа обменов когда слейвов еще и много. Каждый притормаживает на свой цикл и резутат тот что имеем, большую часть времени в линии тишина. Да еще мастер цедит по одному регистру.
Алексеев
11.10.2018, 13:16
Полностью согласен и ранее уже на это жаловался. Слейв должен сразу отвечать из буфера, разработчики пошли по пути как попроще, чтобы не связываться с обновлением буфера по окончании цикла. У меня из-за этого проблемы общего темпа обменов когда слейвов еще и много. Каждый притормаживает на свой цикл и резутат тот что имеем, большую часть времени в линии тишина. Да еще мастер цедит по одному регистру.
Хотелось бы задать вопрос разработчикам . Вообще планируется ли организация пакетного запроса мастером и ответа слейвом запрашиваемого пакета . Мне кажется многие вопросы (пожелания )отпали само собой .
Ревака Юрий
11.10.2018, 13:42
Хотелось бы задать вопрос разработчикам . Вообще планируется ли организация пакетного запроса мастером и ответа слейвом запрашиваемого пакета . Мне кажется многие вопросы (пожелания )отпали само собой .
Групповой запрос для мастера в задачах есть, в режиме слейв отвечает пакетом.
Серёга Букашкин
11.10.2018, 13:46
...и ответа слейвом запрашиваемого пакета.
Слейв на групповой запрос сейчас отвечает нормально, групповым ответом без ограничения длины в пределах своего буфера. Проверял мастером СП300. Только лучше было бы чтобы сразу, а не закончив свой цикл. Если бы хоть одну их этих проблем решили уже интенсивность обмена увеличилась бы в разы. А если обе (и групповой обмен и ответ сразу) бы решили вообще бы красота.
Алексеев
11.10.2018, 15:07
Слейв на групповой запрос сейчас отвечает нормально, групповым ответом без ограничения длины в пределах своего буфера. Проверял мастером СП300. Только лучше было бы чтобы сразу, а не закончив свой цикл. Если бы хоть одну их этих проблем решили уже интенсивность обмена увеличилась бы в разы. А если обе (и групповой обмен и ответ сразу) бы решили вообще бы красота.
Прочитал тему. И не могу представить в каких задачах требуется такая интенсивность по обмену . Даже в наших задачах работающих с газом
одной секунды достаточно , даже если у меня цикл программы 15 мсек (использую 70% ресурса ПР200 ) сколько раз в секунду я могу опросить более 50 раз .
Да разработчики скорей всего используют прерывания ( обработку прерываний ) после завершения цикла программы . Скорей всего им так удобней .
Юрий Ревака прилагает все усилия к тому,чтобы оправдать глюк разработчиков. О чем я писал в предыдущих постах. Вместо
того,чтобы просто ответить,что да,мол есть такая беда. Он выкладывает кучу красивых картинок с стимулятора. Которыми
восторгаются малоопытные киповцы. Делает ещё кучу экспериментов. И все ради того,чтобы потребитель убедился в том,что
с разработкой все в порядке. Казалось бы все честно. Но позвольте спросить у Вас уважаемый Юрий- по отношению к кому? По
отношению к работадателю- да. Действительно Вы честно и с усердием отрабатывает свой хлеб. По отношению к клиентам?
Очень сомнительно.
Какая куча экспериментов? В этой теме был один серьезный эксперимент, но в идеальных условиях. А дальше Юрий посчитал, что свой долг выполнил и остальную информацию просто игнорирует. По выявленной проблеме правда признал, что да, есть такая не беда - "особенность". И снова молчок. Наверное нужно обращаться с этой проблемой в Овен официально.
Какая куча экспериментов? В этой теме был один серьезный эксперимент, но в идеальных условиях. А дальше Юрий посчитал, что свой долг выполнил и остальную информацию просто игнорирует. По выявленной проблеме правда признал, что да, есть такая не беда - "особенность". И снова молчок. Наверное нужно обращаться с этой проблемой в Овен официально.
Посмотрите пост 26. Это по Вашему один эксперимент? Тогда я не знаю,что такое два эксперимента. Юрий проделал колоссальную
работу ,но ради целей описанных мной в предыдущем посте.
Алексеев
11.10.2018, 16:14
Какая куча экспериментов? В этой теме был один серьезный эксперимент, но в идеальных условиях. А дальше Юрий посчитал, что свой долг выполнил и остальную информацию просто игнорирует. По выявленной проблеме правда признал, что да, есть такая не беда - "особенность". И снова молчок. Наверное нужно обращаться с этой проблемой в Овен официально.
Я могу предположить что Вам могут ответить . Я читал (не помню где на форуме 3 года назад) это концепция ПЛК и естественно ПР200 фирмы ОВЕН ( может быть и других производителей) вначале выполняется
программа 1 цикл обрабатываются входные , выходные дисплей клавиатура ,а потом обрабатываются прерывания связанные с обменом т.д .
Мне программисту контроллеров (микро контроллеров) это тоже не понятно я могу в любой момент обработать в программе любое прерывание в зависимости от приоритета.
Потому как с сетью работают 10% ПР ,видимо потому приоритет отдан отработки входов ,вычислениям ...а уж потом сети ,тем более мастер в ПР появился только в 200 серии ,имхо...
Собственно что кому не нравится ? обмен по сети всегда медленнее цикла программы будет. Не пойму вообще о чем спор. Надо быстрее получать данные с датчиков где-то, применяйте другое оборудование, тут собственно Овеном даже пахнуть не будет...
Алексеев
11.10.2018, 16:53
Потому как с сетью работают 10% ПР ,видимо потому приоритет отдан отработки входов ,вычислениям ...а уж потом сети ,тем более мастер в ПР появился только в 200 серии ,имхо...
Я с вами полностью согласен . Если у одного потребителя возник вопрос ,а остальных все устраивает ,никто даже пальцем не пошевелит .
Просто любые изменения могут повлечет за собой и другие проблемы . А которых Мы даже не догадываемся .
Алексеев
11.10.2018, 16:56
Собственно что кому не нравится ? обмен по сети всегда медленнее цикла программы будет. Не пойму вообще о чем спор. Надо быстрее получать данные с датчиков где-то, применяйте другое оборудование, тут собственно Овеном даже пахнуть не будет...
Я тоже не понимаю . Но уже 25 страниц в теме .
Собственно что кому не нравится ? обмен по сети всегда медленнее цикла программы будет. Не пойму вообще о чем спор. Надо быстрее получать данные с датчиков где-то, применяйте другое оборудование, тут собственно Овеном даже пахнуть не будет...
На 100% согласен. Но хочу добавить,что дело не в ПР. А,чтобы Овном пахло ,дело за малым. ВУ должно последние обработанные
данные вытаскивать из буфера(даже если идёт процесс обработки и новые данные ещё не готовы) и немедленно отдавать их
мастеру. Только и всего.
Ревака Юрий
11.10.2018, 17:42
Какая куча экспериментов? В этой теме был один серьезный эксперимент, но в идеальных условиях. А дальше Юрий посчитал, что свой долг выполнил и остальную информацию просто игнорирует. По выявленной проблеме правда признал, что да, есть такая не беда - "особенность". И снова молчок. Наверное нужно обращаться с этой проблемой в Овен официально.
Про особенность я узнал от Вас, уточнил у программистов алгоритм и действительно ли может что-то подобное проявляться, мне ответили положительно. Но так как кроме обмена по интерфейсу необходимо еще обслуживать логику, дисплей вх/вых и т.д то я не считаю это проблемой или неисправностью, видимо на этапе ТЗ были заданы определенные приоритеты, и для Вашей задачи, приоритет нужен для модбас. Но увеличение приоритета для модбас, приведет к другим последствиям, это мое личное мнение. Можно обратиться официально, разве кто-то Вам запрещает, но мне кажется если проборов продано очень большое количество , и только сейчас возник этот момент, то это проблема правильного выбора оборудования для конкретной задачи. Это опять таки мое личное мнение.
Посмотрите пост 26. Это по Вашему один эксперимент? Тогда я не знаю,что такое два эксперимента. Юрий проделал колоссальную
работу ,но ради целей описанных мной в предыдущем посте.
В моем понимании это был один эксперимент, или изыскание. Первая часть - установление минимально достижимого периода опроса, можно считать выполненной, хотя на пустом проекте, где кроме опросов нет ничего, ценность результата снижается. Вторая часть - оценка влияния нагрузки на период опроса. И вот здесь и вылез подвох. Показанный Юрием результат выглядел хорошо и дал мне уверенность, что возможностей ПР для моих задач вполне хватает. А при конкретной реализации процесс пошел не так и пришлось затратить довольно много времени, чтобы вытащить на свет эту "особенность". А вообще это изыскание надо было проделать на этапе испытаний и результаты указать в технических характеристиках. А в описании указать, от чего может зависеть период опроса. Тогда сразу было бы понятно - для каких задач ПР подходит, а для каких нет. Это было бы честно по отношению к потребителям. И подобных вопросов и претензий не возникало бы. Но тут опять мешает "особенность". Ведь за заявленные ТХ нужно отвечать. Как указывать полученные Юрием 40 мс при времени цикла 7 мс, если при 1 мс может получиться более 100? А указывать минимальные результаты или описывать особенности - будет некрасиво. Поэтому и промолчали.
Алексеев
11.10.2018, 19:55
Сергей и кто эту теме поднял и естественно все участники .
Естественно нужно официальное обращение . Я естественно поддержу если приоритет
по модбасу будет не в ущерб и проекты которые рабочие будут не сбоить .
И программисты железа (это не программисты ОЛ) должны быть уверены на 100% что это не повредит всему остальному.
Может и не обязательно делать приоритет? Даже если цикл 10-15 мс, не так уж это и много. Главное, чтобы период опроса не гулял от сложности проекта. Я уже озвучивал вариант, что для работы с интерфейсами нужно не выкраивать остатки времени от остальных задач, а выделять столько, сколько нужно для работы без тормозов. Если остатков не хватает, добавлять 1 мс времени цикла. По моему это гораздо проще и точно ни чему не повредит.
в ОЛ нет условных переходов, время затраченное на работу со всеми элементами можно просчитать легко, но раз пишется среднее время, значит к расчетам прибавляется время на обмен с экраном, на обмен с RS485. И следует помнить, что в умных книжках пишут: "при нескольких источниках запросов прерывание становится разделяемым ресурсом, использование которого может привести к нестабильности длительности цикла выполнения программы". Нестабильность ведь не одно и тоже что прямая зависимость от увеличения блоков, может разработчики соглашались на джиттер, а не то что обозначено заглавием темы, кстати можно было бы к примеру указать процент используемых блоков для той или иной ситуации, а не просто говорить что цикл вот-вот перейдет к следующему значению, потому что разброс времени цикла может перекрывать ближайшие ситуации
в ОЛ нет условных переходов, время затраченное на работу со всеми элементами можно просчитать легко, но раз пишется среднее время, значит к расчетам прибавляется время на обмен с экраном, на обмен с RS485. И следует помнить, что в умных книжках пишут: "при нескольких источниках запросов прерывание становится разделяемым ресурсом, использование которого может привести к нестабильности длительности цикла выполнения программы". Нестабильность ведь не одно и тоже что прямая зависимость от увеличения блоков, может разработчики соглашались на джиттер, а не то что обозначено заглавием темы, кстати можно было бы к примеру указать процент используемых блоков для той или иной ситуации, а не просто говорить что цикл вот-вот перейдет к следующему значению, потому что разброс времени цикла может перекрывать ближайшие ситуации
Красиво излагаетe. Только неизвестно ,тогда зачем в это ПР влупили STM 32. Если в ОЛ нет условных переходов,то в микро
программе микропроцессора это не проблема. При тактовой частоте 160 МГц для этого процессора плевое дело и клавиши обс
луживать и дисплей и интерфейс даже не прибегая к прерываниям и условным переходам. ПР заточено изначально ёлочные Гир
лянды переключать, а не обслуживать сети. Обратите внимание,что даже АЦП туда воткнули 10 разрядный. Так на всякий случай
Вдруг и правда,кому то взбредёт в голову что то измерять. А тут оба- нашлись индивидуумы ,измерять начали. Тогда посадили
грамотного Реваку,чтоб макросы проталкивал супер-пуперовские,которые линейность высшей математикой выравнивают.
По большому счету никакого криминала в данной ситуации не нахожу. Паровоз с рельс не сошел. Ну столкнулся дядя с ситуа
цией,ну и что? Если б не столкнулся никто об этом не знал и прекрасно ёлочные гирлянды и дальше переключали.
PS. Только,что сходил на Ровкину ветку. В натуре гирлянды забабахал. Только от затеи с
ПР отказался,потому,что оно медленное.
Филоненко Владислав
12.10.2018, 07:27
Красиво излагаетe. Только неизвестно ,тогда зачем в это ПР влупили STM 32. Если в ОЛ нет условных переходов,то в микро
программе микропроцессора это не проблема. При тактовой частоте 160 МГц для этого процессора плевое дело и клавиши обс
луживать и дисплей и интерфейс даже не прибегая к прерываниям и условным переходам. ПР заточено изначально ёлочные Гир
лянды переключать, а не обслуживать сети. Обратите внимание,что даже АЦП туда воткнули 10 разрядный. Так на всякий случай
Вдруг и правда,кому то взбредёт в голову что то измерять. А тут оба- нашлись индивидуумы ,измерять начали. Тогда посадили
грамотного Реваку,чтоб макросы проталкивал супер-пуперовские,которые линейность высшей математикой выравнивают.
По большому счету никакого криминала в данной ситуации не нахожу. Паровоз с рельс не сошел. Ну столкнулся дядя с ситуа
цией,ну и что? Если б не столкнулся никто об этом не знал и прекрасно ёлочные гирлянды и дальше переключали.
PS. Только,что сходил на Ровкину ветку. В натуре гирлянды забабахал. Только от затеи с
ПР отказался,потому,что оно медленное.
Приходите к нам работать, такие гениальные программисты нам нужны!
Приходите к нам работать, такие гениальные программисты нам нужны!
Шутить надо аккуратней :o
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot