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

[Mike HG]

Ничего не понял. Согласно какой диаграммы? И какое время таймаута? Имеется ввиду таймаут ответа в настройках мастера?

[capzap]

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

[Mike HG]

Вы поставили такое время, когда слейв в теории давно уже ответил, а ПР даже не приступила к прослушиванию интерфейса...

Это как так? Мастер начинает слушать сразу после запроса и слушает либо до прихода ответа, либо до окончания таймаута. Я пробовал менять этот параметр. Менее 4 мс начинаются потери данных, 4 мс и более - никакой разницы нет. Юрий вообще советовал ставить таймаут с запасом 100-500 мс. А в справке... Предполагаю что там имеется ввиду таймаут ответа слейва.

[capzap]

Ну значит им надо менять документацию и справку, потому что определение в текстовом виде таймаута верное, а рисунок совсем другое предусматривает, некое подобие rs.DL в слевах. Зато, Вы выяснили что ответ от прибора приходит за 4мс,что сопоставимо с теми расчётами что были когда-то приведены в Википедии по модбас

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

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

ПР200, мастер.Переменная управления чтением сетевого регистра управляет странно. Интуитивно кажется, что если она =0, то по этому регистру запросов быть не должно. Но по факту это не так, запросы всё равно идут, только реже чем когда она =1. Если периодически подавать в нее импульсы "1",то работает подобно как постоянно =1. Хотелось бы внятных пояснений как управлять при помощи этой переменной.

[Mike HG]

Когда переменая =0, запросы идут с периодичностью, установленной в поле "Период опроса". Отключить запросы по периоду опроса по моему невозможно. Можно только увеличить этот период. Максимально возможное значение 65535 сек. При установке переменной в 1 формируется запрос. capzap предполагает, что если 1 удерживать постоянно, то запросы будут формироваться чуть ли не каждый цикл. Мне кажется, что мастер до прихода ответа, или до истечения таймаута новые запросы не формирует. Но на 100% этот момент я еще не подтвердил. В тех поддержке мне когда-то говорили, что для инициации запроса нужно подавать 1 только в течении 1 цикла программы. При времени цикла в 1 мс у меня наблюдались сбои, при времени цикла 2 мс и более уже работает. Хотя тогда я еще плохо понимал, как это работает, может были и другие ошибки. Вообще все тонкостей не знают и в техподдержке, отсылают то к РЭ, то к описанию протокола Modbus.

[capzap]

согласно диаграммы уменьшите время таймаута до 1мс

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

[Mike HG]

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

Посмотрел внимательно ваш проект, погонял на симуляторе. Проект простой, скорее всего время цикла 1 мс. Похоже у Вас тот же эффект, что описал я. Длительность команды чтения (записи) в 1 мс недостаточна для адекватной работы. Как это связало с таймаутом, непонятно. Попробуйте увеличить длительность команды. Насколько - точно не скажу. У меня сейчас устойчиво работает при 5 мс, при меньшем времени на устойчивость не проверял. И не понятно, зачем Вы дергаете переменную опрос? Никакого практического смысла в этом не вижу, а глюков возможно добавляет.

[capzap]

чем дольше она включена тем больше дополнительных запросов приходит в слейв, обобщенно выставив 40мс в логе будут 4 запроса без ответа и на последний, пятый, будет ответ, ставлю 20мс два запроса без ответа, на третий отвечает, что то в этом роде. И я как раз говорю, что заметна не правильна работа, глюки. В идеальных условиях всё летает, сами же писали что Юрий предоставил подробное тестирование, но если чуть "шаг в строну" от этих условий мастер перестает нормально работать, это надо исправлять

[Mike HG]

От каких условий? Он их точно не обозначил. Я пытался добиться от него подробностей, но он ответил, что ему неохота лезть в тайминги. И послал меня изучать РЭ и протокол. Хотя при чем тут протокол, когда нужно знать логику работы конкретной железяки? А в РЭ ничего толком не описано. Исправлять надо, согласен. И писать толковое РЭ.

выставив 40мс в логе будут 4 запроса без ответа и на последний, пятый, будет ответ, ставлю 20мс два запроса без ответа, на третий отвечает

Так это как раз следствие малого таймаута ответа. Как только он истекает - мастер посылает новый запрос. Поставьте длительность команды 5-10 мс, а таймаут 10-20 мс.