Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Промышленная инженерия доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 14
А не староват ли MFC для новый разработок? Почему не веб-интерфейс?
А как связываться с контроллерами? Это должно быть приложение, на WinRT или Win32 или любой другой, но именно приложение под любую операционную систему. А MFC - это скорость разработки. Мне очень комфортно в ней работать, писать много, но и выход в рабочую программу быстрый.
Да, приложение (backend) нужно написать, и frontend (на стороне броузера). Зато приложение можно один экземпляр установить и с многих клиентов пользоваться.
Можно ИИ использовать чтобы быстро все написать.
Вот пример OPC UA клиента: https://ide.opcfy.io
Использован OPC UA Rust SDK в приложении, и PrimeReact для фронта, и Cursor + Claude Code
Хотя от конкретных условий, требований и имеющихся навыков / библиотек зависит, почему бы не использовать старый добрый MFC.
В данном приложении так и получается: разделена серверная и клиентская часть. Серверная часть работает напрямую с контроллерами и льет данные на сервер SQL, а клиенты, подключаются к SQL, считывают данные и сохраняют рецепты на сервере. Есть в планах написать программу для андроида с работой через SQL, но это будет позже и тоже будет самописная, уже такую наподобие писал на джаве.
Быстрая разработка это только готовая скада с готовыми драйверами, мышекликательной визуализацией итп.
А самописки - прошлый век. Реально, времен бухгалтерий на дельфи.
Но есть ряд задач, который скады не покрывают или покрывают дорогими опциями, например сложное архивирование с расчётом всяких кубов агрегаций или пост обработка данных. Вот тут такие решения в тему
Всё было сделано сначала на WinCC (и программы на контроллер тоже нужно было написать). Но рецепты в WinCC очень отвратительные и в последних версиях нет возможности встроить "бесплатные" версии. Поэтому пришлось "пилить" самоделку.
Да и конечно пост обработка данных "на лету" очень показательна. Тут она реализована в полной мере. Расписывает шаги персонала от начала и до конца.
Wincc имеет возможность вызова внешних dll из С-скриптов, там можно всё
Неподалёку от меня есть очень показательная система, которая разрастается на 1Гб объема базы SQL Server в неделю... Прошло больше полгода, сервера уже не хватает... Память на 378 Гб кончилась, думают убежать в облако... беда бессмысленного программирования ради красивых картинок.
Я не говорю, то такое решение подойдет для всех. Но те задачи, которые ставились, программа выполняет. Есть возможность роста. Я, например, подумываю сейчас объединить свичи и прочее комп. оборудование через OPC UA.
По это будет поле темной темы для своих программ... которое уже сделано на 90%.
Неподалёку от меня есть очень показательная система, которая разрастается на 1Гб объема базы SQL Server в неделю... Прошло больше полгода, сервера уже не хватает... Память на 378 Гб кончилась, думают убежать в облако... беда бессмысленного программирования ради красивых картинок.
Не вижу связи с обсуждаемой темой.
Ну так не надо писать 1гб в неделю и пытаться все хранить в памяти.
Это от средств разработки не зависит
Зависит не только от кривизны рук программиста, но и от используемой системы программирования.
Та программа написана на Java and PostgreSQL (новые супер технологии), и периодически зависает с задачами по 1,5 Гб в памяти... при задаче принять от 20-ти устройств пакет 100 байт раз в 5 секунд и отправить его в 1С.
А зачем хранить все подряд а базе данных? Это же не эффективно! У вас могут данные от плк (ну или калькулированные внутри системы) одинаковые одинаковые и очень долго. Представьте себе, что значение 1(битовая 1) с 1000 дискретных датчиков идёт в течение недели. И вы это все тупо кладёте в базу! Причём с интервалом в 100 миллисекунд. 10 записей в секунду, 600 в минуту, а дальше сами посчитайте. Ну или какое нибудь аналогово значение, которое не меняется долго. А вы все продолжаете складировать в базу. Не проще ли сделать отметки времени и указывать что в это время данное значение началось, а в это закончилось. И каждый раз у вас одна запись обновляется в формате времени, если значение тега не поменялось, как изменилось значение тега, так начали новую запись. Теперь у вас вместо 6 048 000 (это количество записей на один тег с одним битовым значением за неделю) имеется одна запись в которой добавлены просто 2 метки времени. Если предположить, что в одной записи у вас порядка 20 байт, то за неделю один тег сгенерит вам 118 мегабайт информации, а 1000 тегов уже 118 гигабайт. Жирненькая база получается и максимально не эффективная. Самое печальное, что и при выборе вам придётся тратить уйму ресурсов для выборки и объёмы буду колоссальный, особенно при постройке графиков. Скорость работы любого приложения будет с каждым разом все медленнее и медленнее и в итоге при росте базы до нескольких терабайт вы скажете заказчику что нужно новое северное железо. Просто мы такое проходили уже)))
При выборке, вы указываете время, на которое хотите получить значение тега и смотрите тупо интервалы. Если укладывается в диапазон времени, то достаете это значение. Если нужен диапазон, то выводите ряд значений и указываете в какие интервалы какие были значения. Да SQL запросы будут немного сложнее, но и экономия объёмов в базе будет колоссальная. Сам такое писал в 2010 году на производстве. На VS2008 и MS Sql 2003. База росла очень медленно, а тегов в ней болталось около 5000 штук с интервалом опроса 100 миллисекунд. В те времена было расточительством использовать большие объёмы данных.
Прошу прощения если слишком много написал. Если есть желание обсудить, пишите, поделюсь опытом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование OPC UA на нативном приложении в технологии MFC MS Visual C++