- В этой теме 22 ответа, 3 участника, последнее обновление 1 год, 1 месяц назад сделано
.
-
Сообщения
-
Ваш ВТД, который не Modbus это из той же серии, что и Меркурий, Пульсар и прочее, применили расчет CRC аналогичный Modbus протоколу и на каждом углу кричат «у нас Modbus подобный протокол», а там им и не пахнет вовсе..
Вот что ваш ВТД с протоколом, разработанным ООО НПФ «ДИНФО» на самом деле.
Имхо, его надо в отдельный драйвер и не выеживаться 🙂Если драйвер работает только с приборами ВТД, а другие производители данный вариант протокола в принципе не используют, то наверное здесь нужен отдельный драйвер именно для ВТД. При этом такой драйвер может использовать общие библиотеки с драйвером Модбас.
Название DrvModbusJP говорит пользователю о том, что драйвер работает со стандартным протоколом Modbus, но имеет дополнительные функции по обработке данных, поддерживает больше команд или реализует другой подход к настройке по сравнению с DrvModbus.
Хотя здесь есть и другой подход. Возможно, Ваш драйвер настолько универсальный, что его можно настроить и под приборы ВТД, и под другие потенциально похожие протоколы.
Иногда обдумываю идею сделать драйвер-конструктор для обмена вида запрос-ответ. То есть пользователь формирует в настройках формат пакета, способ расчёта КС, расшифровку ответов и т.п. Тогда можно будет делать шаблоны для большого спектра устройств. Но в названии такого драйвера слово Modbus уже лишнее.
в рамках запрос-ответ практически нереально.
Все дело в расчете CRC , не всегда она рассчитывается с 1-го и до CRC, бывают такие чудеса, что закачаешься…протокол DF1 тому пример, надо на лету вычленять служебные байты, так как они не участвуют в расчете контрольной суммы.
Вот конструкторы в рамках одного протокола вполне возможны на практике.
Для расчёта CRC или CheckSum нужно добавить параметры с какого по какой байт считать. Баланс между универсальностью, удобством и здравым смыслом — творческая задача.
- Вы должны авторизироваться для ответа в этой теме.