Вид для печати
Добрый день. Осваивая ПЛК и модули к ним ф. ОВЕН столкнулся, с ранее неизвестным мне, протоколом DCON. Как я заметил многие модули ввода-вывода могут опрашиваться, помимо Modbus, и по указанному выше протоколу. Вопрос знатокам. Зачем его ОВЕН стал использовать и в каких случаях его применять?
Добрый день.
Во время выпуска первой линейки модулей ОВЕН на российском рынке были популярны модули ADAM и ICP DAS с поддержкой этого протокола.Цитата:
Зачем его ОВЕН стал использовать
Поддержка протокола DCON позволила клиентам использовать наши модули при модернизации систем, где применялись модули этих производителей.
В случае, если вы хотите заменить вышедший из строя модуль другого производителя, который ранее опрашивался по протоколу DCON.Цитата:
в каких случаях его применять?
Другие ситуации, в которых применение DCON было бы оправданным, мне сложно представить.
DCON очень интересный протокол.
Обладает достаточной компактностью при передаче, при этом он символьный, т.е. сформировать команду и понять ответ легко без программ, плюс, в нем предусмотрен опрос и конфигурирование модулей ввода вывода изначально.
Да, можно и по модбас, через регистры конфигурировать, но стоит ошибиться регистром в функции записи, и все... А вот отдельная команда на конфигурирование, не позволит этого сделать.
ЗЫ. В целом, вопрос из разряда: почему на сегодняшний день существует ModbusTCP, Ethercat, Profinet, Sercos? Они ведь одно и тоже делают...
Учитывая слабость DCON к помехам (из-за алгоритма проверки корректности пакета), а то и отсутствия защиты вообще в некоторых модулях - очень неоднозначный протокол получатся. Да и неструктурированный, пишу как хочу, что хочу, куда хочу.Цитата:
Сообщение от keysansa
Благодарю за информацию.
Вы, может забыли включить опцию CRC в протоколе? Так-то там CRC16...Цитата:
Сообщение от Филоненко Владислав
ЗЫ. Не пишу - куда хочу, вам на такой запрос никто не ответит "ОК", а легко расширяемый.
"Там" - это где?Цитата:
Сообщение от keysansa
У DCON нет спецификации, но, например, во всех известных мне реализациях (в т.ч. нашей) в качестве контрольной суммы используется арифметическая сумма ASCII-кодов всех символов, предшествующих стоп-символу. Контрольная сумма занимает два символа, т.е. все возможные варианты - от 00 до FF. Это, мягко говоря, ограничивает ее надежность.
Пруфы:
http://ftp.icpdas.com/pub/cd/8000cd/...05_English.pdf (стр. 34)
https://www.reallab.ru/images/editor...DO-16DI-8R.pdf (стр. 48)
http://elektron.pol.lublin.pl/elekp/...Manual_7ed.pdf (п. F-1)
У D-CON один разработчик. Документация к протоколу поставляется с каждым устройством (ICP7000 - точно).Цитата:
Сообщение от Евгений Кислов
Да, прошу прощения, неверно указал CRC16 как их контрольную сумму. Там действительно сложение.
Я просто зацепился за "слабость к помехам".
Однако, CRC16 так же не обеспечивает 100% корректности передачи сообщения как сама по себе, так и потому, что передается по тому же каналу, что и тело сообщения.
И если Владислав не удовлетворен работой связи в условиях сильных помех, то ему нужно использовать ни Modbus, ни DCON, а провести изыскания по определению источников помех и их характеристик, разработать мероприятия по их устранению.
Да, возможно, от помех полностью избавиться не получится, и придется применять протоколы, которые защищаются циклическими кодами, которые позволяют проверять и восстанавливать более 2-3 бит.
ЗЫ. Есть, конечно, люди, считающие, что проложив 100м хорошего кабеля, 100% получат каждый цикл ПЛК достоверные данные, а так же, такие, кто считает, что 32 битный хэш, хоть и уменьшает скорость, но дает надежность 100%.
keysansa а CRC16 не циклическая ? Это как же надо изголиться, чтобы CRC не давал 100% гарантии ? Тем более в Mobus...
Кажется это единственный способ расчета, когда пакет с CRC дает 0 на выходе. Больше нигде не видел такого. То есть пакет Modbus можно проверить дважды и убедиться, что он корректен.
3 одновременно измененных бита в пакете, например. Или 2, один из которых - в теле самой CRC16.Цитата:
Сообщение от melky
ЗЫ. Гугление привело сюда https://habr.com/ru/post/428746/
Нам это преподавали на теории связи.
ЗЫЫ. DCON, за счет того, что у него не используется в пакете вся "полнота" байта, а только заглавные ASCII буквы английского алфавита, и ASCII цифры, тоже достаточно надежен (если сойдется контрольная сумма, но при разборе встретится символ, который, в случае ошибки и не буква и не цифра - тоже возникнет ошибка).
ЗЫЫЫ. Сама контрольная сумма тоже, только ASCII.
Про RTU просто напомню про "полноту". Еще до проверки CRC. По мелочи :Цитата:
3 одновременно измененных бита в пакете, например. Или 2, один из которых - в теле самой CRC16....
DCON, за счет того, что у него не используется в пакете вся "полнота" байта
Если битый адрес девайса в запросе (если в ответе - то смысл дальше проверять ?) нужно чтоб это была именно запись (иначе ответ станет мусором по отношению к запросу), при этом умудрится получить действующий битый адрес учитывая что довольно часто юзается только 1..4 младших бита. Лайфхак - адреса 1,2,4,8 наверно ))
Если битая функция - почти тоже самое как с адресом
Адрес бита/регистра - а поддерживает ли слейв всю область для случайного изменения ?
Кол-во регистров - надо чтоб тронулось не более 7 бит из 16-ти.
Если (!!) 16-ая - то так, чтоб сочетались кол-во регов и кол-во байт (и само кол-во байт в запросе)
В самих данных - да, проще. Но например для ф6. это 2 байта из 8-ми.
и т.д.
Т.е. еще до CRC вероятности такие себе для среднестатических запросов. Если конечно проверять не только crc ))
А другой бит где ? Вроде как может пойматся на уровне четности. С 3-мя тоже интересно - где ? (хотя конечно часто 8n1) И да - это у всех.Цитата:
..Или 2, один из которых - в теле самой CRC16.
1. CRC-8 (аналогичное CRC в 1-Wire)Цитата:
Сообщение от keysansa
2. Многие устройства поддерживают CRC в виде суммы символов
3. А есть, которые ВООБЩЕ не поддерживают