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

[melky]

Одесса в не видели как Pt1000 врет на овеновских ПЛК, до 6 градусов как с куста.... так что дешево и сердито подойдет и такой датчик.
у DS18B20 если что точность +-0,5 гр.

[Aviator_VZh]

... Pt1000 врет на овеновских ПЛК, до 6 градусов как с куста....

А можно, пожалуйста, поподробнее. Это на краю диапазона? У меня в проекте на ПР200 заложен Pt1000 и я очень рассчитывал на 1 градус для комнатной температуры.

[Одесса]

Одесса в не видели как Pt1000 врет на овеновских ПЛК, до 6 градусов как с куста.... так что дешево и сердито подойдет и такой датчик.
у DS18B20 если что точность +-0,5 гр.

Мелки не против lLM. А вот насчёт DS Вы малость недоинформированы. Работает он по двум алгоритма. По первому алгоритму
0,5 по второму 0,1 он. Разница во времени измерения 90мс. и 750мс. и

[Mike HG]

Был неделю в отпуске. Теперь вышел и продолжил опыты с модулем. Выяснил, что модуль отвечает стабильно за 20 мс, ошибок в ответах нет. Есть только повторы, то есть не обновляются значения в регистрах. Но с ПР тоже не все гладко. Отладил небольшую тестовую прошивку со временем цикла 1 мс, получил 15-18 запросов в секунду, жить можно. Начал постепенно добавлять в прошивку разные функции и заметил, что скорость опроса начинает падать. С добавлением 2-3 логических элементов падает до 13-16 в секунду, а с добавлением одного таймера сразу упала до 8-10 запросов в секунду. Долго разбирался, пытаясь понять зависимость, а потом добавил сразу большой узел, время цикла увеличилось до 2 мс и скорость опроса выросла до 18-19 в секунду. Это что же получается? Если сложность прошивки укладывается в какой-то период, а на опрос интерфейса времени не остается, то идет зарубание опроса?

[Ревака Юрий]

Про это я и писал в начале темы, что если программа усложняется и растет время цикла, то обмен будет происходить в выделенные временные промежутки.

[Mike HG]

Не представляю, чем можно его озадачить, чтобы получить время цикла 15 мс? Я пока дошел только до 4, и в схеме уже можно заблудиться. Юрий где-то писал, что на запрос выделяется часть времени цикла. Время 1 мс, допустим на обработку схемы тратится 0,5 мс, остальное время он ждет или работает с интерфейсами. Что можно успеть за это время? Если не успел, то продолжает в следующий цикл. А если на схему тратится 0,9 мс, то на интерфейс вообще ничего не остается? Когда на схему тратится 1,2 мс, то увеличивается время цикла до 2 мс. И тогда на работу с интерфейсами выделяется 0,8 мс времени. И скорость возрастает. Я алгоритм примерно так представляю. При 15 мс наверное и групповой запрос существенно не улучшит ситуацию. Мне кажется, что на работу с интерфейсами нужно выделять фиксированное количество времени, и если времени цикла не хватает - увеличивать его, даже если основная схема этого не требует. А при большом времени цикла выделять периоды внутри цикла.

[Mike HG]

Про это я и писал в начале темы, что если программа усложняется и растет время цикла, то обмен будет происходить в выделенные временные промежутки.

Так почему эти временные промежутки уменьшаются в разы при относительно небольшом усложнении программы, пока время цикла не выросло, и резко уменьшаются, если 1 мс прибавилась?

[Ревака Юрий]

Так почему эти временные промежутки уменьшаются в разы при относительно небольшом усложнении программы, пока время цикла не выросло, и резко уменьшаются, если 1 мс прибавилась?

Этот момент не понятен пока, не сталкивался с подобным, а какие именно блоки добавляются?

[Mike HG]

Например ТР (Импульс включения заданной длительности).

[Ревака Юрий]

Например ТР (Импульс включения заданной длительности).

Так и думал, и времена наверное минимальные?