Перейти к содержанию
    

Детали разработки модуля Modbus

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

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

а что ваша плата сделает? ну во первых - речь всё таки о бытовом ПК (да и ктому же с вашего ходу... "Товар не доступен к продаже").  во втоврых ПК+PCI-1602+Win - что получиться? Modbus строго по спецификации? выделение пакета по паузам с контролем 1.5? Что-то я очень сомневаюсь, что на винде на уровне апликэшэн это получиться. А если делать модбас раком-боком с костылями, методами "ну вроде подключил и работает"  с оговорками - конечно получиться. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Дак очень много зависит от качества программы, правильности установки ОС и перфекцинистических хотелок. Поэтому у моего соседа винда слетает раз в пол-года, у меня уже 5 лет стоит и все норм, вот так и живем)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

23 minutes ago, Arlleex said:

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

нет. чесный реалтайм контроллер одной стороной в модбас, с другой на выбор - усб, пси, изернет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Планированием транзакций занимается драйвер XHCI. Это весьма сложная программа, и некоторые микроконтроллеры (LPC) имеют вовсе аппаратный хост-контроллер. Ни о каком детерминизме в планировании здесь говорить ну никак нельзя, потому что планирование динамическое - на основе текущего состояния и новых данных, подсовываемых от различных сервисов и пользовательских приложений. Таки вопрос повторяется - можно ли на обычном стационаре под линухой или виндой гарантировать неразрывность IN/OUT-транзакций для одного CDC внутри кадра?
 

10 минут назад, siargy сказал:

нет. чесный реалтайм контроллер одной стороной в модбас, с другой на выбор - усб, пси, изернет.

И это называется "честный RTU на ПК"?
 

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

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

И это не верное утверждение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

18 минут назад, siargy сказал:

нет. чесный реалтайм контроллер одной стороной в модбас, с другой на выбор - усб, пси, изернет.

Т.е. делаешь свой преобразователь из tcp/485. ставишь на него реалтайм МК. Получаешь от ПК по tcp допустим tcp-модбас, или мэк, или http и транслируешь в RS реалтаймовым МК модбас со всеми паузами. получаешь ответ в соответствии с протоколом, ретранслируешь его в ПК по tcp.  Да, конечно, всё будет работать. Разработать свой модбас-преобразователь. Кто за это спорит. Все предложения были касательно - взять бытовой ПК с виндой + усбсвисток с алишки и всё сделать в соответствии со стандартом. Вот сомниния во втором варианте. 

спецы по кишкам USB, подскажите вот за что.... вот ПК... у него в процессоре встроенный USB. этот USB на материнской плате подключен к микросхеме-хабмост. одна дырка - usb device, 3 дырки - usb-host. два хоста от этого моста уходят на внутреннюю перефирию на материнке. один сомтрит разъемом наружу. к этому разъему подключили раширитель usb до 7 портов. и в этот расширитель ткнули принтер/ethernet/wifi/ ну и usb/rs485. Вот при такой герлянде usb/rs485 гарантировано выдаст 100-200 байт неразрывно?

Изменено пользователем razrab83

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

гарантировано выдаст 100-200 байт неразрывно?

Гарантировано неразрывно - нет. Гарантировано 100-200 байт - да.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

29 minutes ago, razrab83 said:

да и ктому же с вашего ходу... "Товар не доступен к продаже"

Это модель для примера. Сейчас подобные идут на PCIe.

30 minutes ago, razrab83 said:

а что ваша плата сделает?

Утверждать не буду, но, во-первых, производитель платы явно указывает на применение платы для работы в сетях Модбас, а, во-вторых, ничто не мешает производителю реализовать на этой плате алгоритм Нэйгла при приёме с задержкой в 3.5 символа или 750/1750мкс, а на передаче удержание высоко уровня на те же 3.5 символа перед переходом на приём. На такой вариант реализации намекает реализация "мозгов" этой платы на ПЛИС от Зилинкс. Так что все требования спецификации Модбас в варианте для ПК несложным образом реализуются и не требуют работы в ОСРВ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

45 minutes ago, Arlleex said:

И это не верное утверждение.

Если выдирать из контекста

48 minutes ago, Arlleex said:

Планированием транзакций занимается драйвер XHCI. Это весьма сложная программа, и некоторые микроконтроллеры (LPC) имеют вовсе аппаратный хост-контроллер. Ни о каком детерминизме в планировании здесь говорить ну никак нельзя, потому что планирование динамическое - на основе текущего состояния и новых данных, подсовываемых от различных сервисов и пользовательских приложений. Таки вопрос повторяется - можно ли на обычном стационаре под линухой или виндой гарантировать неразрывность IN/OUT-транзакций для одного CDC внутри кадра?
 

