[mantech 42]

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

битрейт 921600.

А ничего, что заявленный битрейт почти в 10 раз больше, чем макс по стандарту модбаса?

[razrab83 21]

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

Одного честного реал-тайм контроллера недостаточно. Нужна еще честная реал-тайм операционная система на ПК.

не нужна. если у вас вся система "ПК+железо" есть не раелтайм, но есть модбас - то ОС с реалтаймом не нужен. 

 

Допустим вы сделаете свой преобразователь rs485/usb. или rs485/tcp на stm32f107. с одной стороны 485/modbus. мк обеспечивает 3.5 и 1.5 паузы. получил 20 байт - пауза в 3.5 - отправил по тср в ПК пакет добавив 6 байт заголовка. хоть на ОРС отправляй. Нужно ПК дать запрос - отправил по ТСП/USB в преобразователь запрос, МК сам его выдаст в rs485 со всеми тайменгами. Задаем требование системы "Ответ от слейва не более 1 сек". На любом битрейте ваш преобразователь будет работать, вне зависимости от ОС и реалтайма на ОС.

[mantech 42]

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

Я это всё к тому, что тащить Modbus в ПК - это геморрой.

Об этм никто не спорит, поэтому и сам делаю мастер модбас на контроллере, но ранее, пока не умел писать комплексный фреймворк на контроллере с собственными драйверами уровня ядра  - приходилось использовать ПК под виндой, и он тоже работал с модбасом норм, при условии регламентированных скоростей 9600-115200...

[quark 48]

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

Задаем требование системы "Ответ от слейва не более 1 сек".

Реал-тайм бывает разный. Задайте требование "не более 10 сек", тогда и винду можно рассматривать как реал-тайм систему. )))
В реальности, для прямого управления каким-либо устройством, обычно, требования лежат в диапазоне миллисекунд - десятков миллисекунд, в самом лучшем случае. Когда винда периодически "задумывается" (по своим делам) на несколько сотен миллисекунд, отбирая управление у вашей программы, то весь ваш реал-тайм накрывается медным тазом. И ни какой протокол здесь не поможет, и ни какое "правильное" железо.
Поэтому, подключение устройств к ПК, обычно, используется только для настройки устройств, передачи данных, накопленных в устройстве и т.п. Или для управления, не сильно критичного по времени. То есть там, где реал-тайм не требуется. Для таких применений MODBUS ничем не хуже других протоколов.

[siargy 6]

11 minutes ago, quark said:

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

Это просто вы не умеете готовить. Например TwinCAT на промышленном ПК Beckoff умеет в реалтайм на EtherCAT.

[quark 48]

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

Это просто вы не умеете готовить.

Возможно... Только сути дела это не меняет. Поскольку тема - по применение MODBUS.

[razrab83 21]

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

Реал-тайм бывает разный. Задайте требование "не более 10 сек", тогда и винду можно рассматривать как реал-тайм систему. )))

не бывает разного реалтайма. 3.5 и 1.5 символов определены в стандарте. их надо выдержать. чтоб их выдеражать, нужно точно знать сколько времени у вас буде реакция на воздействие. мк может обеспечить точное поведение, т.к. обеспечить реалтайм. МК может обеспечить 3,5 и 1,5. ОС, допустим винда не может. 

 

что касается ожидание ответа, то модбас его не рагламентирует. При создании системы пишутся требования: "битрейт 115200, старт, 8бит, ДВА стопа. адреса то такие. Ожидание ответа не более 1000 мс.". Винда должна обеспечить выдачу пакета без пауз, а ожидать ответ будет 1 сек. ожидать она 1 сек сможет, а выдать команды без пауз не всегда.

 

Опять же.... я же писал....

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

"ПК+железо" есть не раелтайм

т.е. пусть это будет поливалка теплицы. Винда отпрашивает датчик влажности грунта. Винда сама опрашивает по модбас через usb/rs485. Отправила запрос... ушел запрос с дыркой в 4 байта. Датчик грунта не ответил. Система нереалтаймовая не работает. а теперь, в этой нереалтаймовой системе выносим преобразование usb в rs-485 во внешний преобразователь на контроллере stm32. 

Нереалтаймовая Винда по usb отправила булк, МК принял. Мк формирует запрос датчику. Нереалтаймовая винда ждет ответа. Мк выдает через DMA в rs запрос. байты идут строго друг за другом. без пауз. Датчик грунта принял пакет и запустил измерение. Там сложный датчик, состоящий из кучи устройств и медленный.... в течении 800 мс делается изсерение и отправляется ответ. Ответ без пауз. Преобразователь на МК получает ответ, при этом контролируя 1.5 и 3.5. Получив пересылает его по USB в ПК. Через 805 мс после запроса ПК получил ответ. В зависимости от состояния грунта измерение проводиться от 500 до 900 мс. Поэтому требование в 1000 мс - обоснованное. 

Далее... надо включить полив.... всё тоже самое... нереалтаймовый ПК передает в преобразователь команду на включение поливалки. и преобразователь в модбус команду на насос - пошел полив. 

Допустим, нереалтаймовый ПК дал команду в USB на полив, и ушел на свопинг.... или на индексацию FS. Команда застряла на 1-2 с недрах ОС и в конце концов попала в преобразователь. И что? Вся система рухнет? Помидоры завянут? Нет! Преобразователь с задержкой в 1-2 сек получит команду на полив, выдаст "правильно" эту команду в модбас и насос начнет полив. 

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

 

[ericN 3]

