железячники, подскажите.

в природе есть что-нибудь промышленное, умеющее mqtt и с релейными выходами?
открытый коллектор и modbus не подходит.

по картинкам искал.
https://contactless.ru/wiren-board-5/

это не с реле?

это не совсем то. оно для того чтобы самому быть мозгами. реле там нет, торчат gpio.

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

сейчас юзается вот такой ICP DAS ET-7060

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

есть серия MQ (например MQ-7244M), которая умеет в mqtt и его опрашивать не надо, но там только открытый коллектор и 650 ма
https://www.expert-automatic.ru/cat/automation/remote-io-modules/9311/mq-7244m/

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

> icp ©   (07.04.18 10:12) [2]


> так как там модбас, а входы надо читать не ниже 20 герц,
>  то его приходится выносить на отдельную сетевуху чтобы
> он не затыкался (в ПО там тупой "вайл тру читай входы" -
>  иначе никак)

В Киеве бузина, а в огороде дядька.

что не так?

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

окей.
расскажи

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

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

из внешнего мира идут сигналы.
быстро.
с датчиков.
воткнутых в icp das 7600.
их надо читать в ПО.

протокол - модбас.
другого в этой коробке нет.

понятно обьяснил?

> понятно обьяснил?

еще нет.
Коробку трогать нельзя? то есть, только с софтом работать?

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

теперь у вас в руках модбас протокол и вам надо не пролюбить сигналы с датчиков.

был бы там мктт то можно былобы просто подписаться на топики и все.

никаких циклов опроса.

но у нас модбас.

не, я всё равно не понял.
причем тут минимальная задержка и какой-то подсчет? предположим, у нас некая задержка. так она ж для всех задержка. и если коробочка шлет 6 раз в секунду, то и приходит 6 раз в секунду. Даже сложнее: если коробочку запрашивают 6 раз в секунду и т.д....
И если modbas поверх tcp, mqtt поверх tcp, причем первому тыщу лет и он крайне прост и менее требователен к ресурсам (которых не хватает для какого-то там просчета из-за какой-то там задержки), то пока версия Германна всё еще актуальна.

емае, пацаны. ну как же так.

еще раз на пальцах.

датчик. моргает ~ 6 герц. (считайте что он реагирует на предметы едущие по конвейеру)
он прикручен к et 7060 на входной порт.

прилада подключена к et 7060 по модбасу и должна ловить моменты когда датчик срабаывает.

если бы (если бы) там, в коробке был бы mqtt то прилада бы подписалась бы на топик датчика и все.

всё!

но там не mqtt а модбас мать ево.

и чтобы читать датчики прилада делает вот такое:

вайл тру ду
читай что там сейчас на входных портах, не делая никаких слипов воопще!

куда еще то проще вам объяснить.

да всё понятно.
но... ))
было заявлено, что необходимо еще вычислительное время. в этом случае mqtt проигрывает. То удобство, что он там некое а-ля прерывание делает, теряется в ентом самом вычислительном времени.
6 гц... вайл тру ду...
у меня усб 1.1 работает в вайл тру ду. иногда. и2ц на 400 кбод тож в вайл тру ду, и нет что-то никаких проблем.
не нравится вайл тру ду? ну опуститься ниже, генерить от туда событие, что с айпи такого что-то пришло.

а вообще,  б подобное на сахара.ру спрашивал бы

главная цель - это не удобство mqtt.
она в другом.

у компа этого может быть всего две сетевухи. (усб вариант не рассматривается, так как это пром. сегмент)

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

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

а хочется на вторую сетевуху повесить то устройство, которое генерит очень большой трафик.

> усб вариант не рассматривается, так как это пром. сегмент

всё страньше и страньше...

все эти большие и очень большие траффики - от них mqtt не спасет.

> icp ©   (08.04.18 12:16) [4]
>
> что не так?
>
> или ты знаешь как на модбасе гарантировано получить изменение
> входного сигнала с минимальной задержкой не гоняя цикл чтения?
>
>

Мне повторить про Киев и дядьку?

все эти большие и очень большие траффики - от них mqtt не спасет.

как художник художника спрошу.

что происходит в проводах, если в ПО крутится цикл

while true do read-something-trough-ethernet ?

и в чем разница
когда мы не читаем показания, а подписаны на их изменения которые нам кто-то сам присылает нам

не, лучше так спрошу, а то все равно найдете способ включить дурика.

представим что у нас не i7 а atmega328 и нам надо ловить единичку на ноге.

способ первый в цикле читать ногу.
способ второй повеситься на прерывание на этой ноге и спать спокойно.

аналогия полная.

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

у меня усб 1.1 работает в вайл тру ду. иногда. и2ц на 400 кбод тож в вайл тру ду, и нет что-то никаких проблем.

и у нас никаких проблем.

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

так вот еще для тех кто.

пока у нас модбас, мы тратим на него одну сетевуху. только чтобы не пропустить датчик.
вместо того, чтобы вынести ту самую гигапиксельную камеру на эту сетевуху.
потому что кроме нее есть еще несколько мегапиксельных камер, и у них лайтенси скачет в моменты активации той "большой" камеры.

е-мае. вроде и форум не блондинковский, а где-то даже инженерский.

> что происходит в проводах, если в ПО крутится цикл
>
> while true do read-something-trough-ethernet ?

что угодно.


> и в чем разница когда мы не читаем показания, а подписаны на их изменения которые нам кто-то сам присылает нам

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


> представим что у нас не i7 а atmega328 и нам надо ловить единичку на ноге.

никакой разницы. и истинные инженеры (не блондинки) единички на ноге не ловят.


> способ первый в цикле читать ногу.
> способ второй повеситься на прерывание на этой ноге и спать спокойно.

способ третий - повеситься на прерывание от таймера и спать спокойно.
И в любом случае - они не имеет отношения к текущей задаче.


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

Я рискну перефразировать: когда модбас, всё, что умеем - тупо наяривать запрос-чтение в цикле. А когда mqtt - то некая коробочка якобы ловит какое-то прерывание, которое нам крайне удобно. а то, что почему-то это все на одной сетевухе умеет работать - ни на какую мысль не наталкивает.


> е-мае. вроде и форум не блондинковский, а где-то даже инженерский.

Да ладно,  где-то даже инженерский он только когда ты здесь.