Здесь то же про этот расходомер: 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
Как это трактовать, я уже не знаю. Ведь на осциллограмме я четко вижу продолжение посылки еще на несколько байт минимум...
Ну вот и косяк найден... в функции инициализации COM порта размер буфера стоит 0. Так было в примере, с которого я взял этот код. Поставил размер 32 и все заработало, считывается вся посылка. :) Всем спасибо за помощь!
Вольд, если код заработал сразу после того, как я изменил значение и перестает работать, как только возвращаю обратно 0, то я склонен думать, что в этом. Если есть иные соображения - поделитесь.
А как же у вас раньше вообще что-то принималось ?
Не могу сказать. Я же не знаю, как работают эти функции. Может у нее есть некое дефолтное значение.
Если немного не в тему, то прошу прощения.
Вопрос такой: для ПЛК110 порт СОМ0 - это порт RS-485-1. Но CoDeSys ругается и не компилирует программу, если использовать СОМ0. Нормально компилируется, только начиная с СОМ1.
Как быть? Нужен именно RS-485-1.
Здравствуйте. Помогите связать ПЛК110-60 с ЛИР 520 по RS232.
Вот параметры.
http://skbis.ru/pdf/readout/LIR510_520_530.pdf
Связь контроллера с устройством цифровой индикации через кабель КС14. Кабель подключаю к контроллеру в порт RS232-Debug
Добрый день. Не подскажу. Не помню.
Требования простые:
Порт RS-485 или RS-232. Если 232 - то надо понимать какие ножки задействованы. Если RFID питается от самого порта ПЛК - тут сложнее.
Ну и наличие описания протокола обмена.
В ПЛК все проще:
Команда открыть порт
Формируем и отправляем запрос информации (как это описано в протоколе обмена).
Ждем заданное время ответ.
Получаем ответ. Разбираем его, выделяя полезную информацию.
Если не нужно снова опрашивать - закрываем порт.
Если найдете такие устройства с ModBus (что вряд ли) - сэкономите себе немного времени и денег.
Добрый день..а есть какие то наработки по эл.счетчикам Энергомера....интересует серия СЕ301
Кстати вопрос к гуру. Предположим мы выставили таймаут 1500 мс, а ответ прибора будет всего 15 байт - что произойдет ?
собственно есть протоколы, которые а) не имеют фиксированной длины ответа и б) не имеют размера ответа в его заголовке.
Собственно МЭК61107 один из таких протоколов.