В 24.05.2023 в 12:42, quark сказал:

То есть там, где реал-тайм не требуется. Для таких применений MODBUS ничем не хуже других протоколов.

когда реалтай все системы не требуется, требуется в реалтайме выдать и принять пакет свыдержкой всех тайменгов. для этого нужен реалтайм. Реалтайм требуется для обеспечения Modbus, а не для обеспечения всей системы.

[quark 48]

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

не бывает разного реалтайма. 3.5 и 1.5 символов определены в стандарте. их надо выдержать. чтоб их выдеражать, нужно точно знать сколько времени у вас буде реакция на воздействие. мк может обеспечить точное поведение, т.к. обеспечить реалтайм. МК может обеспечить 3,5 и 1,5. ОС, допустим винда не может. 

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

требуется в реалтайме выдать и принять пакет свыдержкой всех тайменгов. для этого нужен реалтайм. Реалтайм требуется для обеспечения Modbus, а не для обеспечения всей системы.

Вот для этого, реал-тайм, как раз, и не требуется. Достаточно "правильного" железа. Например, MOXA, которая не разрывает пакеты при приеме/передаче.
А в большинстве случаев - достаточно настройки размеров буферов ввода/вывода у "обычного железа". И ограничения длины передаваемого пакета, чтобы не было разрывов пакетов. Напомню, что межфреймовая пауза в MODBUS задается по принципу "не менее". Сделать паузу "не менее" - можно и не имея реал-тайм.
А для приема - можно все паузы игнорировать в программе на ПК. Это не повлияет на результат.

[ericN 3]

В 24.05.2023 в 12:19, mantech сказал:

А ничего, что заявленный битрейт почти в 10 раз больше, чем макс по стандарту модбаса?

Пруф?

В 24.05.2023 в 10:33, Arlleex сказал:

Справедливости ради стоит заметить, что на таких скоростях правило 3.5 и 1.5 не применяется, вместо этого берутся фиксированные таймауты 750 мкс и 1.75 мс.

Пруф?

Не ради троллинга или что-то доказать.... я таких ограничений не встречал. Сейчас глянул тут и тут. Нет его. Есть у когонить пруфы на эти ограничения? Только не на вики(рус) или маил.ру, а на оригинальные документы. 

[mantech 42]

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

Например, MOXA, которая не разрывает пакеты при приеме/передаче.

Вот мне одно дело не понятно, сразу скажу, ничего не утверждаю, просто мысли вслух. Допустим имеем FT232 мост, который имеет 256 байт буфер ФИФО на передачу, а нам нужна именно передача, мы формируем пакет модбаса на передачу, не более размера буфера, т.е. до 256 байт длиной. Какой смысл драйверу разрывать этот пакет? Ну если не принципиально там сделан корявый драйвер и он вместо того, чтобы выдать одной булкой эти 256 байт, будет их делить на 8 например и толкать в течении секунды??

[dimka76 52]

On 5/24/2023 at 11:32 AM, mantech said:

Вот мне одно дело не понятно, сразу скажу, ничего не утверждаю, просто мысли вслух. Допустим имеем FT232 мост, который имеет 256 байт буфер ФИФО на передачу, а нам нужна именно передача, мы формируем пакет модбаса на передачу, не более размера буфера, т.е. до 256 байт длиной. Какой смысл драйверу разрывать этот пакет? Ну если не принципиально там сделан корявый драйвер и он вместо того, чтобы выдать одной булкой эти 256 байт, будет их делить на 8 например и толкать в течении секунды??

Для USB-FS булки могут быть не больше 64 байт. Если не ошибаюсь.

Кстати вот дескрипторы для FT232

Quote

Endpoint Descriptor:
bEndpointAddress:     0x81  IN
Transfer Type:        Bulk
wMaxPacketSize:     0x0040 (64)
bInterval:            0x00

Endpoint Descriptor:
bEndpointAddress:     0x02  OUT
Transfer Type:        Bulk
wMaxPacketSize:     0x0040 (64)
bInterval:            0x00

 

[quark 48]

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

Какой смысл драйверу разрывать этот пакет?

Дело в том, что этот буфер может быть не один. Когда вы из программы на ПК отправляете пакет на передачу, то совсем не факт, что он напрямую попадает в буфер драйвера...

[tonyk_av 39]

1 hour ago, siargy said:

на более высоких скоростях в длинных пакетах будут пропуски

Я использовал её на 115200, о чём написал выше.

1 hour ago, razrab83 said:

при чем здесь OPC?

А при том, что раз делается устройство используемое в какой-то системе управления и/или мониторинга, то вопрос интеграции этого девайса с другими стоит не на последнем месте.

Для Модбас есть внятное описание и стандарт, много утилит для тестирования. Наличие ОРС-сервера для протокола показывает то, что у протокола есть хорошая поддержка и его интеграция в существующую систему будет не сложной в отличии от всяких приблуд с самописными протоколами, на которые, как привило, и документации внятной нет.

9 minutes ago, ericN said:

Пруф?

Не ради троллинга или что-то доказать.... я таких ограничений не встречал

Стандарт пробовали читать?

[Михась 2]

Нажористое обсуждение для 2023 года. Но в общем, промавтоматизация для всякого рода "курятников" действительн предпочтительна на модбасе, потому что если гикнется какой-то модуль ввода-вывода или частотник, то можно будет сравнительно безболезненно его заменить. А вот уникальные самопиные протоколы - огромный геммор для эксплуатации и системных интеграторов. Мы например подключаем такое за другие деньги уже.

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