Протокол DCON зачем он ?

[KIB52]

Добрый день. Осваивая ПЛК и модули к ним ф. ОВЕН столкнулся, с ранее неизвестным мне, протоколом DCON. Как я заметил многие модули ввода-вывода могут опрашиваться, помимо Modbus, и по указанному выше протоколу. Вопрос знатокам. Зачем его ОВЕН стал использовать и в каких случаях его применять?

[Евгений Кислов]

Добрый день.


Зачем его ОВЕН стал использовать

Во время выпуска первой линейки модулей ОВЕН на российском рынке были популярны модули ADAM и ICP DAS с поддержкой этого протокола.
Поддержка протокола DCON позволила клиентам использовать наши модули при модернизации систем, где применялись модули этих производителей.


в каких случаях его применять?

В случае, если вы хотите заменить вышедший из строя модуль другого производителя, который ранее опрашивался по протоколу DCON.
Другие ситуации, в которых применение DCON было бы оправданным, мне сложно представить.

[keysansa]

DCON очень интересный протокол.
Обладает достаточной компактностью при передаче, при этом он символьный, т.е. сформировать команду и понять ответ легко без программ, плюс, в нем предусмотрен опрос и конфигурирование модулей ввода вывода изначально.
Да, можно и по модбас, через регистры конфигурировать, но стоит ошибиться регистром в функции записи, и все... А вот отдельная команда на конфигурирование, не позволит этого сделать.
ЗЫ. В целом, вопрос из разряда: почему на сегодняшний день существует ModbusTCP, Ethercat, Profinet, Sercos? Они ведь одно и тоже делают...

[Филоненко Владислав]

DCON очень интересный протокол.
Обладает достаточной компактностью при передаче, при этом он символьный, т.е. сформировать команду и понять ответ легко без программ, плюс, в нем предусмотрен опрос и конфигурирование модулей ввода вывода изначально.
Да, можно и по модбас, через регистры конфигурировать, но стоит ошибиться регистром в функции записи, и все... А вот отдельная команда на конфигурирование, не позволит этого сделать.
ЗЫ. В целом, вопрос из разряда: почему на сегодняшний день существует ModbusTCP, Ethercat, Profinet, Sercos? Они ведь одно и тоже делают...

Учитывая слабость DCON к помехам (из-за алгоритма проверки корректности пакета), а то и отсутствия защиты вообще в некоторых модулях - очень неоднозначный протокол получатся. Да и неструктурированный, пишу как хочу, что хочу, куда хочу.

[KIB52]

Благодарю за информацию.

[keysansa]

Учитывая слабость DCON к помехам (из-за алгоритма проверки корректности пакета), а то и отсутствия защиты вообще в некоторых модулях - очень неоднозначный протокол получатся. Да и неструктурированный, пишу как хочу, что хочу, куда хочу.

Вы, может забыли включить опцию CRC в протоколе? Так-то там CRC16...
ЗЫ. Не пишу - куда хочу, вам на такой запрос никто не ответит "ОК", а легко расширяемый.

[Евгений Кислов]

Так-то там CRC16....

"Там" - это где?
У DCON нет спецификации, но, например, во всех известных мне реализациях (в т.ч. нашей) в качестве контрольной суммы используется арифметическая сумма ASCII-кодов всех символов, предшествующих стоп-символу. Контрольная сумма занимает два символа, т.е. все возможные варианты - от 00 до FF. Это, мягко говоря, ограничивает ее надежность.

Пруфы:
http://ftp.icpdas.com/pub/cd/8000cd/napdos/7000/manual/7005_English.pdf (стр. 34)
https://www.reallab.ru/images/editor/catalog/nl-series/NL-16DO-16DI-8R.pdf (стр. 48)
http://elektron.pol.lublin.pl/elekp/instrukcje_LV/ADAM-4000_Manual_7ed.pdf (п. F-1)

[keysansa]

"Там" - это где?
У DCON нет спецификации, но, например, во всех известных мне реализациях (в т.ч. нашей) в качестве контрольной суммы используется арифметическая сумма ASCII-кодов всех символов, предшествующих стоп-символу. Контрольная сумма занимает два символа, т.е. все возможные варианты - от 00 до FF. Это, мягко говоря, ограничивает ее надежность.

