koyodza (15.11.2012 13:51, просмотров: 284) ответил zeleny на Сразу. Требование паузы 3.5 char устарело сразу после появления интерфейсов USB/Ethernet/Bluetooth-RS485, где такие точные паузы не выдерживаются, и могут быть разрывы в середине пакетов. Конец пакета определяетя по правильной CRC, ошибки - по-
- почему ? даже если адрес и CRC правильные ? - zeleny(15.11.2012 13:53)
- А потому что CRC призвана защитить(обнаружением) посылку от помех на линии. И что Вы будете делать если пройдет помеха и CRC совпадет? При помехах на линии и так есть вероятность принять неправильную посылку, а Вы еще хотите усугубить ситуацию и abivan(30 знак., 15.11.2012 14:28)
- помеха пройдет и при наличии паузы - zeleny(15.11.2012 14:32)
- там CRC может ошибочно совпадать и без помех, данные внутри пакета могут быть разные. Получится огрызок - koyodza(15.11.2012 14:31)
- данные внутри пакета не пройдут по условию начала пакета, которое распознается именно по тайм-ауту приема - zeleny(15.11.2012 14:35)
- а это кто написал? "Конец пакета определяетя по правильной CRC, ошибки - по тайм-ауту" - koyodza(15.11.2012 14:38, ссылка)
- данные внутри пакета не пройдут по условию начала пакета, которое распознается именно по тайм-ауту приема - zeleny(15.11.2012 14:35)
- потому, что потом начнутся глюки, типа по какому-то адресу какое-то значение не записывается или не читается, потому что CRC совпала в середине пакета - koyodza(15.11.2012 14:06)
- не начнутся - начало пакета определяется по тайм-ауту приема - zeleny(15.11.2012 14:09)
- повторяю, идите нах с этими "новшествами". Не забывайте, что кто-то может почитать вашу писанину и сделать большую **йню не подумавши. Есть только один критерий конца пакета в ModBus RTU - таймаут, и всё. Не нравится - переходите на ModBus ASCII koyodza(21 знак., 15.11.2012 14:15)
- вообще я использую примерно такой алгоритм koyodza(782 знак., 15.11.2012 14:28 - 17:41)
- тоже иногда испльзую, только обычно 0xAA или 0x85 в качестве маркера начала пакета, заодно и синхронизации модемов (типа построенных на fx469 и т.п.), хотя в нынешних проектах неактуально, поэтому оставляю чистый modbus. - AVF(16.11.2012 10:54)
- речь шла о ModBus RTU, а не о проприетарных протоколах - koyodza(16.11.2012 11:18)
- ну а остальное там модбас rtu. добавлен маркер в начале передачи. он даже в CRC не участвует - AVF(16.11.2012 12:08)
- речь шла о ModBus RTU, а не о проприетарных протоколах - koyodza(16.11.2012 11:18)
- Полностью согласен (но п.1 не использую). Вообщето на сайте modbus.org есть, в пдф-ках, полный граф состояний и переходов и для мастера и для слейва, который совпадает с koyodz'овским (кроме ноу-хау). - Скрипач(15.11.2012 18:14)
- Может быть п.1 заменить простым включением передатчика (в единицу) на время таймаута (или несколько больше его), чтобы приемный буфер очистился от хлама? Тогда вообще никаких терок со стандартом не будет. - sin(15.11.2012 16:42,
) - я бы 1-й пункт убрал потому как 255 есть в стандарте(From 248 to 255 - Reserved) это значит что может появится адрес типа Broadcast хз зачем, а Вы его отбросив возьмете Function code, который совпадет с вашим адресом. Начнете делать проверку abivan(42 знак., 15.11.2012 14:41)
- не должен появиться, BROADCAST определён как нулевой. Можете убрать, я сразу предупредил, что этот пункт - собственное ноу-хау koyodza(264 знак., 15.11.2012 14:48 - 14:50)
- я имел в виду ситуацию, когда разработчику протокола взбредет в голову использовать резерв(добавить фичу), ХЗ для чего, может для хабов каких. И Ваше старое устройство начнет ловить "ошибочные" пакеты. - abivan(15.11.2012 16:12)
- если кому-то взбредёт в голову какое-то другое усовершенствование, то совместимость тоже может быть нарушена. У меня гарантируется совместимость с устройствами, которые соответствуют стандарту - koyodza(15.11.2012 16:16)
- я про изменение стандарта. Имеют право, раз зарезервировали. И тогда Ваши старые устройства перестанут удовлетворять стандарту. - abivan(15.11.2012 16:26)
- убрал. Не хотите - не делайте - koyodza(15.11.2012 17:42)
- я про изменение стандарта. Имеют право, раз зарезервировали. И тогда Ваши старые устройства перестанут удовлетворять стандарту. - abivan(15.11.2012 16:26)
- если кому-то взбредёт в голову какое-то другое усовершенствование, то совместимость тоже может быть нарушена. У меня гарантируется совместимость с устройствами, которые соответствуют стандарту - koyodza(15.11.2012 16:16)
- я имел в виду ситуацию, когда разработчику протокола взбредет в голову использовать резерв(добавить фичу), ХЗ для чего, может для хабов каких. И Ваше старое устройство начнет ловить "ошибочные" пакеты. - abivan(15.11.2012 16:12)
- не должен появиться, BROADCAST определён как нулевой. Можете убрать, я сразу предупредил, что этот пункт - собственное ноу-хау koyodza(264 знак., 15.11.2012 14:48 - 14:50)
- тоже иногда испльзую, только обычно 0xAA или 0x85 в качестве маркера начала пакета, заодно и синхронизации модемов (типа построенных на fx469 и т.п.), хотя в нынешних проектах неактуально, поэтому оставляю чистый modbus. - AVF(16.11.2012 10:54)
- вообще я использую примерно такой алгоритм koyodza(782 знак., 15.11.2012 14:28 - 17:41)
- повторяю, идите нах с этими "новшествами". Не забывайте, что кто-то может почитать вашу писанину и сделать большую **йню не подумавши. Есть только один критерий конца пакета в ModBus RTU - таймаут, и всё. Не нравится - переходите на ModBus ASCII koyodza(21 знак., 15.11.2012 14:15)
- не начнутся - начало пакета определяется по тайм-ауту приема - zeleny(15.11.2012 14:09)
- бывают коллизии (не говоря о "вааще неправильно") - Vit(15.11.2012 13:57)
- А потому что CRC призвана защитить(обнаружением) посылку от помех на линии. И что Вы будете делать если пройдет помеха и CRC совпадет? При помехах на линии и так есть вероятность принять неправильную посылку, а Вы еще хотите усугубить ситуацию и abivan(30 знак., 15.11.2012 14:28)
- почему ? даже если адрес и CRC правильные ? - zeleny(15.11.2012 13:53)