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

в природе есть что-нибудь промышленное, умеющее 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 - то некая коробочка якобы ловит какое-то прерывание, которое нам крайне удобно. а то, что почему-то это все на одной сетевухе умеет работать - ни на какую мысль не наталкивает.


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

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

> while true do read-something-trough-ethernet ?

что угодно.

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

в общем случае - только в алгоритме.

Для анженеров спецом было уточнено.
что происходит с точки зрения ПРОВОДОВ

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

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

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

картинка для растормаживания мамкиных инжинеров

https://cloud.mail.ru/public/39Aw/mvk3RiPkj

> что происходит с точки зрения ПРОВОДОВ

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

Но вот что мне непонятно: если я дурак, то что мне дальше-то объясняешь? Твоя проблема, сам решай, ты ж умный.

>icp [13]
Как я понял, конечные данные попадают в i7 через сетевую карту которая принимает по
tcp/ip. Этот протокол гарантирует доставку но не гарантирует ее время. Посланный ей фрейм может прийти и через неделю после отправки. След-но пытаться в Вашей схеме
получить "реальное время" не получится. Надо менять схему сбора данных или последовательность их обработки.

Но вот что мне непонятно: если я дурак

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

получить "реальное время" не получится.

все там получится, тем более что про тру реальное время речи не идет.

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

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

>icp
Может поможет:
Контроллер I/O подсадить к i7 через Modbus
но i7 будет слайвером а I/O мастером, при этом убирается
опрос от i7. 20 Гц событий при грамотном алгоритме
на контроллере I/O  и 4800/9600, полагаю, можно будет достичь.

камеры-то там не для мебели стоят.

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

и если i7 будет слэйвом,

то у нас либо arm cortex должен обработкой заниматься,
либо мастер должен уже в обратную сторону напрягать сетку,
постоянно спрашивая комп: "а не пора ли дрыгнуть нам рычагом отбраковщика?"

>icp
так I/O напрямую через RS485 к i7 подключить в обход сетки

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

ЗЫ вы реально думаете, что 485-й здесь не упомянут потому что мы про него не знаем или не пробовали?

> не хватает еще какого-нибудь начинающего ардуинщика.

самокритика - это хорошо.

Я уже предлагал: считаешь себя супер-профи - иди на сахару, общайся на уровне.

>..в этой ветке очень остро не хватает ...
действительно не хватает теле-патов - будете 1-м.

> KilkennyCat ©   (09.04.18 12:47) [19]
>
> способ третий - повеситься

Хороший способ, че уж там... :)

каких нафик телепатов?

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


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

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

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

> icp ©   (09.04.18 20:16) [32]
>
> каких нафик телепатов?
>

Таких, которые смогут трансформировать ваш смутный поток сознания в что-то понятное если и не всем, то многим. Или хотя бы некоторым.

>[32]

Что ни делает дурак,

Все он делает не так.

Начинает не сначала,

А кончает как попало.

С потолка он строит дом,

Носит воду решетом,

Солнце в поле ловит шапкой,

Тень со стен стирает тряпкой,

Дверь берет с собою в лес,

Чтобы вор к нему не влез.......

........

.........с той минуты

Стал ходить дурак надутый.

То и дело он, дурак,

Говорит другим: - Не так!

Он не плачет и не пляшет,

А на все рукою машет.

Постороннему никак

Не узнать, что он дурак.

Дети буквы пишут в школе,

Да и спросят: - Хорошо ли?

Поглядит в тетрадь дурак,

Да и вымолвит: - Не так.

Шьют портнихи на машинке,

Шьют сапожники ботинки.

Смотрит издали дурак

И бормочет: - Все не так!

И не так селедок ловят,

И не так борщи готовят,

И не так мосты мостят,

И не так детей растят!

Видят люди, слышат люди,

Как дурак дела их судит,

И подумывают так:

«Что за умница дурак!»

как славно что вы здесь сегодня собрались.

теперь читаем что написано сверху.

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

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

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

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

>> что модбас не подходит,

Значит нужОн CanBus!

>>но цуко поверх rs485

И обязательно с опторазвязкой! Без оптронов rs485 только для лохов.

> icp ©   (10.04.18 08:50) [36]
>
> вот если по-русски сказано, что модбас не подходит, значит
> емае он не подходит.

Без аргументирования сего утверждения это выглядит как "Что-то у меня не работает. Не знаю что, но что такое модбас я тоже не знаю. Значит виноват именно он."


> tesseract ©   (10.04.18 23:51) [37]
>
> >>но цуко поверх rs485
>
> И обязательно с опторазвязкой! Без оптронов rs485 только
> для лохов.
>

Смех смехом, но меня полтора года назад "завалили" на некоем зачёте из-за того что я утверждал что для RS485  общий провод не нужен.

> утверждал

настаивал на этом, что ли? )) или просто, сказал, что необязательно?

> KilkennyCat ©   (11.04.18 02:41) [39]
>
>
> > утверждал
>
> настаивал на этом, что ли?

