Одесса в не видели как Pt1000 врет на овеновских ПЛК, до 6 градусов как с куста.... так что дешево и сердито подойдет и такой датчик.
у DS18B20 если что точность +-0,5 гр.
Вид для печати
Одесса в не видели как Pt1000 врет на овеновских ПЛК, до 6 градусов как с куста.... так что дешево и сердито подойдет и такой датчик.
у DS18B20 если что точность +-0,5 гр.
А можно, пожалуйста, поподробнее. Это на краю диапазона? У меня в проекте на ПР200 заложен Pt1000 и я очень рассчитывал на 1 градус для комнатной температуры.Цитата:
Сообщение от melky
Мелки не против lLM. А вот насчёт DS Вы малость недоинформированы. Работает он по двум алгоритма. По первому алгоритмуЦитата:
Сообщение от melky
0,5 по второму 0,1 он. Разница во времени измерения 90мс. и 750мс. и
Был неделю в отпуске. Теперь вышел и продолжил опыты с модулем. Выяснил, что модуль отвечает стабильно за 20 мс, ошибок в ответах нет. Есть только повторы, то есть не обновляются значения в регистрах. Но с ПР тоже не все гладко. Отладил небольшую тестовую прошивку со временем цикла 1 мс, получил 15-18 запросов в секунду, жить можно. Начал постепенно добавлять в прошивку разные функции и заметил, что скорость опроса начинает падать. С добавлением 2-3 логических элементов падает до 13-16 в секунду, а с добавлением одного таймера сразу упала до 8-10 запросов в секунду. Долго разбирался, пытаясь понять зависимость, а потом добавил сразу большой узел, время цикла увеличилось до 2 мс и скорость опроса выросла до 18-19 в секунду. Это что же получается? Если сложность прошивки укладывается в какой-то период, а на опрос интерфейса времени не остается, то идет зарубание опроса?
Про это я и писал в начале темы, что если программа усложняется и растет время цикла, то обмен будет происходить в выделенные временные промежутки.
Не представляю, чем можно его озадачить, чтобы получить время цикла 15 мс? Я пока дошел только до 4, и в схеме уже можно заблудиться. Юрий где-то писал, что на запрос выделяется часть времени цикла. Время 1 мс, допустим на обработку схемы тратится 0,5 мс, остальное время он ждет или работает с интерфейсами. Что можно успеть за это время? Если не успел, то продолжает в следующий цикл. А если на схему тратится 0,9 мс, то на интерфейс вообще ничего не остается? Когда на схему тратится 1,2 мс, то увеличивается время цикла до 2 мс. И тогда на работу с интерфейсами выделяется 0,8 мс времени. И скорость возрастает. Я алгоритм примерно так представляю. При 15 мс наверное и групповой запрос существенно не улучшит ситуацию. Мне кажется, что на работу с интерфейсами нужно выделять фиксированное количество времени, и если времени цикла не хватает - увеличивать его, даже если основная схема этого не требует. А при большом времени цикла выделять периоды внутри цикла.
Так почему эти временные промежутки уменьшаются в разы при относительно небольшом усложнении программы, пока время цикла не выросло, и резко уменьшаются, если 1 мс прибавилась?Цитата:
Сообщение от Ревака Юрий
Этот момент не понятен пока, не сталкивался с подобным, а какие именно блоки добавляются?Цитата:
Сообщение от Mike HG
Например ТР (Импульс включения заданной длительности).
Так и думал, и времена наверное минимальные?Цитата:
Сообщение от Mike HG
Время от 20 до 250 мс. И что не так? Влияет сам факт добавления блока. Не зависимо от того запускается он или нет.
Думал, может установлены минимальные значения. То что блок не запущен, не значит что он не оказывает влияния на время цикла, при старте программы время рассчитывается исходя из худших условий, благодаря этому получаем время цикла независимое от того запущен узел логики или нет, как-то так, возможно и таймер так считается, и так как его минимальное время 1ms, то это влияет на общий цикл, а это время в свою очередь на обмен по сети. Этот момент требует уточнения.Цитата:
Сообщение от Mike HG
Возможно Вы не поняли. У меня ПР200 мастер опрашивает один модуль. Частота опросов падает у мастера по мере усложнения программы. Когда программа усложняется настолько, что время цикла увеличивается на 1 мс - частота опросов восстанавливается. При дальнейшем усложнении программы все повторяется. По крайней мере до 4 мс. Влияют как раз таймеры и счетчики. Описывал выше, что при добавлении одного блока частота опросов уменьшалась почти в 2 раза.
65535 мс.:) Переменную "Запуск чтения" ставлю в 1. Запросы идут с минимально возможным периодом.Цитата:
Сообщение от Серёга Букашкин
Считываю сетевую переменную, сравниваю ее с нулем, если не равна нулю, значит пришел ответ, запоминаю результат, переменную обнуляю. Замеряю количество циклов между ответами, умножаю на время цикла. Отдельно считаю количество ответов за 1 сек. Засекаю по внутренним часам. Все результаты вывожу на дисплей.Цитата:
Как измеряете частоту ответов?
Реле устанавливает время цикла в зависимости от сложности программы с дискретностью 1 мс. Поэтому по мере добавления элементов время цикла не меняется, а потом с добавлением очередного элемента сразу увеличивается на 1. А вот период опроса с добавлением элементов возрастает, почти пропорционально. На самой границе, когда до увеличения времени цикла остается добавить один элемент - вообще зависает!Цитата:
Вообще-то добавление блока не может заметно изменить время цикла.
Думаю попадают, просто не понимают в чем дело. Когда я только начинал использовать в ПР 485 интерфейс, у меня было подобное. Без всякой видимой причины останавливался опрос. Мог проработать 30 сек, а мог несколько часов. Обращался в техподдержку, ничего конкретного не посоветовали. Заменить интерфейс, проверить все соединения, отключить все внешние устройства и подключать по одному, использовать экранированную витую пару для соединений (на длине линии 10 см:)). Если не поможет, отправить устройство в сервисный центр. Потом само рассосалось.
Период запроса именно такой. Вложение 38917 Поставил максимально возможное значение. Запросами управляю с помощью флага "Запуск чтения" переменная R_2. Это запрос конкретного регистра по требованию. Как я понял - исполняется немедленно при установке в 1 и имеет приоритет перед запросами по расписанию. При постоянной 1 запросы идут один за другим без всяких таймаутов. удобная функция, когда с одного устройства нужно запрашивать несколько регистров с разным периодом.
А она точно должна быть "0" если ответ не пришел? Не знаю как у Вас меняется сигнал, но для float можно попробовать сравнивать на неравенство предыдущему значению.Цитата:
Сообщение от Mike HG
Если я ее обнуляю, то она 0. Способ работает. Поначалу пытался сравнивать с предыдущим. Для float нет функции сравнения на равенство. Приходится преобразовывать в int и использовать функцию EQ. При преобразовании в int отрезается дробная часть. А если сигнал меняется в 4 или 5 знаке после запятой? Значит сначала нужно умножить на 100000. И еще в начале темы я уже писал, что у меня модуль не всегда вовремя обновляет данные в регистре, и я просто на очередной запрос получаю такое же значение, и спрашивал, как с этим разобраться. Таким способом я не могу определить - не пришел ответ, или пришел с таким же значением. Теперь момент ответа фиксируется четко. Для измерения сделал на втором ПР "генератор сигнала". С помощью ЦАП на аналоговом выходе сигнал постоянно меняется в заданном диапазоне. Либо смотрю шумы модуля. При 24 разрядном АЦП и отключенных фильтрах в 4-5 знаке шумит очень хорошо.
Не обязательно переводить в INT, как раз свойство float и поможет отличать старые значения от новых, нашел пример, делал расчет времени преобразования для модуля расширения, основан как раз на алгоритме задания нарастающего сигнала, момент преобразования фиксируется на fGT.Цитата:
Сообщение от Mike HG
fGT - Сравнение на большее значение. Будет работать, только если сигнал будет изменятся в одну сторону - увеличиваться или уменьшаться. Но он же не может меняться до бесконечности, в конце концов выйдет за пределы диапазона. Поэтому я его меняю периодически вверх - вниз. С шумами тоже не прокатит.
В общих свойствах мастера нет периода. Если Вы про интервал между запросами, то у меня там 0. Юрий здесь писал, что меньше 8 разницы нет, типа ограничения на уровне железа.Цитата:
Сообщение от Серёга Букашкин
А как этот эффект может зависеть от количества абонентов? Может Вы просто не боролись за высокую частоту опроса?
Так меняйте его достаточно медленно, главное регистрировать изменение, как раз на возрастание я и работал. Но опять таки, если Вы пишите что модуль долго обновляет значения в регистре, тогда надо там что-то ускорить, ПР никак эту проблему не решит.Цитата:
Сообщение от Mike HG
Да, тогда работал именно с одним абонентом на шине. При наличии нескольких, возможно картина будет иная.Цитата:
Сообщение от Серёга Букашкин
не знаю всей "кухни" ОЛ, но если для сравнения вещественных использовать следующую дичь: принять как целочисленное и прогнать его через XOR с предыдущим значением, если будет единица в любом из разрядов или целочисленное больше нуля, значит можно фиксировать изменениеЦитата:
Сообщение от Ревака Юрий
А как целочисленное прогнать через XOR? Оно туда не лезет!
У меня скорость опроса 15 раз в секунду. Соответственно менять надо не реже. В конце концов я уже объяснил, почему я делаю именно так. Если надо поймать изменение float, то есть простой способ, я им тоже пользуюсь, когда нужно. Вложение 38932 Сейчас речь не о способе регистрации изменений и не о моем модуле, а о том, что в ПР200 выявлен существенный косяк в работе RS-485.Цитата:
Сообщение от Ревака Юрий
От чего же?Цитата:
Сообщение от Mike HG
Прекрасно "лезет"
Вложение 38934
который проявляется только у Вас? Лог снифера можете приложить, где будут видны запросы-ответы с метками времени при всех этапах добавления блоков в проектЦитата:
Сообщение от Mike HG
Тогда я не понял.:confused: XOR - это исключающее ИЛИ. А что это такое у Вас?Цитата:
Сообщение от petera
У меня нет снифера. Все делаю на ПР его же средствами. Это становится заметно, когда борешься за высокую и стабильную частоту опроса.
Битовые элементы работают и с целочисленными ,выполняя побитывые операции .Цитата:
Сообщение от Mike HG
У меня, верней в ОЛ, - по битный XOR, как и в других языках программированияЦитата:
Сообщение от Mike HG
12345 == 11000000111001
12346 == 11000000111010
11000000111001 XOR 11000000111010 = 11 или 3 в дес.
так может не надо бороться, может все Ваши действи, ловли не понятно чего и приводят к искуственно созданным задержкам. Что значит нет снифера, RS485 позволяет держать на шине несколько устройств, подцепитесь к этой сети через конвертер с ПК и слушайте что в порту происходит, а ПР и модуль пусть работают так, как им положено, а не под "нагрузочным тестом"Цитата:
Сообщение от Mike HG
Не нашел у себя в OL версия 1.12 такой функции. Есть только XOR, который работает с булевскими сигналами.
Отдельного элемента нет ,те что есть универсальные ...Что подадите так и работаетЦитата:
Сообщение от Mike HG
В смысле у меня нет на ПК программы, которая может слушать и выводить результаты. Надо искать, разбираться. ПР вполне способно с помощью простеньких макросов измерить все, что нужно, и вывести результаты на дисплей. Не думаю, что будет существенная разница с ПК. В начале темы я задавал вопросы, как определить кто косячит реле или модуль. Юрий предоставил результаты измерений, которые показали, что реле способно обеспечивать нужную мне скорость. Я тоже провел подобные измерения, подтвердил эти результаты для себя. Стал разбираться с модулем. Определил его возможности и косяки. Научился опрашивать с нужной мне частотой и приемлемым количеством ошибок на "голом" реле. А когда начал реализовывать основную программу - все посыпалось. Как я уже писал, на каком-то этапе незначительные изменения в программе стали приводить к значительным изменениям в скорости опроса в обе стороны. Долго не мог понять зависимость. Потом взялся с самого начала. Постепенно добавлял элементы в программу, делал измерения и выявил данный эффект.
второй пост темы по содержанию идентичен моему предложению, давно можно было поставить и разобраться
Спасибо, дошло. В справке об этом ничего нет. Сам бы ни за что не догадался.Цитата:
Сообщение от rovki
Ну сейчас это уже не актуально. Уже разобрался. Способ значения не имеет.Цитата:
Сообщение от capzap
Возникает вопрос, что с этим делать? Будут ли производители принимать какие-то меры по устранению проблемы?