
Комментарии 11
А не староват ли 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С.
Использование OPC UA на нативном приложении в технологии MFC MS Visual C++