CRC16 для modbus, не повторяйте ошибок Опции

[Andrew2000]

...Уж больно "кривой" и запутанный протокол.

Назовите ровнее...
Давайте уважать пенсионеров - это все-таки 1979 год. И жив он до сих пор, думаю, потому, что он как раз очень простой, даже примитивный.
http://www.modbus.org/tech.php
http://freemodbus.berlios.de/

[Николай Иванович...]

Очень хотелось бы хоть кому-нить оторвать голову , за модбас...

Позже попробую

Удачи

[SpiritDance]

Давайте уважать пенсионеров - это все-таки 1979 год. И жив он до сих пор, думаю, потому, что он как раз очень простой, даже примитивный.

Угу вот давайте теперь уважать идиотов только за то что они пенсионеры. RTU-modbus на мыло! Единственный бинарный протокол имеющий право на жизнь - это slip(и подобные), остальное в помойку. И почему так мало кроликов пользует ASCII вариант modbus?

[Andrew2000]

Угу вот давайте теперь уважать идиотов ...

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

[rezident]

И почему так мало кроликов пользует ASCII вариант modbus?

Потому, что байтовая длина пакета, закодированного в Modbus ASCII, примерно вдвое больше, чем его же в RTU. Вообще ASCII-формат был придуман для связи, использующей модемы. В пакте формата ModBus ASCII присутствуют только "печатные" символы и нет байтов, которые модем способен понять как управляющие (его работой) символы и выйти из "прозрачного" режима трансляции данных, перейдя в командный режим.
А вообще я полностью согласен, что реализовывать поддержку потокола ModBus во вновь разрабатываемых устройствах нужно только в том случае, когда предполагается их использование в сетях совместно с устройствами, поддерживающими только ModBus. От использования ModBus как основного и единственного протокола связи нужно стараться уходить.

[sensor_ua]

А вообще я полностью согласен, что реализовывать поддержку потокола ModBus во вновь разрабатываемых устройствах нужно только в том случае, когда предполагается их использование в сетях совместно с устройствами, поддерживающими только ModBus. От использования ModBus как основного и единственного протокола связи нужно стараться уходить.

Мне вот он тоже не очень нравится. Вот только альтернативы никак не подберу. Нужен поддерживаемый различными SCADA, достаточно документированный и просто стандарт "де-факто" с близкими возможностями, менее перенапряженный проблемами совместимости железа (индейцы, ограничения адресов) у первичных разработчиков, чем Modbus.

[demiurg_spb]

Мне вот он тоже не очень нравится. Вот только альтернативы никак не подберу. Нужен поддерживаемый различными SCADA, достаточно документированный и просто стандарт "де-факто" с близкими возможностями, менее перенапряженный проблемами совместимости железа (индейцы, ограничения адресов) у первичных разработчиков, чем Modbus.

На самом деле, с появлением OPC проблема выбора протокола перестала существовать.
Выбирай что угодно, хоть свой собственный придумывай.
Главное предоставь свой OPC сервер - и дело в шляпе.
И это, на мой взгляд, правильно.
Установить ещё один канал rs485 в PC будет проще, и, возможно, надёжнее...
Да и цены и предложения на адаптеры usb<->rs485 благоприятствуют.
A SCADA системе уже всё равно, сколько физических каналов и какие там ходят протоколы.

Но стоит заметить, что доступность самой документации на OPC и ее доступность для мозга, могут слегка подпортить эту благостную картину...

[sensor_ua]

проблема выбора протокола перестала существовать.
Выбирай что угодно, хоть свой собственный придумывай.
Главное предоставь свой OPC сервер - и дело в шляпе.

Простите, но жонглирование "хотите-нехотите" не приветствую. OPC-сервер как технология, ИМХО, вообще диверсия для поднятия технологии COM от M$ после зарубывания DDE.
Практически у каждой SCADA есть хозяева. Мне приходится интегрировать свои девайсы в чужие системы самых разных пошибов. Чем меньше возникает вопросов от хозяев службе поддержки, тем быстрее решаются вопросы.
Если можете подсказать конкретный протокол с описанными (пусть и весьма расплывчато) свойствами, то, пожалуйста, подскажите.

[rezident]

demiurg_spb в общем-то правильно заметил. SCADA система не работает напрямую с протоколами. Это функция OPC-сервера. Если OPC-сервер сторонний, тогда ой! А если свой собственный, то какая проблема имплементировать туда поддержку хоть десятка различных протоколов? Наш OPC-сервер, например, работает, используя нашу же библиотеку (в виде DLL) с протоколами связи, где кроме нашего собственного протокола еще и ModBus до кучи поддерживается. При конфигурировании в OPC-сервере объектов просто выбирается из списка тот протокол, который поддерживается данным конкретным объектом.

