[quark 48]

10 часов назад, mantech сказал:

Только учтите, потеря 3 пакетов ДРУГ ЗА ДРУГОМ, а это уже совсем другая вероятность, чувствуете)))

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

[razrab83 19]

2 минуты назад, quark сказал:

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

И? -6 степень..... что там выходит.... раз в год? или раз в 10 лет? у вас раз в 10 лет выйдет из под контроля ядерный реактор остановиться полив теплицы. что хорошего? И ещё, раз в 10 лет - это не значит что после ввода в эксплуатацию через 10 лет, это значит на интервале 10 лет случиться 1 раз. И этот раз может наступить на следующий день после ввода в эксплуатацию.  

[siargy 6]

On 5/24/2023 at 2:22 PM, Arlleex said:

на ПК сделать честный RTU нельзя

можно. в этой теме ужэ раз 5 написали как.

[quark 48]

2 минуты назад, razrab83 сказал:

И? -6 степень..... что там выходит.... раз в год? или раз в 10 лет?

Это при предполагаемой вероятности разрыва 1/100, не забывайте. В реальности, разрыв будет происходить раз в сутки. Пусть даже раз в час, при непрерывной работе. В этом случае, вероятность будет порядка 1/10000. А три раза подряд - минус двенадцатая степень. Пять раз - минус двадцатая. Этого Вам достаточно?

 

[siargy 6]

18 hours ago, jcxz said:

Ваш Modbus-RTU работает через USB-CDC-свисток.

взяли заведомо неправильный вариант и 10 страниц пытаетесь натянуть сову на глобус. не надо так!

[=AK= 10]

On 5/22/2023 at 4:17 AM, jcxz said:

Втыкаю USB-свисток на FT232. Наблюдаю в его дескрипторе 2 ep (IN и OUT): по 64 байта каждая. Соответственно - макс.размер кадра в котором передаются данные USB-CDC = 64 байта. Если по UART пришёл непрерывный кадр размером 70 байт, то очевидно USB-хосту он будет отправлен как минимум в двух USB-bulk-кадрах

Очевидно вы с USB знакомы понаслышке. То, что вы называете "размер кадра" (data payload), практически ни на что не влияет. Об этом в спецификации USB сказано так: The division of the data stream into smaller chunks is not visible to the client

USB СDC реализован поверх USB bulk. При размере "кадра" 64 байта, в одном фрейме FS (т.е. за 1 мс) передается до 19 "кадров" балк, т.е до 1216 байт. В FT232 передающий буфер имеет размер  256 байт, куда пакет размером 70 байт прекрасно поместится и будет отправлен в одном фрейме в виде двух "кадров": первый "кадр" 64 байта, следующий за ним "кадр" 6 байт.

С приходом переданного фрейма в приемном буфере USB хоста весь пакет в 70 байт появится сразу, одномоментно.

При желании хост может определить, что пакет пришел целиком, а не является частью какого-то очень длинного пакета, не уместившегося в один фрейм. Но для этого придется отказаться от услуг CDC и опуститься непосредственно на уровень балк. Конец пакета обозначен "кадром" длиной менее 64 байт. Если длина передаваемого пакета кратна 64 байтам, то окончание пакета обозначается "кадром" нулевой длины.

Случаи перегруженного USB можно не рассматривать в силу их экзотичности.

[razrab83 19]

1 минуту назад, quark сказал:

Это при предполагаемой вероятности разрыва 1/100, не забывайте. В реальности, разрыв будет происходить раз в сутки

кто так решил? В реальности, у нас, было так, что 100 пакетов идет не за сутки, а за несколько секунд 100 мс. Т.е. вероятность 1/100 - это 10 разрывов в секунду. что там с вашей минус 12 степенью?... Так вот в реалии, сначала потерю связи убрали повторами. Стали случаться выходы из строя, переход на резервный комплект по причине "устройство перестало отвечать". Пришлось убрать контроль 1.5 у слейвов, стало работать безотказно. Но это что касательно нашей разработки и реального случая из жизни. 

 

Конечно... если ТС сделает обмен раз в 1 сек на 9600 и не будет на мастере-ПК контролировать тайминги - да всё будет прекрасно работать. Кто спорит.  Но о чем тут спор: вопрос - какой протокол? Ответ предложение - modbus. Кто-то на ПК с модбасом хаплул горя. Посторался на ПК сделать его как требует стандарт и замучался. Теперь делиться своим опытом. Но кто-то топит за модбас, он ему нравиться. Довод в пользу модбас - это стандарт, это ОРС, это можно расширять систему, это можно подключать сторонних слейвов. Так вот если расширяться чужаками, надо делать честный модбас, а это геморой. А если не расширяться чужаками - то и довод этот в топку... 

 