Настаивал.
Ибо 485-му не нужен общий провод по определению. Ибо 485 интерфейс это дифференциальный интерфейс, для которого важна лишь разница потенциалов между проводами A и B. Если она положительная, то это единица. Если отрицательная, то это ноль.
А провод C - его можно задействовать как экран. Естественно с подключением только с одной стороны.

> [40] Германн ©   (11.04.18 03:08)
> Настаивал.

Зачётчики аргументировали своё вИдение?

> Германн ©   (11.04.18 03:08) [40]


> Ибо 485-му не нужен общий провод по определению. Ибо 485
> интерфейс это дифференциальный интерфейс,

Отчасти.
RS-485 - это стандарт. В стандарте описано наличие необязательного общего.
То есть, как раз по определению, общий провод там может присутствовать.
Или иными словами, он не наследует абсолютно и безоговорочно всё от дифференциального интерфейса.
В противном случае,можно утверждать, что и USB достаточно только D+-, если, например, питание не передается.

http://www.ti.com/lit/an/slla070d/slla070d.pdf  стр. 18

и здесь еще забавно описано: https://en.wikibooks.org/wiki/Serial_Programming/RS-485#Grounds_and_Grounding

>>RS-485 - это стандарт. В стандарте описано наличие необязательного общего.

RS-485 как раз нифига не стандарт, а рекомендация, был бы стандартом начинался бы с IEEE или ANSI. А так - каждый изголяется, как хочет.

RS-485 (англ. Recommended Standard 485)
Название стандарта: ANSI TIA/EIA-485

> KilkennyCat ©   (11.04.18 05:30) [42]
>
>
> > Германн ©   (11.04.18 03:08) [40]
>
>
> > Ибо 485-му не нужен общий провод по определению. Ибо 485
> > интерфейс это дифференциальный интерфейс,
>
> Отчасти.

Тогда добавлю и ещё к этому отчасти. Зачётчик громогласно утверждал, что он при запросе в их техподдержку первым образом спрашивает подключен ли общий провод в обоим устройствам (передатчик, приемник) и если нет, то отказывал в помощи.

> Германн ©   (12.04.18 02:20) [46]

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

Да кстати. Вспомнил, что на самом деле у них (а речь шла об Apollo https://www.aamsystems.ru/produkty/kontrollery/) используется не классический его вариант, а некое подобие RS422.

> Германн ©   (12.04.18 02:54) [48]

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

> kilkennycat ©   (12.04.18 02:36) [47]
>
>
> > Германн ©   (12.04.18 02:20) [46]
>
> ну, тут индивидуальный идиотизм, и на новые микросхемки
> он смотрит как на врагов.
> я б спросил его, что он вообще подразумевает под общим проводом,
>  так как это как бы тоже, неоднозначная фигня в практической
> реализации... ;)

А какой смысл спрашивать у троешника?

А что касается т.н. "общего провода", то эта неоднозначная фигня меня в последнее время достала в вопросах видеонаблюдения. Вот  с какого-то перепуга изготовители видеокамер начали поголовно соединять этот самый общий провод с корпусом видеокамеры. И всё бы вроде ничего пока камеру вешают на бетонную/кирпичную/деревянную и т.п. поверхность. А вот на металлическую, если она достаточно большая, то ...

> Германн ©   (13.04.18 01:47) [50]

это в дорогом (профессиональном) сегменте? или везде?

Ну вот такая к примеру
http://www.interlogix.su/shop/video/analog-cameras/dome-cameras/uvd-xp4dnr-va2-p-copy-from-16122013-092830/

>>Германн ©   (13.04.18 01:47) [50]

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

В данном случае общий провод это внешний контакт BNC-разъема. А на еще одной подобной камере (ссылку не могу найти) это еще и минус питания.

Ну вот она http://ltv-cctv.ru/links-page/LTV_600_tsilindricheskie/ltv-cxm-620-48/

по RS-485
https://www.compel.ru/lib/ne/2017/9/7-rs-485-vse-eshhe-samyiy-nadezhnyiy-promyishlennyiy-interfeys?utm_source=electronix.ru&utm_medium=referral&utm_campaign=ne9&utm_cont ent=20171204&utm_term=anons

> GEN++ ©   (14.04.18 11:26) [56]

Всё бы ничего. Но эта статья скорее реклама от Maxim Integrated.
Во всём остальном это просто мусор найденный троешником в интернете.
Раздел "Сравнение интерфейсов RS-485 и RS-422" просто смешно читать.

Основная проблема применения RS-485 в промышленности и в системах автоматизированного управления зданиями состоит в том, что электрические переходные процессы, возникающие при быстрой коммутации индуктивных нагрузок, электростатические разряды, а также импульсные перенапряжения, воздействуя на сети автоматизированных систем управления, способны исказить передаваемые данные или привести к выходу их из строя.
А какой интерфейс защищён от подобных проблем?

В соответствии со стандартом TIA/EIA-422, интерфейс RS-422 специфицирован для промышленных применений с одним ведущим устройством шины данных, к которой может быть подключено до 10 ведомых устройств
При царе Горохе посчитали, что электроника того времени не потянет более 10 устройств на линии. Но теперь-то другие времена.
Ну а про "одного ведущего" я пока промолчу.

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

Я мог бы и дальше разбирать ту статью, но имхо уже достаточно.