Здесь то же про этот расходомер: http://www.owen.ru/forum/showthread.php?t=517&page=13
Вид для печати
Здесь то же про этот расходомер: http://www.owen.ru/forum/showthread.php?t=517&page=13
Понятно, что не поддерживает. Потому и пишу в теме про нестандартные протоколы.
Здесь у человека считывание происходит нормально, он читает всю посылку с Гипера в массив 40 байт, а у меня максимум 16 байт считывается. Вот в чем затык.
capzar , какой кусок кода привести? Абсолютно весь код я взял из примера по работе с библиотекой SysLibCom.
Ну вот весь файлик. Там правда еще есть код, относящийся к дисплею, но основное меня интересует в функциональном блоке send_command_bin
Вот посмотрите на скриншотах, видно, что функция SysComRead всегда возвращает не более 15 байт(read_byte=15), хотя я точно знаю, что в посылке больше байт. Можете объяснить, почему так происходит?
Вложение 29437
Вложение 29438
Это в аргументах функции SysComRead? Попробовал, тоже самое, 15 байт и все.
capzar, о каком цикле речь? Можете подробнее разжевать, что я могу пропустить, а то совсем запутался. Т.е. после того, как функция приняла 15 байт заканчивается какой то цикл? Подскажите, как проверить, что-то теряю или нет из посылки. Иеще такой момент - на скриншоте есть хорошо заметная преамбула в буфере приема - семь байт 0xFF, а по документации их должно быть восемь. Пропускает первый байт? Но почему?
Вот для лучшего понимания наглядный пример. Ответ от прибора приходит, но последние байты считать не могу.
Вложение 29459
Как их можно считать, подскажите.
Да, есть. Это: преамбула - 8 байт 0хFF, стартовый байт - 0х06, адрес ведомого - 0х01, команда - 0х21, длина ответа - 0х08, два байта статуса, шесть байт - данные запрошенного параметра и контрольная сумма по XOR.
Писать надо что-то в таком роде.
Ждём ответ, знаем что он должен быть 20 байт
Принимающий буфер не менее 20, хоть 30 пусть будет
Цикл 1
Получаем данные в размере 8 байт, кладём их в принимающий массив и сохраняем переменную сколько положили.
Цикл 2
Получили еще 8 байт, складываем в тот же массив, но со смещением из сохраненной переменной.
Складываем сколько пришло (8) с тем что было (8) в ту же переменную = 16, 16 < 20 (ожидаемого), значит ждём еще.
Цикл 3
Получаем 4 байта, делаем как в цикле 2.
Перед получением можно запомнить время ПЛК и в каждом шаге проверять не превысило ли оно секунды 3 например (таймаут), значит сбрасываем всё и посылаем запрос опять.
Всё это работает довольно быстро и таким образом не важно сколько уйдёт циклов на приём, главное чтобы не превысил таймаут.
Что сейчас заметил: убрал проверку получения байт и сделал вот так
byte_read1:=SysComRead(port_number, ADR(buf_otvet), 8, 0);
byte_read2:=SysComRead(port_number, ADR(otvet), 8, 0);
т.е. два вызова функции подряд с чтением восьми байт. Результат озадачил. Две функции подряд возвращают все те же байты и не больше.:confused:
Вложение 29464
Как это трактовать, я уже не знаю. Ведь на осциллограмме я четко вижу продолжение посылки еще на несколько байт минимум...