[ericN 3]

В 24.05.2023 в 16:46, quark сказал:

Вы тоже тему не читаете?
Отлистайте пару страниц назад, и почитайте как, в случае ПК, обеспечивается неразрывность фреймов и необходимые по стандарту межфреймовые паузы.

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

 

ps тему читаю. где там в отлистаном обеспечение тайменгов виндовым ПК со штатным драйвером UART? 

[quark 48]

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

Реалтайм для модбас? Для меня что-то новое, т.к. мне совершенно не понятно, каким боком системная архитектура связана с протоколом обмена...

Вот почему народ упорно не хочет читать, что пишут? Приходится повторять сто раз...
Для использования MODBUS в ПК не нужна реал-тайм система (контроллер и ОС).
Годится обычный оффисный ПК c обычной виндой и обычный USB-RS485.
Со всеми стандартными устройствами MODBUS все будет работать.

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

где там в отлистаном обеспечение тайменгов виндовым ПК со штатным драйвером UART? 

А где было сказано, что это необходимо? Без этого все делается. Видимо, ничего не поняли. Читайте все по новой.

[razrab83 19]

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

Вот почему народ упорно не хочет читать, что пишут? Приходится повторять сто раз...

Вот почему народ упорно не хочет читать, что пишут? Приходится повторять сто раз... чтобы выделить из потока фрейм вам нужно реалтаймовые 3,5 символа тишины. Нет в модбас иного разделения потока данных на фреймы. Вам ни какой офисный ПК и не офисный, тем более усб-свистки, не обеспечат эти 3.5 тишины. 

[Arlleex 141]

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

Со всеми стандартными устройствами MODBUS все будет работать.

Тогда уж пишите ..."при определенных обстоятельствах".

[quark 48]

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

Вот почему народ упорно не хочет читать, что пишут? Приходится повторять сто раз... чтобы выделить из потока фрейм вам нужно реалтаймовые 3,5 символа тишины. Нет в модбас иного разделения потока данных на фреймы. Вам ни какой офисный ПК и не офисный, тем более усб-свистки, не обеспечат эти 3.5 тишины. 

Опять про поток! Из какого потока вы собрались выделять фрейм? Из потока мусора?

ПК - ведущее устройство. Пока не отправите запрос - никакого ответного потока не будет.

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

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

Со всеми стандартными устройствами MODBUS все будет работать.

Тогда уж пишите ..."при определенных обстоятельствах".

Пишу: При любых обстоятельствах, соответствующих стандарту.

За исключением использования "мусорной линии", конечно.

[Ruslan1 17]

Ну и намотали тут всего на вентилятор про мой любимый Модбас.

Если приемник/передатчик не обеспечивает спецификацию- то он не годится.

RTU в PC работает с кучей оговорок. Хотите чтобы PC работал с RTU безусловно- делайте аппаратный конвертер между Модбас протоколами: RTU-ASCII, или RTU-TCP, или RTU-что-то не-модбасное, независимое от таймаутов.

Если изначально знаете что будет канал связи и/или PC - то не выбирайте тайминго-зависимый RTU, а сразу закладывайте ASCII, ну или TCP. Или вообще какой-нить SLIP если Модбас не нравиться.

 

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

[quark 48]

7 минут назад, Ruslan1 сказал:

RTU в PC работает с кучей оговорок.

Работает точно по стандарту без всяких оговорок. С любыми стандартными устройствами.

Не согласны - читайте тему с начала.

[jcxz 199]

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

Лучше нерабочие методы - в урну! Да здравствует MODBUS!

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

У вас при приеме в ПК все паузы потеряются. Хуже того - могут появиться лишние. Там не годится этот метод.

Вы так и не привели рабочих методов. Где "методы", Зин?

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

Только "нечестным" он будет только внутри ПК. А снаружи - все будет честно. И строго по стандарту.

Здесь - "честный", здесь - "нечестный"; здесь - работаем, здесь - нет. Вот и цена вашим "методам".  

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

Работает точно по стандарту без всяких оговорок. С любыми стандартными устройствами.

