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

[capzap]

Так это как раз следствие малого таймаута ответа.

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

[Mike HG]

У меня таймаут 15 мс, все запросы только с помощью переменных. Все отправляется и принимается. По прежнему думаю, что когда таймаут был большой длительность команды была 1 цикл, то есть 1 мс.

[capzap]

У меня таймаут 15 мс, все запросы только с помощью переменных. Все отправляется и принимается. По прежнему думаю, что когда таймаут был большой длительность команды была 1 цикл, то есть 1 мс.

ну так остался один шаг повторить мой проект, это вставить переменную в поле опрос, там где у меня выставлена переменная EnRequest, хоть на постоянно в TRUE

[Mike HG]

Уже нет такой возможности. Я свои опыты завершил в ПР залил окончательный проект и прибор пошел в дальнейшую настройку. Я добился всего, чего хотел. Опрашиваю 5 регистров float с двух модулей. При времени цикла 5 мс за 65 мс опрашивается 3 регистра. Два опрашиваются постоянно, третий с каждой серией запросов меняется. Главный инструмент настройщика ПР200 15722.970.jpg

[Mike HG]

И так было мутно, теперь тумана добавилось в этом таинстве. Зависимости от назначения периода опроса не замечено если он установлен меньше естественного периода. Общий период опроса может быть длинным когда много абонентов.

Туман развеялся, осталась легкая дымка. Зависит в основном от количества передаваемых регистров. Примерно 25-40 мс на 1 регистр. Опрашиваете к примеру 10 регистров - минимальный период опроса будет 250 мс. Поставите 500 мс - будет 500, поставите 250 мс - будет
250. Дальше уменьшаться не будет. Поставите 200, 100 или 50 - все равно останется 250 мс. Это если все переменные запись/чтение =0 или не выбраны.

[Mike HG]

Переменные работают, и пользоваться ими очень удобно, когда нужно опрашивать разные регистры с разной частотой. При большом времени периода опроса, когда оно не оказывает заметного влияния примерно так. При установке переменной в 1 идет запрос данного регистра. Если 1 не снять до получения ответа, то сразу же пойдет следующий запрос. Если установить в 1 сразу несколько переменных, то эти регистры будут опрашиваться по очереди с максимально возможной скоростью, без пауз. Вот как работает, когда и период опроса небольшой, и переменные в 1 - точно не скажу, не понял. Но ничего хорошего с такими настройками получить не смог. Сегодня был прецедент. Настроил опрос трех регистров с одного устройства, уложился в 65 мс. Период опроса максимальный 65535 мс, запросы инициируются с помощью переменных по тактовому генератору через 65 мс. Подключил второе устройство, у которого 2 регистра только на запись, период опроса 1000 мс, стоит галочка "Запись по изменению". Значения не меняются, соответственно писать в эти регистры не должен. На первом устройстве опрос перестал успевать, пошли пропуски. Деактивирую второе устройство, устанавливая в 0 переменную "Опрос", пропуски исчезают.

[Серёга Букашкин]

Переменные работают, и пользоваться ими очень удобно, когда нужно опрашивать разные регистры с разной частотой.

Я был уверен, ибо логично, что если переменная управления назначена сетевому регистру и она =0, то запросов по нему не будет. Оказалось это не так, они будут. Какое это тогда управление? Попытки проредить запросы одноцикловой 1 раз в 10с тоже не меняли ничего в темпе опроса. Объяснить принцип может только разработчик, а опыты только запутывают.

[Одесса]

Я был уверен, ибо логично, что если переменная управления назначена сетевому регистру и она =0, то запросов по нему не будет. Оказалось это не так, они будут. Какое это тогда управление? Попытки проредить запросы одноцикловой 1 раз в 10с тоже не меняли ничего в темпе опроса. Объяснить принцип может только разработчик, а опыты только запутывают.

Так я об этом и раньше говорил. Разработчики Сейчас читают эту ветку и думают. Ну-ну. Экспериментируйте. И только нам
известен алгоритм. И мы и дальше будем хохотать над Вашими экспериментами.
Нормальный разработчик такие проблемы не решает загадочными методами. Есть общепринятые во всем мире алгоритмы
решения подобных проблем. Привожу Вам его. В процессе выполнения цикла, на каком бы этапе цикл не происходил, по запросу
цикл должен прерваться, обработать запрос и выдать данные запрос чему. После этого продолжить цикл до нового запроса. И
так все время. Потому ,что ответ на запрос есть задача приоритетная. Но разработчики данного прибора пошли против общепри
пятого алгоритма. И поэтому все беды нестабильности ответа по времени именно в этом и заключаются.

[Одесса]

Короче угомонитесь. Загадка разгадана. Разработчики ПР пренебрегли классикой решения подобных задач. По ихнему алгоритму
пока не закончится цикл основной программы никаких запросов не обрабатывать. По окончанию цикла проверяется буфер с пос
ледники запросом. И именно на него даётся ответ. Сколько там запросов пришло ,во время основного цикла - не волнует. Ответ
даётся на последний запрос. И поэтому получается такая чуча- Вами наблюдаемая и мною объясняемая. Это есть четкая недоработка. Так что уважаемые дорабатывайте и не заставляйте людей лабораторные работы делать .

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

Так я об этом и раньше говорил. Разработчики Сейчас читают эту ветку и думают. Ну-ну. Экспериментируйте. И только нам
известен алгоритм. И мы и дальше будем хохотать над Вашими экспериментами.

Вчера как раз обсуждали вопросы, которые необходимо более детально прояснить в Help по работе с сетью, надеюсь повысим информативность в этом вопросе.