ModBus

[Василий_S]

Протокол Modbus RTU в приложении сам реализовал ?

ModBus ASCII. Конечно сам, героическими усилиями, так сказать.

[Вольд]

ModBus ASCII. Конечно сам, героическими усилиями, так сказать.

А каким образом у тебя неверные данные в базу попадают, почему они не отбраковываются ? Что КС не помогает ?

[Василий_S]

А каким образом у тебя неверные данные в базу попадают, почему они не отбраковываются ? Что КС не помогает ?

Это уже проблема распределения полученных данных. Было бы что распределять. А базовая проблема в том, что данные в буфер после запроса иногда приходят некорректно. Я ставил "ловушки" по длине ответа и туда попадалось то, что длина ответа от устройств "иногда" меньше ожидаемой. Сейчас поставлен тройной фильтр - по длине данных, КС и совпадению адреса в ответе и запросе к устройству. В общем, всё указывает на некорректность ответов ПЛК. В дальнейшей обработке данных не сомневаюсь. В том числе и попадании некорректных данных в базу ибо это результат их обработки.
По "тройному" фильтру прога определяет: ещё раз запрашивать "этот" ПЛК или переходить к следующему устройству. Поставлена планка на 20 попыток. Если все они неудачны - то результат обработки (в организованной переменной)- 0. И эти нули видны в базе в объявленном выше количестве - за 4800 записей за сутки 10-20-30 пенок, равных нулю. А так - частенько просматривается 2 или 3 попытки, есть и другие значения, меньшие 20-ти. И это бы устроило (меньше 20-ти попыток), ибо корректный результат, после последней попытки запроса, есть.

[capzap]

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

Есть такой сайт http://ru.wikipedia.org/wiki/Modbus, там в самом низу раздел Стандартные коды ошибок и под ним примеры, в котором явно наблюдается, что ответ может быть меньше ожидаемого, это один из вариантов

[Василий_S]

Есть такой сайт http://ru.wikipedia.org/wiki/Modbus, там в самом низу раздел Стандартные коды ошибок и под ним примеры, в котором явно наблюдается, что ответ может быть меньше ожидаемого, это один из вариантов

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

[capzap]

Протокол Modbus RTU в приложении сам реализовал ?

ModBus ASCII. Конечно сам, героическими усилиями, так сказать.

А каким образом у тебя неверные данные в базу попадают, почему они не отбраковываются ? Что КС не помогает ?

Это уже проблема распределения полученных данных. Было бы что распределять. А базовая проблема в том, что данные в буфер после запроса иногда приходят некорректно. Я ставил "ловушки" по длине ответа и туда попадалось то, что длина ответа от устройств "иногда" меньше ожидаемой. Сейчас поставлен тройной фильтр - по длине данных, КС и совпадению адреса в ответе и запросе к устройству. В общем, всё указывает на некорректность ответов ПЛК. В дальнейшей обработке данных не сомневаюсь. В том числе и попадании некорректных данных в базу ибо это результат их обработки.

В общем, обнаружилась интересная вещь!Длина ответа ПЛК на запрос мастером по модасу аскии совпадает с ожидаемой, но в месте, где находится КС - стоят нули!

to Вольд, XopHeT и Ryzhij убедите меня, что дело в железе, а не в самописных прогах, даже несмотря на

Интересно ещё бы понять как связан всплеск нахождения нулей в КС, или что там ещё, с наступлением дневного рабочего времени.