кабель с четырьмя парами как раз таки ближе к ЛВС, чем RS485Сообщение от Василий_S
в чем подвох?
кабель с четырьмя парами как раз таки ближе к ЛВС, чем RS485
в чем подвох?
Это уже проблема распределения полученных данных. Было бы что распределять. А базовая проблема в том, что данные в буфер после запроса иногда приходят некорректно. Я ставил "ловушки" по длине ответа и туда попадалось то, что длина ответа от устройств "иногда" меньше ожидаемой. Сейчас поставлен тройной фильтр - по длине данных, КС и совпадению адреса в ответе и запросе к устройству. В общем, всё указывает на некорректность ответов ПЛК. В дальнейшей обработке данных не сомневаюсь. В том числе и попадании некорректных данных в базу ибо это результат их обработки.
По "тройному" фильтру прога определяет: ещё раз запрашивать "этот" ПЛК или переходить к следующему устройству. Поставлена планка на 20 попыток. Если все они неудачны - то результат обработки (в организованной переменной)- 0. И эти нули видны в базе в объявленном выше количестве - за 4800 записей за сутки 10-20-30 пенок, равных нулю. А так - частенько просматривается 2 или 3 попытки, есть и другие значения, меньшие 20-ти. И это бы устроило (меньше 20-ти попыток), ибо корректный результат, после последней попытки запроса, есть.
Последний раз редактировалось Василий_S; 11.02.2014 в 22:11.
И мне интересно.
Есть такой сайт http://ru.wikipedia.org/wiki/Modbus, там в самом низу раздел Стандартные коды ошибок и под ним примеры, в котором явно наблюдается, что ответ может быть меньше ожидаемого, это один из вариантов
Спасибо, видимо мне стоит вернуться к анализу именно содержимого буфера, а не тольк,о как в прошлом делал, ограничиваться контролем длины ответа устройств.
Последний раз редактировалось Василий_S; 11.02.2014 в 19:43.
В общем, обнаружилась интересная вещь!
Длина ответа ПЛК на запрос мастером по модасу аскии совпадает с ожидаемой, но в месте, где находится КС - стоят нули!
Предистория такая:
Поставил первую ловушку. Т.е. по проверке длины ответа ПЛК (MSComm1.InBufferCount = 75 должно быть), находящегося в буфере (перед считыванием данных из буфера) организовал запись в текстовый файл содержание ответа, если длина ответа меньше 75. И - НИ ОДНОЙ ЗАПИСИ за сутки!!!
Смотрю вторую ловушку. Там идёт проверка по длине ответа, КС и совпадению адреса в запросе и ответе. Сделан цикл из 20 попыток запроса, если проверка неудачная. Если проверка проходит, то прога выходит из этого цикла. В случае достижения количества попыток запроса равным 20 делается запись в текстовый файл с содержанием ответа и сопутствующими атрибутами (адрес, время и номер ловушки). И там, в текстовом файле второй ловушки, ОБНАРУЖИВАЮ ОТВЕТ ПЛК требуемой длины, с корректными, кажись, данными и с НУЛЯМИ в месте расположения КС!!!
Что за хрень, а, разработчики ПЛК "Овен"?!
И таких ответов дофига и все с нулями в КС.
Последний раз редактировалось Василий_S; 13.02.2014 в 15:48.
Как бы Вам вежливо объяснить, чтоб искали ошибки прежде всего в своей программе, есть ведь сторонние модбас тестеры с выводом отправленных и принятых байт, вот если покажете скрин что и они показывают об некорректной работе овеновского оборудования, тогда и взывайте к разработчикам
Хорошо, но попозже. Ещё понаблюдаю, сутки - маловато. Но ноли в КС впечатляют.
Да и мне уже не до вежливости - столько сил и времени вгрохал.
Последний раз редактировалось Василий_S; 13.02.2014 в 16:05.
на сколько мне известно есть такая фича, когда вместо передачи последних единиц линия "отпускается". разные устройства это действие воспринимают по-разному. Некоторые - счита.ют единицами и все ок. Некоторые - считают нулями и всё плохо.
Столкнулись с этим при работе с МВ110-8АС. Решение одно - отключать проверку КС. либо вручную заменять последние нули в посылке на единицы и проверять КС.
А можно чуток поподробней? В плане того, что мне не понятно, что значит линия "отпускается".
Последний раз редактировалось Василий_S; 13.02.2014 в 16:26.
Ваши права
Ответить с цитированием