Comments 36
Вы и вправду применяете такое в реальных проектах?
Если мы говорим о промышленной автоматизации, то понимаем, что программирование будет связано с языками стандарта МЭК 61131-3.
На основе данного стандарта в промышленные контроллеры устанавливают программное обеспечение от:
ISaGRAF, Rockwell Automation (Монреаль, Канада)
CoDeSYS, CODESYS GmbH (Кемптен, Германия)
ISPSoft, Delta Electronics, Inc (Тайбэй, Тайвань)
Как-то странно звучит этот отрывок.
Я, к примеру, в большинстве проектов и CoDeSYS не использую, не говоря про остальные два.
А что вы используете?
Siemens Simatic.
Для проектов покрупнее S7-1500, для помельче 1200.
Программирую в TIA Portal.
И как сейчас обстоят дела с Сименсом? Все по обходным путям?
Я уже год как не в России.
Иногда про проекты спрашивают, как понимаю что S7-1200 без проблем, 1500-е посложнее. Но судя по тому что на моей прошлой работе дела не остановились, а они только на S7-1500 работали, то достают.
Да и тут, так как выходцы из РФ, то спрашивают, бумаги просят предоставить, что никак и никуда.
Сейчас есть и китайские аналоги, и наши тоже. Правда только S7-300 и вроде где то можно достать S7-400. Но и этого вполне хватает для автоматизации на производстве.
А как вы обеспечиваете выполнение задач, то биш процессов, в реальном времени?
А что вы подразумеваете под реальным временем?
Реальное время, это когда задача выполняется в строго установленное время и не может пропустить какое либо событие.
В RTOS я как то могу управлять всем этим. А вот в LINUX?
Приведу пример: Есть у меня счетчик импульсов. Аппаратное прерывание ведь мне не доступно, значит это пользовательский процесс.
А в это время по UART/RS485 пошла передача. Пропустит он импульсы?
Да мало ли задач, где требуется жесткое реальное время - управление по прохождению фазой нуля, работа с энкодерами, выдача и расшифровка ШИМ сигнала.
У меня сейчас на проекте контроллер S7-1516, управляет приточными установками, чиллером, фанкойлами, частотниками по Modbus...
Среднее время цикла 10 микросекунд.
Есть и аппаратные прерывания.
Для этого в модулях дискретных есть счетчики. ПЛК не используется для такого подсчета импульсов
Реального времени нет... Есть только иллюзия его существования :)
Да что вы говорите?
RTOS, FreRTOS, MBED, QNX и даже LinuxRT вполне обеспечиваю жесткое реальное время
Думаю, имелось ввиду, что задержка будет всегда. Где то больше, где то меньше.
В жестком реальном времени если время выполнения функции превысило установленное, то это считается сбоем системы.
Запланированное время может быть минуту, а может быть микросекунду. Суть от этого не меняется. Система реального времени должна обеспечить выполнение.
В микроконтроллерах за временем выполнения следят таймеры с аппаратными прерываниями. Не уложился - все, ошибка всей системы. Потому что в таких системах неопределенность в управлении хуже всего.
LINUX - система разделения ресурсов и не гарантирует времени выполнения задачи. Кроме того в любой момент времени диспетчер процессов может приостановить выполнения процессу и дать ресурс другому.
Ну а дальше все зависит от ваших задач. Если для вас не критично время выполнения той или иной задачи или время цикла настолько большое, что диспетчер процессов несколько раз сделает свой цикл, то тогда да.
В микроконтроллерах за временем выполнения следят таймеры с аппаратными прерываниями.
"Реальное время" - это ж всего лишь термин. За которым нет реального времени как такового. Даже аппаратное прерывание это не реальное время. Если для вас не критично выполнение процедуры за 1 сек, то это тоже можно назвать реальное время. Если и 1 нс недостаточно, то и это уже не назовешь реальным временем.
Давайте говорить в рамках отраслевого ГОСТ Р МЭК 61069-4 2017. Там есть однозначное определение жесткого и мягкого реального времени.
А все эти рассуждения, что есть время, что есть мгновения оставим философам )))
Если говорить о жестких таймингах, тогда мы упираемся в объем выполняемых операций на такт. Это тоже накладывает немалые ограничения на возможности проекта
а оно вообще тут надо, реальное время то? я вот тут вижу бросание пакетами а не каконить ногодрыг, PWM. Для чего нибуть совсем быстро меняющегося это все равно не подойдет
А как же быть, когда тебе не хочется зависеть от стороннего программного обеспечения и иметь переносимый код, который с минимальными трудозатратами можно развернуть на множестве устройств, и даже поставить на персональном компьютере?
Запускайте стартап, например "PLC++", открывайте наработки (особенно интересно посмотреть на вашу реализацию библиотеки Process Object) и уверен к вам присоединятся
https://www.softwaredefinedautomation.io/
Я с этими ребятами в прошлом году общался, тогда они были ещё немецкой компанией, насчёт их идеи о софтварном ПЛК.
Видать, в гору дела пошли.
Можно было бы сразу обозначить в теме что речь идет о мягком режиме софт реального времени без упоминаний МЭК 61131-3, т.к. диспут строится здесь чтением поста по диагонали, отсюда и потеря внимания от концепта автора.
Проще говоря написан на плюсах код под DSP MCUх35 архитектуру, как это происходит под теми IDE, в которых автору - эмбедеру комфортно, или доступом API с объектным описанием регистров портовых состояний и все это делается под сугубо под себя, т.к. ни о какой языковой репликации МЭК 61131-3 речь не может идти.
Конечно такой контроллер не может претендовать на управление многоосными приводами в координатных фрезерных станках или в ARM манипуляторах, которые участвуют во внешней комплексной автоматике и т.д. Но к примеру в инертных системах климат контроля, гидр-распределения, в торговой автоматике и т.д. и т.п вполне рулит и здесь на первом плане вопрос цены от создания до сервиса и жизненного цикла такого решения.
В принципе в таком ракурсе не особо и критично что под капотом Linux или х86 Win в кастомном OEM варианте обе оси будут отрабатывать свои функции без заметной разницы со своими сбалансированными плюсами и минусами.
не хочется зависеть от стороннего программного обеспечения и иметь переносимый код, который с минимальными трудозатратами можно развернуть на множестве устройств
<картинка с джедаями> разве не для этого были созданы эти самые МЭК 61131-3 :) :) :)
Промышленные контроллеры, Linux и только C++. Часть 1