"У меня всё работает"... и пофиг что у пользователя. как это знакомо.... Стараюсь держаться по-дальше от таких "разработчегов". И другим советую.

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

ПК - ведущее устройство. Пока не отправите запрос - никакого ответного потока не будет.

Кадр отправленный из ПК через USB свисток, может стать несколькими кадрами. В стандарте Modbus-RTU.

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

Опять про поток! Из какого потока вы собрались выделять фрейм? Из потока мусора?

Из какого угодно. 

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

[quark 48]

14 минут назад, jcxz сказал:

Вы так и не привели рабочих методов. Где "методы", Зин?

14 минут назад, jcxz сказал:

Кадр отправленный из ПК через USB свисток, может стать несколькими кадрами. В стандарте Modbus-RTU.

15 минут назад, jcxz сказал:

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

Я уже понял, что тему вы не читаете. Поэтому говорить с вами бесполезно.

14 минут назад, jcxz сказал:

"У меня всё работает"... и пофиг что у заказчика. как это знакомо....

У меня нет неработающих проектов. Все, что сделал - работает без претензий заказчиков. Некоторые проекты - уже более 20 лет.

14 минут назад, jcxz сказал:

Стараюсь держаться по-дальше от таких "разработчегов". И другим советую.

Я тоже стараюсь держаться от вас подальше. И другим советую.

[Ruslan1 17]

Just now, quark said:

Работате точно по стандарту без всяких оговорок. С любыми стандартными устройствами.

Не согласны - читайте тему с начала.

Не, я в этот холивар масла подливать не стану :) Если Ваш компьютер может мастером RTU без дополнительных условий- то снимаю шляпу.

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

Со слейвом на PC еще больше ограничений, годится только как игрушка.

[jcxz 199]

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

У меня нет неработающих проектов. Все, что сделал - работает без претензий заказчиков.

Не верю! С таким-то отношением к стандартам это просто невозможно.... Пи$%^ть - не мешки ворочать!  

[quark 48]

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

Не верю!

Вам и не надо верить. Вообще, вам не надо верить.

[Ruslan1 17]

22 minutes ago, quark said:

Работает точно по стандарту без всяких оговорок. С любыми стандартными устройствами.

Если не секрет...

А на чем писали (операционка/среда программирования)? И на какой уровень вниз уходили, чтобы таймауты обеспечивать настолько маленькие, как это предлагает стандарт?

Я имею в виду- как удавалось быстро определить в PC, что пакет уже принят и быстро послать новый, чтоб загрузить линию по максимуму? Поллингом регистров?

Я в Билдере это делал, пришлось от прерываний к поллингу перейти. 4 порта RS-232 с потоком на 57600 (или даже 38400) со скрипом справлялись на Целероне, в винде даже помнится какие-то твики применял.

[quark 48]

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

А на чем писали (операционка/среда программирования)? И на какой уровень вниз уходили, чтобы таймауты обеспечивать настолько маленькие, как это предлагает стандарт?

Маленькие таймауты не нужны. Если вы, все-же, соизволите почитать мои сообщения и попытаться разобраться, то поймете почему. Наоборот, иногда  их приходилось увеличивать, поскольку некоторые системы работали напрямую через интернет, который вносил свою задержку . На "дальнем конце" стояла MOXА, к которой были подключены внешние устройства. Подключенный к интернету ПК выполнял роль мастера. Использовался стандартный MODBUS-RTU. Ни чего там специально не дорабатывали и не "подкручивали". Эта одна из систем. Были и попроще, без интернета. Через USB-RS485, например. Таких было много.

34 минуты назад, Ruslan1 сказал:

Я имею в виду- как удавалось быстро определить в PC, что пакет уже принят и быстро послать новый, чтоб загрузить линию по максимуму? Поллингом регистров?

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

[Ruslan1 17]

11 minutes ago, quark said:

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

Спасибо, ясно. Такого RTU мастера я тоже делал. И через LAN/интернет c виртуальным портом с двух сторон, и через RS-232 порт на удаленном GSM модеме. Если со стороны мастера возможны задержки больше минимально допустимых стандартом, тогда не интересно, задача решается почти тривиально.