Мне безразлично кто и что НЕ делает и по какой причине. Я говорю о том, как НАДО делать и как делаю сам.

Ну и пусть сыпет. Всегда возможна, пусть даже и нештатая ситуация, когда посыпется мусор и с такой ситуацией надо уметь БЕСПРОБЛЕМНО справляться.

Тем не менее тот же MODBUS начинался тогда, когда помянутая Вами тини была-бы более, чем крута на фоне чего либо типа 8080 мегагерцового. Тратить ресурсы на самом деле не приходится особо, поскольку первоначальный отсев мусора идет уже по ошибкам фиксируемым UART, потом по тем тому самому 1,5 интервалу. В случае MODBUS контроль адреса и так далее....

Которые гарантированно обеспечиваются активизацией передатчика а не навешиванием сопливых растяжек.



Вот в начале и делается 1,5 байтовая пауза, кторая
1) Обепечивает признак битого пакета для любого мусора возможно идущего из линии.
2) Обеспечивает гарантрованный стоп бит и соответственно захват байтовой синхронизации UART-ом.
Для других протоколов может быть достаточно однобайтовой паузы только для синхронизации.

Ну не большая, но много именно с хлипенькими "растяжками" внутри.
Причем это в основном левая китайская перемаркировка. Отличаются от настоящих легко по поведению при замыкании линии - растяжки сразу идут лесом в вылезает истинное личико .
По этой причине я и писал ранее TRUE Falsafe.

Спорить с вами бесполезно.
Вы зациклились на своём решении и не видите его недостатков.
Поверьте что никогда не поздно учиться.
Если не доверяете мне с непрерывным опытом разработки КИПиА и интеграции чуть более 16 лет - я не в обиде.
Но не прислушиваться к корифеям типа zltigo по меньшей мере самонадеянно.

Гарантированный - единственный. Он же, в отличие от растяжек, работающий ВСЕГДА, а не только на короткой линии и при низком уровне помех.

Это абсолютно правильно, ибо если адрес не ваш, то уже пофиг и пакет и его целостность - пакет уже игнорируется и становимся в ожидание следующего фрейма без лишних разбирательств.

Таймер 1,5 как видно из этого супер алгоритма, Вам оказался не по уму

К словам цепляетесь... перефразирую вопрос: Как ВЫ делаете активную паузу, если мастер ПК?

я не пытаюсь вам доказать свою правду.... я хочу учиться... у меня тоже не малый опыт... (с 2000 года, теже 16+, наверно мы ровесники ))) )
Я просто первый раз слышу об активных паузах. всегда линия 485го растягивалась. без растяжек даже на столе могло не работать. я не работал на линиях 1000 метров.... может вы и корифей типа zltigo речь ведёте о 2-3 км.... или десятки км.... тут я пасс.
Но если это до 500м.... тут у меня есть опыт теже, 16 лет.... и растяжки работают на ура. приимущества: 1. не надо заморачиваться с активными паузами, 2 не надо переваривать мусор из-за его отсутствия (а что его нет... на практике проверенно, а не теоретические выводы).

Наверно я начну со следующей разработки делать активные паузы... просто я хочу понять - ради чего? научите меня правильно готовить 485? Пока я преимуществ в активной паузе не вижу.

ps, да, кстате.... 2demiurg_spb У вас не было задачи с десктопного ПК под виндой или линуксом по MODBUS-у работать? Или промышленная ЭВМ должна быть мастером в MODBUS-е? Как вы добиваетесь в таких случаях активной паузы? (опять же, я не хочу вам навязывать своё решение. я своё мнение высказал, вам решать. я хочу узнать как вы технически решаете подобные задачи? Ну чтоб научиться... ведь ни когда не позно )

я считаю пакет с битым црц. поэтому мне не пофиг.

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

