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

[keysansa]

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

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

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

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

"Там" - это где?
У 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)

[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%.

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

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

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