1 на милиони. Твърде малък шанс за да се притесняваш чак толкова много. Ако протокола имаше проблем, нямаше да е стандарт просъществувал десетилетия. А и дори е пренесен в същия вид на TCP. Без crc-то само. Там долните слоеве така или иначе я вършат тая работа.

не е 1 на милиони..

изобщо не е 1 на милион, зависи както от дължината на пакета така и от броя грешки, в зашумена среда и по-калпав хардуерен слой може ида не е достатъчно и за сравнително къси пакети : http://users.ece.cmu.edu/~koopman/roses ... bedded.pdf

Защо да се мъчи човек с модбъс, след като има CAN? Там имаш наготово 15-битово CRC от хардуера...
Относно чексумата - никога не е достатъчно силна... Т.е. правенето на safety не се ограничава до това да има надеждна чексума. Там е до вероятност за отказ - става сейфти когат минеш под определено число тая вероятност. В конкретния случай, дори да имаш SHA512, трябва да отчетеш фактори като:
- софтуера е калпав и в определена ситуация, примерно след като е вървял 33 дена без рестарт, не реагира правилно и въпреки че чексумата на излиза, оня вика всичко е ок - т.е. бъг който чупи защитата
- ако си изчистил софтуера, остава да предвидиш шанса точно когато има шум да дойде енергия свише (нЕкоя бърза частица) и твоя процесор да обърка сметката и да си помисли че е вярна
- и евентуално, че тоя процесор си бие отбой, щото някой забравил да сложи чексума на флаша и он сменим инструкциите и сложил един NOP точно дето трябвало да скочи към рекацията за грешка...
Та като цяло трябва да имаш идея какво гониш, какъв бюджет имаш, т.е. доколко има пазар, и т.н. Разбира се, добрите инженерни практики изискват да мислиш по тия теми дори когато правиш лампички за елха, колкото и да не е критично да мигнат грешно веднъж в годината.
Към темата има отношение и бит еррор рейта на физиката отдолу - ако е много зле работата и трябва да компенсираш с големи CRC-та, че и да възстановяваш данни с разните ECC-та, значи по-добре да не ползваш тая физика - поне когато имаш избор, т.е. по-добре смени физиката, която явно е неподходяща за даденото приложение/обкръжениет - щото ти хубаво ще детектнеш грешката, ще поискаш повторение, а твоето искане наобратно може пак да се счупи, и после пак грешка ама в друг бит, и после пак повторение - и какво стана с машината - ще работи ли или ще си оправя грешките? Особено ако се гони някакъв real time и има времеви ограничения, хич не е добре. Затова разните индустриални бъсове имат механизми за подобни ситуации - примерно затварят си очите за единична грешка, ако на следващия цикъл дойда верни данни. В CAN има броячи за тия неща на хардуерно ниво дори и те пазят от такива грешки, по-точно те информират че нещата не са каквито трябва да бъдат.
Ако се вълнуваш от тази тематика, най-добре стъпи на раменете на някого, т.е. базирай се на одобрен (сертифициран) сейфти стандарт и ако си наистина амбициозен може да си помислиш да направиш някакъв продукт. Имам предвид че инвестицията в разработването на "концепцията", т.е. стандарта, е сума за която дори хидроинжЕнера ще излезе от сараите...

Благодаря на gicho за хубавият пост. Съгласен съм на 100% с него.
Ако наистина средата е много зашумена и modbus или друг протокол генерира доста на често грешни . Явно изборът на комуникация не е правелен.
Това обаче е доста рядък случай. За CRC-16 не съм много съгласен , че може да се излъже толкова лесно. Не е невъзможно , но на практика е много трудно.
Все как трябва да съвпаднат няколко критерия за да се валидира пакета правилно (данни , позиция и стойността от предходното изчисление )

Ползвам подобно валидиране от много години , но с друг полином и на практика не съм изпадал в ситуация на невалидни данни с валидна чексума

