А кто-нибудь разбирается в SCADA-системах?
Сколько у тебя точек(сигналов с датчиков)?
20-30
Посмотри MasterScada, на 32 точки она бесплатная. http://www.insat.ru/services/support/demos/DEMO-MASTER-SCADA...
Преимущества: всё делается мышкой. (заточена на инженеров)
Минусы: здоровая и коммерческая.
Преимущества: всё делается мышкой. (заточена на инженеров)
Минусы: здоровая и коммерческая.
обычно как раз нет, до tcp ip ещё далеко не везде доросли.
А до SNMP?
Ядро SCADA-системы (та часть, что общается с "сервером") сейчас все же делается уже на Ethernet по вполне понятным и логичным причинам. Тривиальные датчики могут сидеть на каком-то другом протоколе (ModBus over XXX), но наружу всё равно будет смотреть "агрегатор" или "конвертер".
Ядро SCADA-системы (та часть, что общается с "сервером") сейчас все же делается уже на Ethernet по вполне понятным и логичным причинам. Тривиальные датчики могут сидеть на каком-то другом протоколе (ModBus over XXX), но наружу всё равно будет смотреть "агрегатор" или "конвертер".ну да, обычно стоит plc со сбором сотен девайсов modbus/4-20 и шлет ethernet куда надо, только ты же про датчики писал
Я не ошибся, когда писал. Я писал о современных приборах, придуманых недавно, а не во времена царя Гороха, когда прикручивание TCP/IP стека в подобные устройства вызывала бурю эмоций и увеличение стоимости продукта в разы. ТС делает, насколько я понимаю, новые датчики. Так вот, не порть порыв, пусть делает правильно.
p/s Датчики ещё можно PoE питать.
p/s Датчики ещё можно PoE питать.
afaik, датчики до сих пор дорого на ethernet сажать.
Ethernet не позволяет посадить все датчики на один кабель, а делать из каждого датчика switch пока не хватает ресурсов у процессора датчика.
Современное решение - это сажать датчики на CAN bus.
ps
В беспроводных решениях не вижу надежности. Эфир не резиновый, и с каждым днём всё больше содержит помех.
Ethernet не позволяет посадить все датчики на один кабель, а делать из каждого датчика switch пока не хватает ресурсов у процессора датчика.
Современное решение - это сажать датчики на CAN bus.
ps
В беспроводных решениях не вижу надежности. Эфир не резиновый, и с каждым днём всё больше содержит помех.
Я не ошибся, когда писал. Я писал о современных приборах, придуманых недавно, а не во времена царя Гороха, когда прикручивание TCP/IP стека в подобные устройства вызывала бурю эмоций и увеличение стоимости продукта в разы. ТС делает, насколько я понимаю, новые датчики. Так вот, не порть порыв, пусть делает правильно.нахрена простому датчику еще и ethernet костыль придумывать? промышленности такого не нужно
промышленности такого не нужноВидимо, у тебя какая-то другая "промышленность". В той "промышленности", в которой мне пришлось поучаствовать, Ethernet используется вдоль и поперек и по "обычным" протоколам/шинам подключаются уж совсем вот прям инфузории-туфельки.
afaik, датчики до сих пор дорого на ethernet сажатьУверен, что знает о CAN/SPI/I2C. Однако по неведомой мне причине для связи между датчиками он сам предложил использовать Ethernet.
Ethernet не позволяет посадить все датчики на один кабель, а делать из каждого датчика switch пока не хватает ресурсов у процессора датчика.http://ru.aliexpress.com/item/88E6350R-MARVELL-QFP-NEW/18011...
Видимо, у тебя какая-то другая "промышленность". В той "промышленности", в которой мне пришлось поучаствовать, Ethernet используется вдоль и поперек и по "обычным" протоколам/шинам подключаются уж совсем вот прям инфузории-туфельки.назови
Современное решение - это сажать датчики на CAN bus.Судя по новостям про умные авто так оно и есть. А обработчики датчиков можно связать друг с другом и со скадой через CAN по IP для унификации. Стандартный же протокол. Чем вместо него пользоваться? SNMP?
Я твои вопросы не распарсил.
http://ru.aliexpress.com/item/88E6350R-MARVELL-QFP-NEW/18011...420р - это дороже всей остальной себестоимости датчика. т.е. только сама эта микруха накрутит цену раза в 2-3
TCP/IP привлек тем, что можно напрямую сливать информацию на сервер без всяких контроллеров-переходников. Вывести микроконтроллер, обвешанный датчиками, в сеть нынче стоит 150 рублей, подумал, что такая некоторая избыточность оправдана гибкостью и масштабируемостью при незначительном увеличении стоимости.
Посмотрел и ужаснулся)))) Ацкий монстр)
Посмотри MasterScada
Посмотрел и ужаснулся)))) Ацкий монстр)
А обработчики датчиков можно связать друг с другом и со скадой через CAN по IP для унификации. Стандартный же протокол.IP зачем? CAN и сам умеет пакеты делать. т.е. поверх CAN-а уже сразу будет прикладной уровень: какой-нибудь аналог modbus-а.
Щас еще хочу глянуть, можно ли для этого LabView приспособить, у меня тут в соседнем классе идет курс по нему, и всё на первый взгляд выглядит довольно доступно)
Щас еще хочу глянуть, можно ли для этого LabView приспособитьПриспособить можно. Если другие работы на неё завязаны, то стоит использовать.
Минусы: учти, что не сможешь продавать решения на нём. Соответственно, в профессиональном плане вкладывание своего времени в освоение LabView - это деньги на ветер.
Минусы: учти, что не сможешь продавать решения на нём.Да, серьезный минус, ибо планируется как-раз проект на продажу.
Но на первое время, пока я даже с наследованием в си++ не разобрался до конца, - возможно сойдет)) Надо делать хоть как-то, иначе можно вечно вылизывать и откладывать.
Посмотрел и ужаснулся)))) Ацкий монстр)И это лучшее, что есть на российском рынке! )
420р - это дороже всей остальной себестоимости датчика. т.е. только сама эта микруха накрутит цену раза в 2-3Как ты оценил эту самую остальную себестоимость датчика, чтобы делать оценки увеличения цены? Ну и да, 8 баксов - это то, что первым я нашел, ткнувшись в гугл. Тот же самый 88E6031/88E6060 стоят уже куда меньше
Но на первое время, пока я даже с наследованием в си++ не разобрался до концаСобрался пилить на C++ свою еще одну нано-SCADA-у? Идущие на смерть - приветствуют тебя!
Я твои вопросы не распарсил.modbus используется, потому что имеет способ адресации значения какого-либо датчика. Соответственно scada заводит в себя modbus, через CAN или ethernet - не важно, чтобы иметь возможность сконфигрурировать запросы. Если отказывать от этого "устаревшего" наследия, то что ещё готового можно использовать для построения ethernet сети для обмена данными датчиков? Протокол snmp похож по возможностям, но традиционно используется в других сферах. Ты предлагаешь его адаптировать?
Собрался пилить на C++ свою еще одну нано-SCADA-у? Идущие на смерть - приветствуют тебя!Ну я щас делаю вторую попытку освоить QT, вроде пока нет ничего сложного в том, чтобы сделать окошко, в котором будут показания датчиков и кое-какие кнопки, ну и работа с сетью.
Сразу предупреждаю, тема для меня малознакомая, поэтому я с трудом буду понимать всякие иронии)
Как ты оценил эту самую остальную себестоимость датчика, чтобы делать оценки увеличения цены?Сталкивался с анализом экономики производства датчиков.
SNMP как основной канал связи для подобных систем пригоден слабо - уж больно дорогой в обработке и совершенно не упрощается в задачах "мне надо часто вот этот фиксированный набор данных". Пока я видел ModBus/TCP, CANoverIP, судя по гуглу, ещё в зачаточной стадии.
Ну и всякие проприетарные системы могут использовать хоть raw Ethernet/IP для передачи своих данных. Броадкастом. Эдакий "я закрою глаза и буду думать, что Ethernet - это шина".
Ну и всякие проприетарные системы могут использовать хоть raw Ethernet/IP для передачи своих данных. Броадкастом. Эдакий "я закрою глаза и буду думать, что Ethernet - это шина".
Ну я щас делаю вторую попытку освоить QT, вроде пока нет ничего сложного в том, чтобы сделать окошко, в котором будут показания датчиков и кое-какие кнопки, ну и работа с сетью.Сделать - да, просто.
Минусы: обслуживать дорого. Вносить изменения, искать ошибки, обеспечивать чтобы старое продолжало работать при добавлении нового функционала, обучать других людей работать с этим, бежать в ногу с прогрессом и т.д.
Ну я щас делаю вторую попытку освоить QT, вроде пока нет ничего сложного в том, чтобы сделать окошко, в котором будут показания датчиков и кое-какие кнопки, ну и работа с сетью.Рекомендации (если идти по пути своего программного решения):
- вместо C++ взять python
- QT сразу заменить на Html
отличная ссылка на сайт производителя софта для автоматизации. а где в реальности в нефтянке, металлургии или где там ещё они пишут, например, расходомеры, которых тысячи на заводе, по ethernet подключены? про какие датчики тут идет речь?
Рекомендации (если идти по пути своего программного решения):почему?
- вместо C++ взять python
- QT сразу заменить на Html
- QT сразу заменить на HtmlЕсли с нуля, то Qt проще. На питоне всё это будет написано намного раньше. хотя не будет стабильной времени обработки сигнала. Для большинства применений питона хватает, есть позитивный опыт.
мне надо что-то более-менее работающее сделать в течение месяца, а си я знаю, в отличие от питона, так что тоже думаю, что для начала, первую пробную версию, проще будет на qt и с++
почему?C++ имеет слишком много детских болезней, чтобы писать на нём несерийное ПО размером больше, чем программа для однокристалки.
Html за копейки позволяет решить кучу вспомогательных задач:
- сделать красиво,
- вывести результат на произвольное устройство,
- развернуть приложение сразу на всех устройствах,
- переиспользовать огромный ассортимент бесплатных готовых компонентов
- добавить вспомогательный функционал
- делегировать выполнение другому
>про какие датчики тут идет речь?
http://new.abb.com/control-systems/essential-automation/comp...
Очень многое по той ссылке уже сопрягается или может сопрягаться по Ethernet. То, что я видел в реальности, базировалось на парадигме "чем раньше уйдем в Ethernet - тем лучше". Возможно, это не самый дешевый способ реализации системы управления объектом (ведь только на датчики придется потратить не $2000, а $6000, если верить , но ещё и коммутаторы покупать надо), однако вполне жизнеспособный.
Есть мнение, что в ситуации ТС Ethernet - самый дешевый способ реализовать задуманное. Или у тебя на примете есть ещё более бюджетный вариант?
http://new.abb.com/control-systems/essential-automation/comp...
Очень многое по той ссылке уже сопрягается или может сопрягаться по Ethernet. То, что я видел в реальности, базировалось на парадигме "чем раньше уйдем в Ethernet - тем лучше". Возможно, это не самый дешевый способ реализации системы управления объектом (ведь только на датчики придется потратить не $2000, а $6000, если верить , но ещё и коммутаторы покупать надо), однако вполне жизнеспособный.
Есть мнение, что в ситуации ТС Ethernet - самый дешевый способ реализовать задуманное. Или у тебя на примете есть ещё более бюджетный вариант?
Или у тебя на примете есть ещё более бюджетный вариант?самый бюджетный вариант - rs485. По современнее, но больше разбираться - CAN bus.
+1 к rs485
и опять дает ссылки на производителя plc, в которых скорее ethernet доп. опция а не данность. Есть еще сайты сименса, йокогавы и др. 
любой современный plc сопрягается с ethernet, только нахрена термодатчику вставленному в трубу ethernet, какой функционал он добавит?
конечно же дешевле modbus'ом все связать на один plc, тем более тянуть сеть можно на километры, как там ethernet я не в курсе.
The faceplate has IP66 and NEMA 4X environmental protection rating and communication options includes Ethernet, RS485, Modbus TCP/RTU and a web server for remote process monitoring.
любой современный plc сопрягается с ethernet, только нахрена термодатчику вставленному в трубу ethernet, какой функционал он добавит?
конечно же дешевле modbus'ом все связать на один plc, тем более тянуть сеть можно на километры, как там ethernet я не в курсе.
Сейчас пишу простенький мониторинг snmp-устройств на NodeJS с вебмордой.
На С++ и других надо писать, когда владеешь языком хорошо, чтобы не получился бег по граблям.
NodeJS тож не шоколадный, но писать простые вещи можно, а при использовании фреймворков, напр. Express, и не очень простые. Минус: на OpenWRT не установишь (чтобы на каком-нибудь роутере крутилось) - нет дистрибутива (да и требования к памяти большие), т.е. отдельный комп под сервер потребуется таки.
P.S. Для snmp и modbus у NodeJS либы есть.
На С++ и других надо писать, когда владеешь языком хорошо, чтобы не получился бег по граблям.
NodeJS тож не шоколадный, но писать простые вещи можно, а при использовании фреймворков, напр. Express, и не очень простые. Минус: на OpenWRT не установишь (чтобы на каком-нибудь роутере крутилось) - нет дистрибутива (да и требования к памяти большие), т.е. отдельный комп под сервер потребуется таки.
P.S. Для snmp и modbus у NodeJS либы есть.
мне надо что-то более-менее работающее сделать в течение месяца, а си я знаю, в отличие от питона, так что тоже думаю, что для начала, первую пробную версию, проще будет на qt и с++Python осваивать быстрее и легче, чем Qt и C++.
Собственно а чем тебе LabView не понравился? Бинарник там собрать можно, библиотеки нужные и он подтянет. Экзешник продавать можно и без самого LabView. Могут возникнуть проблемы с лицензированием, но мне кажется Вам на это накласть
>и опять дает ссылки
и опять пишет не по-русски.
>нахрена термодатчику вставленному в трубу ethernet
нахрена термодатчику modbus? Чем контроллер в modbus принципиально отличается от ethernet контроллера?
>тянуть сеть можно на километры, как там ethernet я не в курсе.
Я, надеюсь, ты слышал про сеть Интернет. Так вот, она на 99% уже работает на Ethernet в том или ином виде. Протоколы IPv4/IPv6 уже достают до любой точки Земли.
и опять пишет не по-русски.
>нахрена термодатчику вставленному в трубу ethernet
нахрена термодатчику modbus? Чем контроллер в modbus принципиально отличается от ethernet контроллера?
>тянуть сеть можно на километры, как там ethernet я не в курсе.
Я, надеюсь, ты слышал про сеть Интернет. Так вот, она на 99% уже работает на Ethernet в том или ином виде. Протоколы IPv4/IPv6 уже достают до любой точки Земли.
ОК, у современных компов нет RS485 интерфейсов. Куда ты его подключать будешь и как? Сколько будет стоить надежный контроллер этой шины? Тот же вопрос про CAN.
самый бюджетный вариант - rs485
нахрена термодатчику modbus? Чем контроллер в modbus принципиально отличается от ethernet контроллера?соотношением цены, простоты, надежности
Я, надеюсь, ты слышал про сеть Интернет. Так вот, она на 99% уже работает на Ethernet в том или ином виде. Протоколы IPv4/IPv6 уже достают до любой точки Земли.это для того чтобы ты мог быстро качать фильмы, а не чтобы получить значение в пару байт и сделать ответное действие.
Цена это, увы, не аргумент - это следствие, не более. Надежность у этих протоколов одинаковая. А вот про простоту я вообще не соглашусь. 100500 датчиков на ethernet, доступных в равной степени из любого места и не требующих дорогущих контроллеров, агрегаторов на концах ModBus шин и прочая-прочая выглядят для меня куда проще.
это для того чтобы ты мог быстро качать фильмы, а не чтобы получить значение в пару байт и сделать ответное действие.Ты усомнился, что Ethernet скейлится лучше ModBus, я привел контр-пример, но ты решил сделать вид, что Интернет - это только про фильмы.
ОК, у современных компов нет RS485 интерфейсов. Куда ты его подключать будешь и как? Сколько будет стоить надежный контроллер этой шины? Тот же вопрос про CAN.комп нужен обычно чтобы залить программу на plc (в промышленности), usb-rs485 стоит сущие копейки на любой вкус и цвет. такое ощущение что тебе маркетолохи уши промыли как круто воткнуть везде ethernet, покупайте наши новые plc
не требующих дорогущих контроллеровс чего ты взял?
зачем тебе доступ к датчику давления в трубе по ethernet из любого места мира? что ты с ним сделаешь? он там стоит совсем не для этого и этот костыль избыточен, да еще и уязвимость повышается.
Ты, похоже, вообще не смотришь, на что отвечаешь. В задаче ТС требуется подключение к компу. Ты правда считаешь, что USB-RS485 переходник за копейки - это надежное решение? У меня валяется пачка из похожих переходников, только на RS232, драйверы для них один глючнее другого под популярную OS, работают через Ж.
Про маркетолохов оставь себе, я тоже могу ответить в стиле "старперы привыкли в 80е клепать всё на RS485, вот и продолжают по-старинке, да ещё и молодежь учат плохому".
Про маркетолохов оставь себе, я тоже могу ответить в стиле "старперы привыкли в 80е клепать всё на RS485, вот и продолжают по-старинке, да ещё и молодежь учат плохому".
Мне не нужен доступ датчика давления в трубе из любого места мира. Ты спросил, как скейлится ethernet, я ответил.
Ты усомнился, что Ethernet скейлится лучше ModBus, я привел контр-пример, но ты решил сделать вид, что Интернет - это только про фильмы.скажи тезисно что ethernet дает для пользователя по сравнению с другими протоколами? а то я уже запутался
Мне не нужен доступ датчика давления в трубе из любого места мира. Ты спросил, как скейлится ethernet, я ответил.так это решение дороже, зачем пользователю это нужно сейчас? просто потому что это круче?
Протоколы IPv4/IPv6 уже достают до любой точки Земли.Представь что в подвале необходимо разместить штук 30 датчиков и ethernet в подвал уже заведен.
Если каждый датчик делать на ethernet, то необходимо тянуть 30 проводов и ставить два здоровых 16-портовых свитча.
Для Rs485 - это будет один провод, последовательно соединяющий все датчики и один одно-портовый converter rs485<->ethernet.
Куда ты его подключать будешь и как?бюджетный вариант - usb-свисток (цена в районе 20$)
enterprise вариант в стойку - rs485<->ethernet http://mydigitalangel.ru/catalog/preobrazovateli/nport-5650-...
Сколько будет стоить надежный контроллер этой шины?1 порт - около 100$ (на одном порту - до 255 датчиков)
Тот же вопрос про CAN.1 порт - около 200$
Основной мой тезис заключается в том, что ModBusRS-485 и Ethernet - это два разных протокола, которые могут использоваться для работы с любыми датчиками. Стоимость датчиков с ethernet сейчас выше, чем тех, что на ModBusRS-485, исключительно из-за того, что все уже запущенные ранее системы работают на ModBus (RS-485) и перепроектировать всё под ethernet нерентабельно, да и не нужно. В новые системы, однако, Ethernet проникает глубже и замена ModBusRS-485 на Ethernet - это вопрос скорее времени и политики, нежели реальной экономии.
В новые системы, однако, Ethernet проникает глубже и замена ModBus на Ethernet - это вопрос скорее времени и политики, нежели реальной экономии.ну вот посмотрел я на твои контроллеры по ссылке, ничем абсолютно они не отличаются от стандартных других производителей. откуда ты взял про ethernet датчики я так и не понял, структура промышленной сети у них дефолтная, в каждой точке полные аналоги других производителей.
соображения насчет проникновения ethernet это только твои соображения, ничем не подкрепленные. Ethernet нужен на уровне выше, но никак не на низшем исполнительном
Представь что в подвале необходимо разместить штук 30 датчиков и ethernet в подвал уже заведен.Если каждый датчик делать на ethernet, то необходимо тянуть 30 проводов и ставить два здоровых 16-портовых свитча.Если в этих датчиках есть 3-портовый свитч, стоимость которого, как мы выше уже узнали, меньше $3, то решение на Ethernet будет стоить столько же, сколько на RS-485 + надежный контроллер за $100. Проводов тоже нужно будет тянуть ровно один.
У звезды (к слову, коммутаторы бывают и 48-портовые) есть свои плюсы, в т.ч. датчики эти питать можно прямо со свитча - тянуть нитку питания к датчикам уже не требуется, появляется защита питания при сбое цепи питания каждого отдельного датчика и т.п.
и замена ModBus на EthernetПонятно, что ты имеешь в виду, но так писать не стоит.
Не стоит противопоставлять Modbus и Ethernet. Это протоколы разных уровней. Modbus Tcp работает поверх Ethernet-а. Противопоставлять стоит ethernet и rs485, или ethernet и полевая шина (CAN bus, profibus и т.д.).
Понятно, что ты имеешь в виду, но так писать не стоит.Согласен.
Удачи
соображения насчет проникновения ethernet это только твои соображения, ничем не подкрепленные
Если в этих датчиках есть 3-портовый свитч, стоимость которого, как мы выше уже узнали, меньше $3, то решение на Ethernet будет стоить столько же, сколько на RS-485 + надежный контроллер за $100. Проводов тоже нужно будет тянуть ровно один.На сколько всё это будет электрически изолировано? Что будет если на это всё пробьёт 380в?
100$ за порт - это включая электрическую независимость одних цепей от других. Используются оптопары для развязки соединений.
в т.ч. датчики эти питать можно прямо со свитча - тянуть нитку питания к датчикам уже не требуется, появляется защита питания при сбое цепи питания каждого отдельного датчика и т.п.ага насосы питать киловатные, клапана тоже можно. зато сбой датчика по питанию положит всю сеть. Питание это вообще отдельный разговор в промышленности, такая штука не прокатит...
Ethernet точно так же можно развязать оптронами. Сигнальная суть у Ethernet и RS-485 одна и та же - и там, и там диф пары.
Тебе, я смотрю, очень нравится передергивать и доводить мысль собеседника до абсурда, не пытаясь вникнуть. Пака.
если собеседник не работал "в поле", а только видимо прогал в офисе, то да приходится 
Обычно промышленные датчики работают по ModBus/TCP и SNMP.просто все началось с ложной информации про датчики и ссылку на контроллеры, опровергающие это утверждение. Сейчас это пока не так и острой необходимости в переходе на ethernet нет
Условно можно выделить 4 поколения датчиков.
1 поколение. С датчика идет токовый сигнал 4-20мА до контроллера.
2 поколение. В датчик ставится однокристалка и преобразователь в rs485
3 поколение. В датчик ставится ethernet.
4 поколение. В датчик ставится беспроводной передатчик: WiFi, ZigBee и т.д.
В промышленности, где датчиков много, окружающая среда недружелюбная (высокие токи, пыль, вибрация и т.д.), надежность требуется очень и очень высокая, а под рукой есть узкопрофильные специалисты - датчики до сих пор используются 1 поколения. И только сейчас из-за сильного падения цен на однокристалки начинается потихоньку переход на 2-ое поколение.
В умных домах (и аналогах) - окружающая среда дружелюбная, монтирование и обслуживание ведут специалисты широкого профиля или вообще любители. И здесь сейчас активно используются датчики 3-го и 4-го поколения.
1 поколение. С датчика идет токовый сигнал 4-20мА до контроллера.
2 поколение. В датчик ставится однокристалка и преобразователь в rs485
3 поколение. В датчик ставится ethernet.
4 поколение. В датчик ставится беспроводной передатчик: WiFi, ZigBee и т.д.
В промышленности, где датчиков много, окружающая среда недружелюбная (высокие токи, пыль, вибрация и т.д.), надежность требуется очень и очень высокая, а под рукой есть узкопрофильные специалисты - датчики до сих пор используются 1 поколения. И только сейчас из-за сильного падения цен на однокристалки начинается потихоньку переход на 2-ое поколение.
В умных домах (и аналогах) - окружающая среда дружелюбная, монтирование и обслуживание ведут специалисты широкого профиля или вообще любители. И здесь сейчас активно используются датчики 3-го и 4-го поколения.
Поколения 2 и 3 отличаются только протоколом и не более того. Нет никакой разницы (ну т.е. вообще нет), какой сигнал будет там в проводах бегать - RS-485 или Ethernet. По сути своей второе поколение родилось тогда, когда третье было ещё дорого. Сейчас серьезных оснований продолжать клепать на RS-485 по-просту нет и со временем, думаю, оно отомрет так же, как отмер проводной интерфейс у MacBook Air.
До WiFi внедомовая автоматика не доберется, впрочем, в обозримом будущем. Ты правильно написал, что в эфире слишком много мусора и его кол-во только увеличивается.
До WiFi внедомовая автоматика не доберется, впрочем, в обозримом будущем. Ты правильно написал, что в эфире слишком много мусора и его кол-во только увеличивается.
Если в этих датчиках есть 3-портовый свитч, стоимость которого, как мы выше уже узнали, меньше $3Есть сомнение, что копеечная однокристалка сможет работать с ethernet контроллером. Однокристалка не угонится за ethernet-ом.
Нет никакой разницы (ну т.е. вообще нет), какой сигнал будет там в проводах бегать - RS-485 или EthernetModbus RTU поверх RS-485 получается резко проще по стеку, чем Modbus TCP поверх Ethernet-а.
В первом случае, есть только один уровень и modbus-пакет сразу выкидывается на линию.
Во втором случае, появляется 4 уровня: modbus, tcp, ip, ethernet. И для обработки всех эти уровней требуется резко больше кода и резко больше вычислительной мощности.
10Base-T уже вполне доступны для 8-битных однокристальных контроллеров.
Modbus RTU поверх RS-485 получается резко проще по стеку, чем Modbus TCP поверх Ethernet-а.Ну вот теперь ты наступаешь на ту же граблю, что и я. Тебя никто не заставляет реализовывать на инфузории-туфельке весь стек до ModBus/TCP. Достаточно работать с Ethernet как с шиной.
Достаточно работать с Ethernet как с шиной.В чем смысл и ценность такого решения?
Куда бОльшей гибкостью, на мой вкус. В этой конфигурации кол-во устройств на шине регламентируется размером MAC-таблицы коммутатора. До тех пор, пока он работает в режиме коммутатора, все инфузории-туфельки будут получать только нужные им сообщения, не отвлекаясь на сообщения, адресованные соседям. Опять же, если тебе вдруг понадобилось вытащить какой-то конкретный датчик на уровень выше - ты просто меняешь этот датчик на обладающий достаточным мозгом и едешь дальше. По сути, используя Ethernet, ты получаешь возможность обновить систему со 2 уровня до 3 без перестройки и, скорее всего, без останова вообще.
Как будет выглядеть код в датчике по обработке сообщений?
Если мы говорим в рамках парадигмы "Ethernet как шина", то этот код будет отличаться лишь тем, что адреса на шине у него будут 48-битными (MAC-адрес). В остальном можно хоть ModBus повторять.
этот код будет отличаться лишь тем, что адреса на шине у него будут 48-битными (MAC-адрес).Все остальные стандартные инструменты не смогут работать с таким решением.
О каких "стандартных" инструментах идет речь? Если ты о "стандартных" софтах, так специально для этих софтин можно придумать конвертер в ModBus/TCP Ну или обучить их этому "раздутому" протоколу.
Ну или обучить их этому "раздутому" протоколу.так специально для этих софтин можно придумать конвертер в ModBus/TCPВот именно, что придумать -> внедрить, стандартизовать, сертифицировать, подсесть на конкретного производителя и т.д.
При rs485 будет полностью стандартное решение.
С этим никто не спорит. Надеюсь, что ты тоже не будешь спорить с тем, что при своем появлении в 1999 ModBus/TCP был тоже нестандартным решением. Совсем.
имхо, ethernet никто использовать нестандартно не будет. Слишком много разнородного оборудования завязано на стандартное поведение ethernet-а. И слишком маленькая память у специалистов(людей, вообще), чтобы их еще грузить тем, что бывает особое оборудование, которое использует ethernet нестандартным образом.
Согласен с тобой, что есть сильный тренд на то, чтобы делать всё на ethernet-е (не вводя разносортицу по шинам и коммуникационному оборудованию)
ps
Миниатюрный стандартный ethernet-разъем уже есть? Если нет, то почему его до сих пор не придумали и не внедрили?
Согласен с тобой, что есть сильный тренд на то, чтобы делать всё на ethernet-е (не вводя разносортицу по шинам и коммуникационному оборудованию)
ps
Миниатюрный стандартный ethernet-разъем уже есть? Если нет, то почему его до сих пор не придумали и не внедрили?
ethernet никто использовать нестандартно не будетЯ встречал такое в проприетарных решениях
Миниатюрный стандартный ethernet-разъем уже есть? Если нет, то почему его до сих пор не придумали и не внедрили?Ну микроразъемы я не видел, есть всякие M12 под двухпарный провод.
Что-то смутно припомниаю, что Modbus он не такой уж и универсальный и у каждого производителя свой Modbus... скорее всего ошибаюсь.
Немного занимался подобными вещами - про Мастерскада (insat) могу сказать, что она глючная и пустая, плюс готовый ОРС-сервер к ней платный.
Структура скады зачастую подразумевает наличие контроллера (и всё управление крутится в контроллере), соответственно, большинство скад заточено под языки стандарта МЭК 61131
http://ru.wikipedia.org/wiki/IEC_61131-3
Зачастую выбор скады упирается в выбор контроллера, так как далеко не все скады имеют драйвера связи с конкретным контроллером.
Серьёзные международные скады стараются выпускать единый пакет контроллер+скада+модули связи+закрытые протоколы обмена данными, чтобы не только ПО, но и всё железо (кроме самих датчиков и исполнительных устройств) было их производства.
Можешь поиграться с Trace mode, у них вроде есть полнофункциональная демо-версия (работает час).
Структура скады зачастую подразумевает наличие контроллера (и всё управление крутится в контроллере), соответственно, большинство скад заточено под языки стандарта МЭК 61131
http://ru.wikipedia.org/wiki/IEC_61131-3
Зачастую выбор скады упирается в выбор контроллера, так как далеко не все скады имеют драйвера связи с конкретным контроллером.
Серьёзные международные скады стараются выпускать единый пакет контроллер+скада+модули связи+закрытые протоколы обмена данными, чтобы не только ПО, но и всё железо (кроме самих датчиков и исполнительных устройств) было их производства.
Можешь поиграться с Trace mode, у них вроде есть полнофункциональная демо-версия (работает час).
Оставить комментарий
nemec2707
Прежде чем изобретать свой велосипед, внезапно захотелось узнать, а что есть готовое.Задача: есть куча устройств - датчиков и исполнительных устройств, нужно их все завести на сервак, и на серваке запрограммировать всю логику их взаимодействия, а также сделать интерфейс оператора.
Первое что пришло в голову - вывести всё в локальную TCP/IP сеть, и написать для сервера прогу, которая будет разруливать событиями и в гуе которой всё будет наглядно видно.
Но я откуда-то знаю, что это называется SCADA, но на этом мои познания заканчиваются, может кто-то подскажет поточнее, в какую сторону копать, какие есть конкретные программыне решения, подходящие для моего масштаба задачи?