Пруфы:
http://ftp.icpdas.com/pub/cd/8000cd/napdos/7000/manual/7005_English.pdf (стр. 34)
https://www.reallab.ru/images/editor/catalog/nl-series/NL-16DO-16DI-8R.pdf (стр. 48)
http://elektron.pol.lublin.pl/elekp/instrukcje_LV/ADAM-4000_Manual_7ed.pdf (п. F-1)

У D-CON один разработчик. Документация к протоколу поставляется с каждым устройством (ICP7000 - точно).

Да, прошу прощения, неверно указал CRC16 как их контрольную сумму. Там действительно сложение.

Я просто зацепился за "слабость к помехам".
Однако, CRC16 так же не обеспечивает 100% корректности передачи сообщения как сама по себе, так и потому, что передается по тому же каналу, что и тело сообщения.

И если Владислав не удовлетворен работой связи в условиях сильных помех, то ему нужно использовать ни Modbus, ни DCON, а провести изыскания по определению источников помех и их характеристик, разработать мероприятия по их устранению.
Да, возможно, от помех полностью избавиться не получится, и придется применять протоколы, которые защищаются циклическими кодами, которые позволяют проверять и восстанавливать более 2-3 бит.

ЗЫ. Есть, конечно, люди, считающие, что проложив 100м хорошего кабеля, 100% получат каждый цикл ПЛК достоверные данные, а так же, такие, кто считает, что 32 битный хэш, хоть и уменьшает скорость, но дает надежность 100%.

[melky]

keysansa а CRC16 не циклическая ? Это как же надо изголиться, чтобы CRC не давал 100% гарантии ? Тем более в Mobus...

Кажется это единственный способ расчета, когда пакет с CRC дает 0 на выходе. Больше нигде не видел такого. То есть пакет Modbus можно проверить дважды и убедиться, что он корректен.

[keysansa]

keysansa а CRC16 не циклическая ? Это как же надо изголиться, чтобы CRC не давал 100% гарантии ? Тем более в Mobus...

Кажется это единственный способ расчета, когда пакет с CRC дает 0 на выходе. Больше нигде не видел такого. То есть пакет Modbus можно проверить дважды и убедиться, что он корректен.

3 одновременно измененных бита в пакете, например. Или 2, один из которых - в теле самой CRC16.

ЗЫ. Гугление привело сюда https://habr.com/ru/post/428746/
Нам это преподавали на теории связи.

ЗЫЫ. DCON, за счет того, что у него не используется в пакете вся "полнота" байта, а только заглавные ASCII буквы английского алфавита, и ASCII цифры, тоже достаточно надежен (если сойдется контрольная сумма, но при разборе встретится символ, который, в случае ошибки и не буква и не цифра - тоже возникнет ошибка).
ЗЫЫЫ. Сама контрольная сумма тоже, только ASCII.

[Валенок]

3 одновременно измененных бита в пакете, например. Или 2, один из которых - в теле самой CRC16....
DCON, за счет того, что у него не используется в пакете вся "полнота" байта

Про RTU просто напомню про "полноту". Еще до проверки CRC. По мелочи :
Если битый адрес девайса в запросе (если в ответе - то смысл дальше проверять ?) нужно чтоб это была именно запись (иначе ответ станет мусором по отношению к запросу), при этом умудрится получить действующий битый адрес учитывая что довольно часто юзается только 1..4 младших бита. Лайфхак - адреса 1,2,4,8 наверно ))
Если битая функция - почти тоже самое как с адресом
Адрес бита/регистра - а поддерживает ли слейв всю область для случайного изменения ?
Кол-во регистров - надо чтоб тронулось не более 7 бит из 16-ти.
Если (!!) 16-ая - то так, чтоб сочетались кол-во регов и кол-во байт (и само кол-во байт в запросе)
В самих данных - да, проще. Но например для ф6. это 2 байта из 8-ми.
и т.д.
Т.е. еще до CRC вероятности такие себе для среднестатических запросов. Если конечно проверять не только crc ))


..Или 2, один из которых - в теле самой CRC16.
А другой бит где ? Вроде как может пойматся на уровне четности. С 3-мя тоже интересно - где ? (хотя конечно часто 8n1) И да - это у всех.

[Филоненко Владислав]

Вы, может забыли включить опцию CRC в протоколе? Так-то там CRC16...
ЗЫ. Не пишу - куда хочу, вам на такой запрос никто не ответит "ОК", а легко расширяемый.

1. CRC-8 (аналогичное CRC в 1-Wire)
2. Многие устройства поддерживают CRC в виде суммы символов
3. А есть, которые ВООБЩЕ не поддерживают