Можно при малозагруженом USB порте, монопольно обслуживающем один-единственный виртуальный COM порт. Что является самым простым и очевидным вариантом использования.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Если выдирать из контекста

А что там выдранного - Вы утверждали

Цитата

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

что не верно. Никаких одномоментно. И между этими моментами может пройти довольно много миллисекунд.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

ничто не мешает производителю реализовать на этой плате алгоритм Нэйгла при приёме с задержкой в 3.5 символа или 750/1750мкс, а на передаче удержание высоко уровня на те же 3.5 символа перед переходом на приём. На такой вариант реализации намекает реализация "мозгов" этой платы на ПЛИС от Зилинкс. Так что все требования спецификации Модбас в варианте для ПК несложным образом реализуются и не требуют работы в ОСРВ.

так о чем спор? я так и сказал, ещё 100500 страниц назад  - реализовать "честный" модбус на ПК - это гемморой.  

Хорошо... вот плата PCI-1602B-CE, $143. Два rs-485. Что будет в винде? Будет vcp-COM23. Как на апликэйшен уровне вы всё это реализуете? Через API Win32? Или через Qt? Вы по приему 1го байта испустите сигнал и перехватите слотом. В слоте запустите QTimer для отслеживании 1,5 символа? Так вы это себе представляете?

 

Или же допустим, раз написано производителе "Для сетей Modbus" (это же не маркетинг, продавцы все честные для маркетинга никада ни напишут лошь). Т.е. производитель на этой плате в Зилинкс-е реализовал все эти 3,5 и 1,5. Прекрасно. Как это работает в винде? Вы подрубили на PCI-E плату. установили дрова. Заходите в "Диспетчер устройств" и в разделе COM порты нет ни каких дополнительных компортов. Зато появилось устройство ADVANTECH/Modbus0 и ADVANTECH/Modbus1. Вы в этой вашей О! Писи! OPC выбираете подключение через ADVANTECH/Modbus0. Т.е. программа, на Qt, создает ioDevice = QIODevice(QT::TYPE::PCI_E_MODBUS, "ADVANTECH/Modbus0"); И дальше всё согластно протоколу... программа шлет  пакет в ioDevice.... ioDevice->send(adr, buffer, size); Ваша плата получает пакет и в плате плиска начинает выдавать целостный пакет, обрамляя его паузами. Если так - то да, всё будет работать. только какое-то API для винды нужно чтобы из прикладного уровня слать и получать пакеты. Какая-то сишная библа должна прилагаться. 

А если в винде появиться обычный COM порт... то это то, о чем я говорил - можно, но гемморойно. 

 

Изменено пользователем razrab83

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Фанат? Не нужно мне приписывать никакого фанатизма.

Простите, за неудачно выбранный термин. )))  Пусть будет - "сторонник", или "приверженец", или - как сами назоветесь... Однако, сути дела это не меняет. )))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, razrab83 said:

Как на апликэйшен уровне вы всё это реализуете?

В Винде появляется обычный СОМ-порт

 

3 minutes ago, razrab83 said:

только какое-то API для винды нужно

К плате прилагется драйвер.

3 minutes ago, razrab83 said:

В слоте запустите QTimer для отслеживании 1,5 символа? Так вы это себе представляете?

Зачем? Я же говорю, "железо" решает проблемы таймингов.

4 minutes ago, razrab83 said:

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

Именно так это и происходит на практике. Сформировал запрос- отправил. Появились данные для чтения из устройства- сразу прочил весь ответ.

Подобные платы существуют и тысячами используются на промышленных объектах (судя по статистике продаж в России). Странно, что многие люди, дискутирующие тут о Модбас, даже не знают о существовании нормального промышленного оборудования со стороны ПК для работы в сетях Модбас. Неужели даже мысль не мелькнула, почему так много оборудования с Модбас, но почему я не знаю о полноценной поддержки этого стандарта на ПК?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

15 minutes ago, Arlleex said:

А что там выдранного - Вы утверждали что не верно. Никаких одномоментно. И между этими моментами может пройти довольно много миллисекунд.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Появились данные для чтения из устройства- сразу прочил весь ответ.

а если ответ был с дыркой? 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Заблуждаетесь. Тяжело тем, кто живет рядом с ними. Но мы относимся к этому с пониманием... )))))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...