[sensor_ua]

SCADA система не работает напрямую с протоколами. Это функция OPC-сервера.

Да, такое решение известно. Можете считать меня убогим, но это не есть правило.

Если OPC-сервер сторонний, тогда ой!

Сторонний. Если на вопрос "какая у вас SCADA?" в ответ получается вопрос "а какой у вас протокол?", то проще сказать "отвечающему" известное для него слово Пока слово "Modbus" срабатывает

[rezident]

sensor_ua, вы меня видимо не понимаете. Я не против ModBus в принципе, особенно когда идет разговор о внедрении своих устройств в чужие сети. Я лишь за то, чтобы не ограничиваться только ModBus при реализации протоколов связи. Об этом я собственно уже написал в посте #20.

[sensor_ua]

Я лишь за то, чтобы не ограничиваться только ModBus при реализации протоколов связи

Я за то же, только пока не попалось приемлемого протокола. У нас есть свой, но лучше бы его не было Известны несколько удобных протоколов, кое-какие внедряем, но почему-то их не знают;( (и хуже - ни о каких "своих" слышать не хотят) там, где приходится интегрироваться

[demiurg_spb]

Простите, но жонглирование "хотите-нехотите" не приветствую. OPC-сервер как технология, ИМХО, вообще диверсия для поднятия технологии COM от M$ после зарубывания DDE.
Практически у каждой SCADA есть хозяева. Мне приходится интегрировать свои девайсы в чужие системы самых разных пошибов. Чем меньше возникает вопросов от хозяев службе поддержки, тем быстрее решаются вопросы.

Я настаиваю.
При наличии OPC сервера вопросы бы отсутствовали вовсе.

Если можете подсказать конкретный протокол с описанными (пусть и весьма расплывчато) свойствами, то, пожалуйста, подскажите.

К сожалению, посоветовать ничего не могу, ибо не силён в разнообразии протоколов.
Знаю лишь modbus и owen, знаком с profibus и CAN.
Знаю, что у Термодата свой протокол есть, а что они придумали - загадка....
Для военного корабля делали систему на С166-ых с использованием их собственных примитивных ASCII протоколов. Я был поражён их безбашенности (даже CRC не считают, а просто суммируют байты посылки).
Большинство производителей приборов автоматизации в Росии используют modbus - это видимо по инерции и(или) по незнанию хорошей альтернативы...

На самом деле, вопрос, поднимаемый Вами, весьма интересен.

Вспомнил, что давненько уже ничего не слышно о протоколе ПИРАМИДА.
Посмотрите на него - может это оно...

[one_man_show]

Если на вопрос "какая у вас SCADA?" в ответ получается вопрос "а какой у вас протокол?", то проще сказать "отвечающему" известное для него слово Пока слово "Modbus" срабатывает

Именно по этой причине продолжаю в ряде железок использовать Modbus, так как это для Заказчика понятная (известная) вещь. Иных протоколов он может и не знать))) Переубеждение не всегда на руку всему проекту в целом, так как используемый протокол не есть самая важная его деталь.

Использую оба варианта протокола, то есть и ASC тоже, а именно, для отладки, так как на стадии отладки всё, что творится в канале можно увидеть "глазами" без специального софта, подключив параллельно дополнительный преобразователь 232-485 и ноутбук с обычным терминалом.

Кроме того, когда у тебя есть реализованные и проверенные годами библиотеки для различных аппаратных платформ, конечно не заморачиваешься, а начинаешь именно со стандарта дефакто. И еще, когда используешь самодельный протокол и одновременно с этим приходится использовать самодельный софт верхнего уровня, то когда начинают вылезать косяки, да еще на территории заказчика, да еще через через какое-то время после запуска.....куча вопросов тогда возникает. И хотя авторы протокола в таком случае под рукой, от этого не легче. В случае применения известного протокола, чем он более "засижен", тем лучше, так как многие косяки его реализации выгребли еще лет 10-20 назад. И использовать самодельный софт верхнего уровня не приходится, берешь любую СКАДу, даже без лицензии, в демо-режиме, и спокойно и быстро делаешь тестовый софт (канальную часть) - имитатор софта Заказчика, так как в любой СКАДе всегда есть Модбас ))) Пока есть)))

[sensor_ua]

о протоколе ПИРАМИДА

Знаем и по-чуть-чуть применяем, но более в исследовательских целях, чем по делу.
Мне удобны протоколы, у которых в шапке есть длина сообщения, а также адрес оптравителя и получателя - такие, которые можно было бы аппаратно разгребать (мне аппаратно не нужно, но логика транспорта в таком варианте прямоугольная) - типа UDP, SimpliciTI, Virtual Wire.