Если под ПК Вы очевидно понимаете Windows/Linuх и иже с ними, то ни мастеров ни слейвов MODBUS под такой "ПК" не бывает. Вот такая печальная правда. Под голый ПК, ака DOS - без проблем. Так же без проблем не уродливый MODBUS-RTU, а протоколы, например, на байтстаффинге. В этом случае достаточно 9-10 битовой паузы для захвата байтовой синхронизации и для этого годится посылка 0xFF.
То, что пытаются делать на "ПК" без аппаратной поддержки, это что-то похожее на MODBUS и только в некоторых условиях и с не всяким оборудованием работоспособное. Да, типичный способ ЗАСТАВИТЬ хоть в каких-то условиях работать - прицепить растяжки. Цену такого "решения", если не понимаете, поймете решив задачку в конце поста.
Соответственно при работе с "ПК" я использую свои конверторы протоколов на Ethernet.
Они отрабатывают все паузы и протокольные таймауты, включая таймауты неответа слейвов.

Займемся арифметикой.
Имеем витую пару 100 Ом волнового и соответственно 100 омный терминатор.
Вопрос первый, какое сопротивление должны иметь волшебные растяжки, дабы обеспечить гарантированную паузу, ну, например, при 3.3V питании и стандартных 200mV порогах срабатывания приемника?

Вы не правы. Никто не должен там ничего никому держать.
Пример хорошего протокола для RS485- тот же Модбас: пауза в Модбасе РТУ не просто так сделана в начале пакета, и тайминг там не просто так был придуман.
Случаи- они разные бывают.

2juvf:
Я стараюсь на комп не заводить MODBUS-RTU - он используется в основном для связи модулей расширения с ПЛК.
Если и завожу по необходимости, то никак не формирую активное состояние в паузе - и говорю клиенту, что так, мол, и так, работать как-то будет...
Если хотите чтобы было совсем хорошо надо раскошелится. Многие не хотят...

А сейчас парсер реализован так (сначала проверка адреса, а уже потом CRC):

Поделитесь опытом.
И какова? На практике это работает. Об этом пишут в даташитах. Погуглил инет на эту тему - кругом рекомендации про растяжки.
какую паузу? растяжки не обеспечат вам гарантированной паузы. растяжки обеспечат вам тишину в линии без дайвера (ну или шум сведут к минимуму).

А мы делаем. И работает, не хоть как-то, а работает.

нет там пауз в НАЧАЛЕ пакета. там пакеты разделены 3.5 символьными паузами тишины. Чтоб тишину обеспечить, достаточно всем помолчать. А если в линии шум... так нужно бороться с шумом. У нас в линиях нет шума. Зачем туда что-то дуть активно?


ps Я могу усомниться в своих знаниях (а я и усомнился... и погуглил... да нет... ставят растяжки), я могу не знать как в ДОС врубить активную паузу, я могу встать осцыолом на линию и посмотреть там шумы... и если их сейчас нет, не значит что их вообще нет.... Я могу во что-то поверить, например в ЛММ. Но верить в то, что растяжки не обеспечат тишину - не получается. У меня на каждом устройстве, и на слейве и на мастере стоит счетчик битых пакетов. если пройдет шум.... и хоть какой-то уарт примет хотя бы 1 байт ложный в тишины - счетчик битых пакетов увеличиться. если ложный байт будет перед нормальным пакетом или сразу после него - счетчик битых пакетов увеличиться. По этим счетчикам можно судить о шумах на линии... и вообще о работе всего модбаса на линии. годами в режиме 7/24 работают устройства... и эти счетчики единично инкриминируются. Т.е. эти "сопливые" растяжки не такие уж и сопливые. Тишину в линии они обеспечивают. А что ещё от них нужно? Зато нет гемора с активными паузами.

Решите задачу о котрой писал, вот и будет Вам первый шаг к пониманию и опыту. Если будете как заведенный попугай долдонить про каке-то "даташиты из гугла с растяжками", то так и останетесь попугаем повторяющим то, что не понимаете.
Выбор за Вами.

Если не сопливые, то тогда это вызывает проблему с дальностью работы в полный рост.

Забыли добавить "у меня". Типичное радиолюбительство описывается одной фразой - "ничего не знаю у меня все работает"

juvf , Вы хотели что-то спросить, или просто еще раз подтвердить самому себе верность своего курса?
Вы очень уверены в том что делаете, в чем тогда вообще смысл дискуссии, что Вы ждете от оппонентов?

Ваш путь ошибочен. Лично Вам он годится, только и всего.

Как говорил один классик "Езжайте! Да, когда свернете налево, ну вы-то направо, там проезд запрещен, обрыв. Но вам туда можно."

поддержу
особенно про стаффинг

есть же протокол BSC(хрен знает какого года выпуска) прозрачный и все проблемы без всяких растяжек и всяких хрен знает каких пауз которые еще и на pc хрен получишь

чего все к этому модбасу привязались с его паузами один гимор от этих пауз

немного в поддержу juvf
Если вы работаете по протоколу modbus по RS485, будьте добры придерживаться стандартов (использовать подтяжку A и В), в противном случае оборудование сторонних разработчиков ваши изыски по RS485 не поймёт.
Если вы разработчик всей системы (и мастера и слейва), то зачем вы вообще используете modbus. Вы нашли способ, используя драйверы RS485 с True Fail-Safe, повысить надёжность передачи данных на большие расстояния - это замечательно, но не надо навязывать своё решение всем, тем более грубить. Напишите статью на эту тему и поделитесь своими наработками.

Например здесь
http://www.analog.com/media/en/technical-d...otes/AN-960.pdf
на стр. 7 есть описание RS485 с True Fail-Safe, где сказано, что используя новые драйверы отпадает необходимость использовать подтяжку А и В, значит ранее такая необходимость была?
На стр. 6 приводится расчёт резисторов подтяжки.

Добавлю сюда пару ссылок на предыдущие обсуждения проблем помехозащищённости RS-485:

• Помехозащищенный RS-485
• как стартует UART?

Краткие выводы:

• Растяжки спасают далеко не всегда;
• Для гарантированного приёма начала пакета нужно либо подержать линию в активном состоянии перед началом пакета, либо передать "прочищающий символ" (это для протоколов с фиксированным символом начала пакета);
• В качестве "прочищающего символа" хорошо подходит 0xFF.

это мы сейчас по кругу пойдем - хотя круги уже нарезаны

в чем я с Вами согласен - что манеру zltigo желательно изменить
надо разъяснять проблемы и показывать их решение - а не гордо фыркать - типа это очевидно

за всяким "очевидно" очень часто скрывается глобальный вопрос и разъяснив его вы обучите всех и сделаете полезное дело

будьте мягче и добрее и всем будет веселее и лучше

"Стандарт" на MODBUS в котором про подтяжку на бочку



Понимание начинается с арифметики. Арифметическую задачку простейшую я сформулировал. После решнения ее будет понята и проблема вносимая растяжками. О том, что даже получив проблему с чувствительностью и дальностью из-за растяжек мы не получим такой помехозащищенности, как при поддержке активного состояния, можно будет уже потом разьяснять. Пошевелить извилинами Автор не озадачился. Ну и господь с ним.
Я со своим участием в этой теме закончил.

нет чтобы написать - папа вышли денег
написал ПАПА вЫшли денег


попробуйте сосчитать до 10 - я понимаю что бесит- тогда попробутй до 1000

я уже ответил. растяжки не обеспечивают гарантированную паузу. чо тут решать? очень интересно, чем вам растяжки в MODBUS не нравяться? вам нужна цифра? Для ваших условий согласно APPLICATION NOTE от AD 775 Ом.

Меня может бесить, когда я обязан кому-либо что либо втолковывать. Здесь я никому ничего не обязан. Толчек дал. Теперь пусть думает, какие НЕХИЛЫЕ отрицательные последствия от такой низкоомной растяжки, которая в тому-же, как у него зародилсь наконец-то умная мысль "растяжки не обеспечивают гарантированную паузу", то есть паузы по любому придется обеспечивать. Осталось сделать последний шаг, что, если паузы придется по любому обеспечивать управляющему контроллеру, то можно в это время и передатчик активным подержать, что будет будет много эффективнее для подавления помех и обеспечения читстой паузы, нежели растяжеки, и послать растяжки лесом.
Punkts un āmen.

ктож спорит то?
все дело в том - что зачастую даже когда приводят 2+2=4 нужно не только увидеть - но и прочувствовать
а это не всем дано бывает, и бывает очень долго приходится с этим свыкаться
особенно когда типа ты был молодцом ;-)
а тут вдруг раз и валенком по голове

терпимее надо быть - это я и себе говорю тоже ;-)

пф..... троль!!! ))))) Я вам дал ответ на вашу "задачку" за обещание показать бога надеясь услышать хоть один вразумительный довод. и? ....
Нет я так не думаю. Для тех, кто в танке

to zltigo
Надеюсь вы погорячились требуя стандарт на MODBUS с подтяжками (знаю, что вы понимаете, что такое протокол и интерфейс).

Речь шла о том, что большинство поставщиков оборудования с RS485 используют подтяжки. И если вы доработаете схему блока до вашего варианта, не факт, что он вообще работать будет и кому вы тогда будете предъявлять претензии - MOXA, Advantech? А заказчик требует что-бы работало. И ваши доводы, по поводу кривых рук разработчиков из MOXA, ему будут не интересны. Скорее всего он сделает "не правильные" выводы.

P.S. Кстати, разработчики из MOXA ещё те ребята, любят совмещать выходные линии RS485 и RS232. При такой схеме включения частенько вылетает драйвер RS232 и соответственно RS485 перестаёт работать. Приходиться резать дорожки или выбрасывать драйвер RS232.

Вооще-то это Вы понесли ахинею. Цитирую:

Так что это я могу поздравляю Вас с "погорячился". Зато теперь Вы узнали, что никаких "стандартов" на подтяжки нет, не было и не будет ни в интерфейсах, ни в протоколах, нигде.

Из этого совершенно не следует, что надо пополнять ряды рукожопых.

У MOXА растяжки опциональные. Им приходится с рукожопыми работать. Впрочем, как и мне. Так что и у меня, как уже писал, в оборудовании предназначенном для подключения чужих, потенциально рукожопных устройств, опциональные растяжки есть. Для своего оборудования нет, не было и не будет по причине нахренненужности и более того - вредности, ибо мне часто нужны дальности сегментов на уровне километров.
Есть еще один случай, когда таже MOXA вынуждена ставить растяжки, это вырожденный случай, например, конвертора произвольных байтовых потоков в Ethernet. В таком случае, когда правила фреймирования протокола и отсева мусора неизвестны любая помеха это смерть и ее приходится давить любой ценой.



Следующий шаг здесь:
http://electronix.ru/forum/index.php?showt...t&p=1451820
Впрочем, про катострофическую потерю дальности я писал не раз. Посчитайте, что остается от чувствительности затерминированного приемника на дальнем конце линии при такой растяжке. Если сможете, то дальше нарисуйте с любимыми растяжками многоточку штук на 16, например, на километр AVG24 и подумайте как же оно сможет работать-то.


Еще раз, последний - мне эта тема про рукожопство надоела. Больше ответов не будет.

to zltigo для информации

во вложении со страницы 22 и дальше...
отвечать вам не буду - бесполезно. Что хотел сказать, сказал выше. Каждый остаётся при своём мнении. Обсуждения не получается.

И вопрос к модераторам: хамство здесь разрешено?

Там как раз сказано, что растяжки не обязательны. Вернее, что их надо ставить в том и только том случае, если устройства в сети декларируют их необходимость:

К тому же это уменьшает допустимое число устройств в сети на 4:


zltigo конечно выражает своё мнение весьма экспрессивно, но его можно понять. Это тут уже обсасывалось не один раз. И все выкладки уже приводились. Я там несколькими постами выше привёл ссылки на предыдущие обсуждения, почитайте, если вам действительно интересно.

срезюмирую....
после этого вообще можно было с этим человеком о Modbus-е ни о чем не говорить. Ну и далее гвоздь в дискуссию
no comments

Во всех рекомендациях, которые я встречал говориться о защитном смещении. Нигде я не встречал про активную продувку. Нет, конечно я про такое слышал.... но не в рамках 485-го и модбаса, а вообще, в теории помехозащищенности линии. Но чтоб в модбасе что-то активно дули!? Может я не правильно готовлю модбас? решил это выяснить. А тут в ответ только вера в что-то святое и хамство. Конкретно, многоуважаемый zltigo заявляет, что под голый ПК, ака DOS - без проблем делает активную паузу. Например это хотел спросить. В ответ получил какую-то задачку…. И ответ “реши и поймёшь как”. Решил. И что? С неба спустилась миссия и открыла мне путь истинный как на десктопном ПК под DOS делать активную паузу?

И решил…. Каково цена? Только тролить и языком молоть умеет.


Очень умиляют высказывания единомышленников
vs )))


Далее…
Возможно…. Только вот те системы с которыми мы стыкуемся… работают… но это всё равно МОЙ путь…. я понял, тут только болтуны толком ни чего не подскажут…. Только нахамят и потролят, как обычно. Ищем литературу, справочники, статьи на эту тему… кто как делает? кто каким путём ходит? Может кто короткую тропинку мне покажет?
Что находим .... пруф раз, пруф два, три, четыре…, а также five, six, семь, восемь .... Много их… и ненавистные вики, и в даташитах на драйвера и от производителей. вот конкретно
пруф Значит мой путь не ошибочный и он подходит не только мне!
Вот ещё интересный девайс… ICP DAS очевидно тоже ставит и/или предлагает ставить растяжки, по необходимости.
Но наш мистер джедай умеет направлять Силу, что даёт ему некоторые сверхъестественные способности zltigo предлагает всех, кто делает помехозащищенное смещение, кастрировать. Он от всех отличается. Может ему когда-то оторвали гениталии и он не хочет от других отличаться?


Теперь по делу…. Что могу ещё добавить…. Поделившись опытом… а не ради того, чтоб кого-то унизить или холиварить….
2demiurg_spb, я видел подобные парссеры. ..... выскажу мнение: мне не нравиться подобные парссеры. Почему.
1)Есть пакет. целостность пакета обеспечивается контрольной суммой и паузами тишины. я сначала выделяю весь пакет из потока, проверяю его целостность и только потом начинаю обрабатывать данные этого пакета. Ну я как-то изначально…. В любом протоколе сначала проверяю целостность пакета, а потом обрабатываю внутренность пакета. Вы адрес и функцию обрабатываете не проверив целостность пакета. может в поле адрес ошибка, или в поле функция.... конечно в конечном счете црц покажет, что пакет был битый....
но.... вот у вас отправили пакет 2-му устройству, один бит ложный. Слейвы получили адрес 6
и тогда 2-ой девайс НЕ отметит битый пакет, а 6-ой девайс отметит, что пакет был ему адресован, но црц плохой и 6-ой сделает mb->stat.comm_errors++;. хотя на самом деле пакет был адресован 2-му. Если црц не совпал, то ни кто не знает, кому на самом деле пакет был адресован.
2) Вы не сможете оценить зашумлённость линии. Ну если конечно это вам надо. Я всегда это делаю. Даже один ложный байт в тишине увеличит счетчик ошибок во всех слевах.
Возможно это нашему маниакальному хирургу кому-то подходит, но это не вписывается в стандарт MODBUS. Ибо в стандарте есть функция 8 -Diagnostics (Serial Line only) . подфункция 12
The response data field returns the quantity of CRC errors encountered by the remote device since its last restart, clear counters operation, or power–up. Т.е. не нужно игнорировать чужой пакет с битым црц.

Что касается растяжек…. Все эти расчеты …. Сложные… они должны учитывать кол-во слейвов, длину кабеля, активное сопротивление/емкость/индуктивность…. Драйвера слейвов (у одних сопротивление 12 кОм, у других 24 кОм…) одни растяжки ставят в начале линии, другие на каждом слейве (например, если растяжки есть внутри драйвера)… терминатор может быть, может не быть, их может быть два….
Согласно апликэшен ноут от аналог девайс на 100 омную линию с 2 терминаторами нужно 775 Ом. Это конечно круто. По другим рекомендованным расчетам получалось около 560 Ом…. На практике мы ставим от 2.4 кОм…. Меньше не ставили. И реально эти растяжки на линии подбирали опытным путём. Также предлагают подберать опытным путём растяжки и терминаторы ICP DAS, причем растяжки только 1 кОм, 10кОм и даже 100кОм

2demiurg_spb я уже говорил, что имею опыт на линиях до 500 м. У вас линии длиннее? Интересно посмотреть на байт 0x55 в линии с растяжками и без. Какие фронты? Как это повлияет на скорость? zltigo не уподобился ответить на вопрос о длине линии…. Но потом проговорился, что ему интересны километры. Однако RS-485 вроде как до 1200 метров. Выше – это уже какой-то овердрайв и использовать там общепринятые решения наверно не целесообразно.

есть такое... но в модбас такое не прокатит... если только в 4 раза скорость понизить, вдунуть 0хфф, потом поднять скорость и слать пакет.

извиняюсь перед ТС за офтоп.

очень много букв
но вы даже не удосужились прочитать о чем пишет Антоха !!
он же написал о стаффинг протоколах !!! а вы это приписываете, что для модбас не прокатит
естественно потому что это для другого случая он написал !!!
что вобщемто и подтвеждает мысль, что с модбас не все нормально


более того например BSC известен ( применен метод байт стаффинга) с 68 года прошлого века и каким образом вылез модбас со своей временной паузой для синхронизации которые с трудом можно реализовать - не дай бог еще и скорость поднять то вообще труба будет, монотонность потока

и дурацкими растяжками гробящие сигнал и ничего не дающие не очень понятно

to АНТОХА


дак никто же этого не отрицает

Уверен, что почти каждый будет проверять работу RS485 без растяжек с True Fail-Safe. Правда, если это потребует переделку софта, то не везде это применишь (совместимости не будет).

P.S. Просто, если человек спрашивает, то нужно объяснять (пусть даже 2+2=4), для этого и существует форум. В своё время был очень хороший форум на telesys.ru, правда потом он стал полем разборок "профессионалов". Начинающих просто "забивали". Не хотелось бы здесь увидеть подобную манеру общения.

Ваше объяснение логично, понятно и более того соответствует описанию счётчиков в документе modbus_over_serial_line.
Но лично мне совершенно не хочется напрягать контроллер расчётами CRC всего сетевого трафика...

Что касается длинны линии, то сталкивался с разными задачами вплоть до километра.
Сейчас под рукой таких линий нет - картинку снять не могу.

А линию продуваю действительно так, как вы предположили. Поясню на примере STM32.
Отключаю функцию UART на ноге ТХ (перевожу в GPIO) и отправляю один байт на заранее рассчитанной скорости чтобы получилась пауза 3,5T (при этом нога TX вообще не дёргается).
Потом в прерывании TXC перевожу ногу обратно в режим UART-TX, меняю на правильный бодрейт и отправляю пакет, потом снова продуваю прежним способом.
Т.е. у меня в драйвере UART есть возможность включить пакетный режим с суффиксом и префиксом активного состояния.
Прерывания от таймера вообще не использую.

возникает вопрос смысл продувки?
если помехи не было - то и продувать то особенно нечего - бит синхронизация и так есть
если же была помеха то продувай не продувай будет принят битый пакет
в чем смысл?

Кста, хороший метод. Вещь в себе. Спасибо за мысль. Раньше делал по таймеру

1) Абсолютно бесполезный, ибо на приеме таймауты 1,5 и 3,5 по любому придется иметь, так зачем еще плодить лишние сущности.
2) На многих чипах нереализуемый, ибо прерывания окончания передачи просто нет, а есть только освобождение буферного регистра.
3) Ошибочный, поскольку в начале модбасовского фрейма 3,5 пауза избыточна и только снижает темп обмена.






В том, что Ваше утверждение "будет принят битый пакет" ошибочное. Это из мусора будет сформирован битый пакет, а передаваемый пакет пойдет очищенным от мусора.

1. Нет. Речь шла о продувке физ. канала. Совершенно закономерно, что мысль дошла до того, чтобы сделать продувку равную Т35 или Т15, но делать ее по максимуму, ессно, необязательно.
2. Нет! "на многих чипах" -это х51?
3. Да )) но не совсем. при Т15 остальной парк девайсов примет все что идет вплоть до Т35. Т.е. после продувки Т15 можно запросто потерять пакет. А после Т35 - нет.
Так что все правильно оказывается.

2) легко реализуемо путем пердачи лишнего байта - и как только лишний байт уйдет из регистра значит передача нужного байта выполнена

по вопросу битый пакет надо договориться о терминах и о каком протоколе мы говорим
после этого эту тему можно обсуждать - а то у нас тут уже все в одну кучу смешалось и модбас и байт стаффиг и растяжки и особенности прерываний и тд и тп и понять о чем идет речь весьма затруднительно

а тут важна совокупность того о чем мы говорим - типа синегирия в полном виде ;-)

и уж если придераться к словам - из мусора будет сформирован битый пакет - он что не будет никем принят? хотя тут опять возникает вопрос что значит ПРИНЯТЬ быитый пакет ;-)

да модбас RTU, что там оговаривать

вот нефига я его не понимаю - поэтому обсуждать его не могу ;-)

ну тут немного не так....
смысл такой, что когда линяя без драйвера, то она чувствительна к внешним шумам. Чтобы быть уверенным, что с выхода приемника не сыпет мусор (дословно "приемник в постоянном состоянии") когда нет активного сигнала, некоторым устройствам нужно защитное смещение.
В описании каждого устройства должно быть сказано:
-Нуждается ли в защитном смещении (например, если использовать драйвера True Fail-Safe, то защитное смещение устройству не нужно)
-Если устройстве реализует или может реализовать защитное смещение линии

т.е. протокол подразумевает тишину на приемниках, когда нет передачи.

Нет. Протокол не подразумевает. В стандартах никогда ничего не подразумевается, там всегда всё формулируется чётко. Если написано,

То это означает именно то, что написано, то есть, что каждое устройство должно документировать, нужны ли ему растяжки, и реализует ли оно растяжки внутри себя.
А если написано, что

То это означает, что если (и только если) одно или несколько устройств нуждается в растяжках (декларирует это в документации), то надо сделать растяжки.
А фраза

всего лишь объясняет, почему некоторым устройствам требуется растяжка.

Никакой тишины линии не подразумевается.

Вы поймите, что способность вашего устройства работать без растяжек - это конкурентное преимущество. Потому что при прочих равных такое устройство будет способно работать на более зашумлённых и длинных линиях, и таких устройств можно больше подключить в сеть.

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

а если банально сменить протокол modbus RTU на протокол использующий byte stuff - то все обсуждаемые проблеммы данного топика
просто исчезнут сами собой - включая начальную тему про сниффер ;-)

как Вы себе это представляете для случая, когда прибору требуется модбас как стд интерфейс?

я представляю это себе так
1 сначало люди придумали проблему
2 а потом извращаются чтобы ее решить

ТС предложили поставить МК на котором перевести идиотский модбас в нормальный поток RS232 (для примера - а то сейчас опять налетите USB CAN и тд и тп)

либо со штампами времени
либо ... не буду дальше

причем народ поделился опытом, что не получается честно отработать даже минимальные скорости этого идиотского протокола на win
все !!! о чем еще говорить?

более того он использует переходник USB-RS232 это и есть фактически такое устройство которое ему и прделагали сделать самому
только с его функционалом

Не всё так просто. В АСУТП и КИП на базе интерфейса RS485 протокол Modbus-RTU является стандартом де-факто. И считается, что помимо любых других он должен быть обязательно.
Реже используется Modbus-ASCII и DCON. Остальные протоколы вообще крайне редки. В Росии тот-же ОВЕН долгое время продвигал свой собственный, весьма не плохой протокол, ну а в последнее время сдался и тоже реализовал во всех своих изделия Modbus-RTU.

конечно не просто - мы же всегда любим делать все через одно место
сделать(принять как вы написали дефакто) стандарт который очень неудобный и потом им пользоваться - хотя между BSC(1968 год) и MODBUS-RTU (2006) пропасть времени

сделать растяжки гробящие шину
проДУВАТь канал (хотя хоть какойто смысл есть)
использовать приемо передатчики без сдвига - хотя даже отечественные драйвера все уже правильные - где вы только неправильные достаете ;-)
сначала угробить промышленность - а потом запеть про импорто замещению
когда уже все угроблено- начать делать страховые запасы
зашибись дефакто

правда потом начинаем покупать все иностранное и при этом качать права чтобы все соответсвовало нашим стандартам

типа а какого хрена у вас мерседес с винтиками не по госту?

или почему печатная плата в дюймах? помните проблему псведо дюймов? - которые 2.5 вместо 2.54?
вот этот дефакто из этой же серии

и еще раз ТС дали четкий ответ - хочешь снифер = делай(тем более они делают свои железки как я понял) МК приблуду. под WIN по честному не получится
что еще обсуждать?

вот мне лично ASCII нравится и я предпочтения ему отдаю, если нужно построить сеть из несложных девайсов.


А там еще было какое-то решение на базе Modbus-ASCII с заменой множества символов, так что они были прозрачны для остальных девайсов с "фирменным модбасом" с точностью до фрейма. причем, непонятно для чего сие вообще, если мастер один



при чем тут... чуждый православию модбас появился эволюционным путем. Всё.

Мягко говоря ничего не понял. Таймера будут по любому и городить "продувку" левой рукой правое ухо просто незачем. Не обойтить без таймера, вот он пусть и отрабатывает все нужные интервалы в зависимости от состояния автомата фреймера.

Абсолютно на всех, котрые ведут совместимость от 8250 чипа. Среди микроконтроллеров это, например все NXP включая ARМ. Ну и само собой все IBM-PC.

Понятие правильности оно абсолютное и не надо называть "правильными" нарушения пртокола под устройства сделанные кем то с нарушением.
Иметь настройки под уродов, это да, жизненная необходимость, но это не делает нарушения легальными.




Не реализуемо. Прерывание отработает с задержкой, да и само прерывение будет выдано с задержкой на один бит в большинстве случаев. Так что получите, как минимум, лишний стартовый бит до того, как отключите передатчик.

реализуемо
и кого волнует мусор на шине?





путем деградации

Стартового бита не будет, потому что ножка передатчика отключена. Так что нормуль.

Если НЕ понимаете о чем речь, не плодите "мусор на шинефоруме". Передатчик НЕ отключен, поскольку передатеся валидный "предпоследний" байт.




Меня волнует мусор, которого могло-бы и не быть. Не люблю грязную работу и сам НЕ делаю свою работу грязно.

ну тогда считаем что этого мусора нет - посколькку после него будет пауза и этот сигнал никому не помешают,
и он строго детерменирован и не представляет никакой опасности и совершенно чист перед протоколом

и в от личии от вашего невозможно - это все решает без проблем

Нет, это вы влезли посреди обсуждения, и, как выясняется, совершенно НЕ понимаете, о чём речь. Но осуждать это вам не мешает.
На всякий случай, речь шла об вот этом методе:

Вот именно по этому методу окончание передачи и НЕ работает, если, как уже писал, нет прерывания по окончанию передачи. И прерывание по загрузки регистра хранения в регистр сдвига, как у 8250 совместимых чипов никак не канает.



Понял. Насрать соседу под дверь, насрать не считается, ибо дверь чужая и проблемы соседа - пусть чистит.