ps ах да.... совсем забыл... ещё случай из жизни... реальная разработка была... есть система: мастер - несколько слейвов. сделали 115200, старт, 8 бит, без чет, стоп. Модбас. свой мастер, часть слейвов свои, часть чужие. Решили расширить систему. купили "чужака" слейва. У него был модбас. легко интегрируется в нашу систему. достаем из коробки и .... у него только 9600 и 19200. да ещё и с четностью. Будет у вас 3-5 устройств с разными параметрами RS.... Будете мастера перенастраивать? или делать несколько шин 485? Так что довод "в будущем легко расширить" тоже в топку. 

 

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

Но если делаешь свою систему - н@х нужен этот ваш модбас. Сделал структуру struct State; заполнил поля, обрамил заголовком и CRC - выдал в IODevice. Получатель принял - проверил CRC (а если это USB/Eth, то и crc не нужен), инициализировал структуру - хочешь приведением типа, хочешь union-ом, хочешь с помощью memcpy - ВСЁ!!! Весь парсинг одной строчкой. И ты сразу получаешь всё состояние всего слейва одним пакетом. хоть 10 байт, хоть 100, хоть 500. 

[quark 48]

4 минуты назад, razrab83 сказал:

Т.е. вероятность 1/100 - это 10 разрывов в секунду. что там с вашей минус 12 степенью?

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

[razrab83 19]

Только что, quark сказал:

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

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

[Arlleex 141]

17 часов назад, quark сказал:

Понятно. Еще один фанат "мусорных линий" объявился, в компанию к Arlleex.

Фанат? Не нужно мне приписывать никакого фанатизма. Когда шина свободна и ни один передатчик ее не держит, мусор вполне может приниматься приемниками. И к этому все абоненты должны быть готовы - как минимум тупо не зависнуть. Это касается вообще любых проводов, торчащих из устройства на улицу. Если Вы такие очевидные моменты решаете лишь аппаратными заплатками, требуя обязательных растяжек на линии - дело Ваше. Не стоит потом винить всех, когда окажется, что в чужой сети этих растяжек не будет.

 

1 час назад, siargy сказал:

можно. в этой теме ужэ раз 5 написали как.

Раком-боком с костылями, методами "ну вроде подключил и работает" - конечно можно.

 

1 час назад, =AK= сказал:

USB СDC реализован поверх USB bulk. При размере "кадра" 64 байта, в одном фрейме FS (т.е. за 1 мс) передается до 19 "кадров" балк, т.е до 1216 байт.

А Вы хоть когда-нибудь открывали сниффер USB-порта, даже не нагруженного? С ПК под виндой или линухой? И что там, хоть раз удалось поймать 19 балков на один и тот же EP внутри кадра (1 мс)? А хотя бы 5?

[tonyk_av 36]

2 minutes ago, Arlleex said:

Раком-боком с костылями, методами "ну вроде подключил и работает" - конечно можно.

Я уже со счёта сбился давать ссылку на нормальные платы последовательных портов с нормальными драйверами. Сходу: PCI-1602.

[=AK= 10]

2 minutes ago, Arlleex said:

А Вы хоть когда-нибудь открывали сниффер USB-порта, даже не нагруженного? С ПК под виндой или линухой? И что там, хоть раз удалось поймать 19 балков на один и тот же EP внутри кадра (1 мс)? А хотя бы 5?

Да. В былые времена я много чего рассматривал в USB, по долгу службы, так сказать. В ходе разработки некого USB-"осциллографа". Правда, мы от FS и балк быстро отказались, но начинали с этого.

[Arlleex 141]

6 минут назад, tonyk_av сказал:

Я уже со счёта сбился давать ссылку на нормальные платы последовательных портов с нормальными драйверами. Сходу: PCI-1602.

Я уже со счета сбился, сколько раз мы все тут перескакиваем с модбаса на ПК (в целом), аппаратном уарте ПК, USB-свистках и т.д. Разговоры слепых с глухими

А лично мне уже давно все понятно)) Ничуть не удивлен, что у половины "все работает, потому что у меня все работает", а у другой был и свой противоположный опыт.
 

1 минуту назад, =AK= сказал:

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

Так по поводу балков на один и тот же EP внутри одного кадра что скажете? Видели? Только честно.

[=AK= 10]

20 minutes ago, Arlleex said:

Так по поводу балков на один и тот же EP внутри одного кадра что скажете? Видели? Только честно.

Уже в другом проекте, при отладке передачи массивов данных через балк я, несомненно, наблюдал передачу большого количества чанков ("кадров") в одном фрейме. Было их 19 или только 18 - не обращал внимания.

Онако, помнится, что в те времена (более 10 лет назад) у Микрософта в драйвере был баг, из-за которого длинные пакеты передавать было нельзя. Ограничение было 8К, пакеты бОльшего размера приходили битыми. Баг был совсем детский, при организации кольцевого буфера при приеме.

Однако была немецкая фирма, запамятовал как называется, предлагавшая свой драйвер, без бага, у них все работало как описано в спецификации USB.

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

[mantech 38]

2 часа назад, quark сказал:

А три раза подряд - минус двенадцатая степень. Пять раз - минус двадцатая. Этого Вам достаточно?

Эх, тяжело же жить на свете перфекционистам))))))