Добър пост , Гичо.
Зададох въпроса, защото мой приятел заподозря -че му се е слуъчило такова нещо на реален обект.
Не е Модбус, но ползва същия полином. Стана ми интересно , та затова...
На Модбус има няколко реквизита - адрес,адрес на регистъра, брой байтове (в командите за трансфер на няколко регистътъра), които допълнително пазят от грешно поведение. Но четворна грешка в данните - примерно мощен шум по средата на байта ,между валиден старт и стоп битове- може би не се "хваща". Не знам как е в единичните команди , които са много къси.
На Модбус работят датчиците, с които отчитат акцизните стоки(масла,бои) - системи ИКУНК (ако не бъркам съкращението) . Преди десетина години , когато митниците дефинираха изискванията - така беше записано. Концентраторът си говори с митницата през интернет, но с датчиците - през Модбус.
В някои случаи може да има доста дълги пакети, и какви мерки са взети срещу шум - си е избор на разработчиците. Хубавото е, че става въпрос само за пари, не за промишлени опасности.

теорията на вероятностите е хубаво нещо, понякога е забавна, но трябва да се помни, че си е 'само теория'.
примерно - вероятността да срещнеш динозавър на улицата е точно 50% - може да го срещнеш, може и да не го срещнеш.
практически, дори очевидни неща като ези-тура, рядко са точно 50% - по-скоро се получава нещо като 49:51, зависи от броя хвърляния.

Ееее ти тука подвежда, ези-тура физически няма как да е 50:50... и въпреки че шанса да спукаш гума пред гумаджийница и на 200 км от най-близката такава да е еднакъв, и макар че много по често минаваш покрай гумаджийница гарантирано ще спукаш гума точно някъде в полето и естествено няма да имаш резервна. Да не забравяме, че освен теория на вероятностите има и теория за всемирната гадост....

А параграф 22 гласи, че ще спукаш гума пред гумарницата когато тя не работи...

Извинявай, изказвам само мнение :
Горните грешки ще ги хване още HAL-а на UART-a те нямат никаква "връзка" със слоя на Modbus RTU
Представи си следното. Приет байт по UART с валидно parity, валиден брой стоп битови и тнт който обаче е с грешни данни, приет някой следващ(и) байт(ове) с валино parity и грешни данни, и данните са се "нагодили" така, че да отговарят на чексумата на modbus телеграмата, а всички останяли байтове са с валидно parity и формат. Теоретично вероятноста това да се случи е нищожна. А ако това нещо се повтаря - грешката със сигурност е в логиката на програмата. Другото е , че в modbus няма дълги пакети , мисля че максимално е 16 байта при RTU / при ASCII е малко повече.

Към 240 байта е максимума. Май 256 байта за целия пакет. Данни плюс контролните байтове. Ограничава те само това че имаш 1 байт за дължина на пакета.

Да наистина е така !!! Гледам какъв буфер съм заделил но явно на мен ми е трябвал толкова навремето . Аз бях master, а ми трябваше RAM

Е все пак протокола не е мислен да преточва HD видео буфера се и добре да е 256 байта. Все пак мастера може да говори и с други устройства. А колко регистъра ще имаш физически реализирани е друг въпрос.

Panchev, и е така и не е така, на партито на серийния порт няма много смисъл да разчиташ, а дали може да се счупят данни така че crc16 да излезе и това може, колкото не ти се вярва има и друг вариант да се счупят данните и Crc-то и то пак да отговаря на данните. Ако ще се точат много данни не знам дали модбъс е начина.

Toni - Сигурно е така. Все пак и този протокол ми е почти набор. 10-ина години не съм пипвал сериина комуникация по RS-xxx, но ако ми се наложи бих направил това дето съм описал в началото на темата. Ползам CAN за по-прости неща като отгоре е пак някакво бутиково изпълнение на протокол. Все пак е безмислено използването на някой от стандартите за да си говорят 5-6 нода . Имам в предвид : Fieldbus , Profibus , ... . Имплементиране на подобен протокол е безмислено, ако не ти се налага връзка с външният свят. За по сериозни неща има EtherCAT на Beckoff който е real-time (1us) и за който има всякви устройства, а и създването на slave не е кой знае какво (LAN9252 на uChip), но темата отдавна отиде в съсвсем друга посока.