Я контролировал переменную - Статус опроса. Она всегда была в 1. Можно это считать отсутствием потерь? Были случаи 100% потери, когда опрос зависал. Тогда статус падал в 0.
Я контролировал переменную - Статус опроса. Она всегда была в 1. Можно это считать отсутствием потерь? Были случаи 100% потери, когда опрос зависал. Тогда статус падал в 0.
Хорошо бы ОПС сервером глянуть ,там и запросы и ответы видны ...и настройки по таймерам можно всякие выставить и количество циклов ....да и режимы работы задать (мастер ,слев) ....если будут потери и они будут зависить от времени цикла ПР и настроек RS485 ,то это досадный баг ,но нужны точные подтверждения ,прямые, а не косвенные ...
Последний раз редактировалось rovki; 02.10.2018 в 21:58.
электронщик до мозга костей и не только
У меня сейчас нет такой возможности. Итак уже потратил на отладку слишком много времени. Прибор нужно запускать в работу. До этого я не занимался на таком глубоком уровне RS-485 сетями, у меня нет никаких диагностических средств и программ, и я не умею с ними работать. Поэтому для меня проще всего использовать средства самого ПР. А вообще на каком этапе Вы предполагаете потери? Если ПР не пошлет вовремя запрос - это будет увеличение времени опроса. А когда пошлет, то устройство по любому ответит, оно-то на время цикла не завязано. Остается вариант, что ПР не сможет (не успеет) обработать этот ответ. Но это извне не увидишь. Тут как раз нужна диагностика на уровне внутренней программы.
херней Вы занимались, а не отладкой и это еще мягко сказано, кому нужны данные со скоростью 65мс, передавать на верхний уровень, так у ПР оба интерфейса 485, можно напрямую опрос делать, отображать на экране, так человеческий глаз только после 200мс начинает различать незначительные изменения, а уж отреагировать тем более бессмысленно, он же не сидит не отрываясь от экрана, программная логика остается, так и здесь всевозможные регуляторы умеют предсказывать результат по выборке за несколько периодов и отдельные всплески они всё равно будут сглаживать.
Отдельно фраза: "ПР не сможет (не успеет) обработать этот ответ" это что вобще за бред, данные все полностью обрабатываются за цикл проекта, а запросы со слейвов приходят через несколько таких циклов
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Чем бы он не занимался ,он выявил фичу ,как минимум .И разработчики ее подтвердили .То что вы говорите ,так должно быть ,но есть по другому .ТС может и не правильно выражается,делая выводы или предположения ,но здраво мыслит и находит фичи теми средствами что имеет и знает.Другие более опытные ее не выявили.Задачи есть разные и может в некоторых из них эта фича сказаться и не обязательно на глаза (мелькание).
электронщик до мозга костей и не только
Не надо использовать дешевое ПР как измерительное быстродействующее устройство. Для этого есть другие системы.
Я не слышал ни чего от разработчиков, Юрий передал слова и ни слова во сколько раз, не понятно что там задерживается, Тс утверждает что задержки увеличиваются в восемь раз, это запрос идёт в районе 500 мс, это можно заметить любому, а не отдельно взятому персонажу, логов не представлено, потому что их не будет, запросы как шли с валим чередом так и будут идти, а его предположения основываться на собственном чудо-коде
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Потому что сами разработчики не замеряли это время ,они просто знают об этой фичи и благодаря ТС об этом узнали и другие пользователи .Как мог так и измерил ,имхо .Поднял вопрос и то спасибо ,а дальше пусть разработчики проверяют ,измеряют ,документируют это не дело пользователей (хотя могут быть помошники) .
электронщик до мозга костей и не только
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран