Подключение устройств с нестандартными протоколами

[IVM]

Здесь то же про этот расходомер: http://www.owen.ru/forum/showthread.php?t=517&page=13

[Log_Stas]

ПЛК "ОВЕН" не поддерживают HART протокол.

Понятно, что не поддерживает. Потому и пишу в теме про нестандартные протоколы.

Здесь то же про этот расходомер: http://www.owen.ru/forum/showthread.php?t=517&page=13

Здесь у человека считывание происходит нормально, он читает всю посылку с Гипера в массив 40 байт, а у меня максимум 16 байт считывается. Вот в чем затык.
capzar , какой кусок кода привести? Абсолютно весь код я взял из примера по работе с библиотекой SysLibCom.

[Log_Stas]

Ну вот весь файлик. Там правда еще есть код, относящийся к дисплею, но основное меня интересует в функциональном блоке send_command_bin

[Log_Stas]

Вот посмотрите на скриншотах, видно, что функция SysComRead всегда возвращает не более 15 байт(read_byte=15), хотя я точно знаю, что в посылке больше байт. Можете объяснить, почему так происходит?
1.jpg
2.jpg

[Log_Stas]

Это в аргументах функции SysComRead? Попробовал, тоже самое, 15 байт и все.

[Log_Stas]

capzar, о каком цикле речь? Можете подробнее разжевать, что я могу пропустить, а то совсем запутался. Т.е. после того, как функция приняла 15 байт заканчивается какой то цикл? Подскажите, как проверить, что-то теряю или нет из посылки. Иеще такой момент - на скриншоте есть хорошо заметная преамбула в буфере приема - семь байт 0xFF, а по документации их должно быть восемь. Пропускает первый байт? Но почему?

[Log_Stas]

Вот для лучшего понимания наглядный пример. Ответ от прибора приходит, но последние байты считать не могу.
P_2.jpg
Как их можно считать, подскажите.

[Log_Stas]

Да, есть. Это: преамбула - 8 байт 0хFF, стартовый байт - 0х06, адрес ведомого - 0х01, команда - 0х21, длина ответа - 0х08, два байта статуса, шесть байт - данные запрошенного параметра и контрольная сумма по XOR.

[Scream]

Писать надо что-то в таком роде.
Ждём ответ, знаем что он должен быть 20 байт
Принимающий буфер не менее 20, хоть 30 пусть будет
Цикл 1
Получаем данные в размере 8 байт, кладём их в принимающий массив и сохраняем переменную сколько положили.
Цикл 2
Получили еще 8 байт, складываем в тот же массив, но со смещением из сохраненной переменной.
Складываем сколько пришло (8) с тем что было (8) в ту же переменную = 16, 16 < 20 (ожидаемого), значит ждём еще.
Цикл 3
Получаем 4 байта, делаем как в цикле 2.

Перед получением можно запомнить время ПЛК и в каждом шаге проверять не превысило ли оно секунды 3 например (таймаут), значит сбрасываем всё и посылаем запрос опять.
Всё это работает довольно быстро и таким образом не важно сколько уйдёт циклов на приём, главное чтобы не превысил таймаут.

[Log_Stas]

Что сейчас заметил: убрал проверку получения байт и сделал вот так
byte_read1:=SysComRead(port_number, ADR(buf_otvet), 8, 0);
byte_read2:=SysComRead(port_number, ADR(otvet), 8, 0);
т.е. два вызова функции подряд с чтением восьми байт. Результат озадачил. Две функции подряд возвращают все те же байты и не больше.
Безымянный.jpg
Как это трактовать, я уже не знаю. Ведь на осциллограмме я четко вижу продолжение посылки еще на несколько байт минимум...