В свое время лет 5 назад я так же думал о постройке кодогенератора с конфигураотором под MCU, для полигона взял отладочную шилду STM32 и занялся прототайпингом ее эмулятора, чтоб была комфортная GUI обертка под все хотелки разрабов. Настраиваешь GPIO под свой алгоритм и можешь посредством UART управлять состояниями GPIO из под LabView (типа I/O свисток) с возможностью дальнейшей С - прошивки, если результат нравится. Но в какой-то момент остановился, т.к. идея уперлась в массу ограничений, прежде всего концептуальных. Зачем клонировать слонов, если они все ограничивают Вас своей архитектурой, к слову не фонтан какой подходящей для многопортовых контроллеров, где требуется сложная оркестрация, за рамками возможностей RISC да и есть такие IDE визуального программирования (для баловства творческой молодежи). В конечном итоге я пересмотрел идею в пользу CPU CISC x86 и там все стало на свои места без ограничений с упором на проекты со сложной автоматизацией.
Пардон, если не в тему, но все же это в параллельной экосистеме. G не про кодогенерацию буквально, если на С вы выполняете описание инструкций, на которых должны функционировать процедуры алгоритма, то на G алгоритм строится из готовых инструкций - узлов. C и G - разные парадигмы, когда G значительно упрощает работу и одновременно исключает человеческий фактор ошибок переводя фокус в иной разрез программирования на потоке с возможностью параллельного выполнения нескольких последовательностей инструкций (потоков) в рамках одного процесса. Программист мыслит потоками данных, а не строками кода. G, это когда, cреда разработки скрывает генерацию и оптимизацию кода, снижая количество синтаксических и инфраструктурных ошибок и смещая фокус программирования в сторону архитектуры, параллелизма и логики обработки данных.
При разрешении работы канала таймера и других устройств необходимо подтвердить два раза, тогда все будет работать как надо. GPIO_IN это по умолчанию, система сообщает, что вывод свободен, вы подтверждаете, что хотите занять, система снова сообщает что заняла вывод Вашей функцией и Вы нажимает ок. Если не правильно и вывод не был GPIO_IN, программа не дает вообще включить выход.
Если уж пишется тулс для обегчения жизни, то зачем разрабу нужны в.с. познания установочных инструкций производителя MCU. Почему бы не автоматизировать такую мелочь, как впрочем и все подобные рутинные вопросы, чтоб не нагружать абстракцию интерфейса юзера дополнительным комом начальных знаний, когда важен результат, а не рытье инструкций от дата шит. Вопрос - на каком языке построено логическое ядро софтины? Его работа не должна, не имеет права на баги в разработке конечных или промежуточных исходников? Ответ я предвижу. Почему бы не применить в качестве ядра под токую IDE язык "G" который заточен под потоковое программирование и визуализацию ввода любых инструкцийв один клик, а блоки его кода при их применении не позволят ошибаться в процессе написания ядра. Глядишь и лагание будет сведено к нулю и сам по себе процесс создания исходника будет автоматным программированием, людям не придет в голову, что есть системная инструкция, о которой они не знали или забыли, другие баги... И еще, при таком концепте Вы вынуждены постоянно следить и обновлять библиотеки всех тех МКшек, которые актуальны или будут развиваться и это тянет за собой шлейф дополнительных пересмотров всего ядра.
Однако конфигуратор выполнен под парадигму - упростить студентам жизнь на 10% и не меняет тотально правила игры подхода в проектировании логики. Мое мнение, что отказ от кодирования с привязкой к языковым методам,именно то, что еще в ожидании, когда все что нужно знать кодеру останется "под капотом" в виде логического ядра, а разработчики будут строить модели своих алгоритмов простыми, немногочисленными инструкциями и их визуальным вводом в общую оркестрацию системы, без заморочек с загрузкой и прошивками, отладками таймингов, поиском библиотек, с визуальной симуляцией кода в работе и т.д. и т.п....
Если бы я решил вести детский робототехнический кружок (мне не нравится слово кружок), я бы так его никогда не назвал, т.к. в названии сидит противоречие будущему и вот почему - Детей нужно сразу погружать в мир взрослой робототехники с реально полезным концептом. Разработка программного обеспечения такого сообщества должна быть интуитивно доступна для генерации исходного кода (оркестрации) и аппаратно модульным, чтоб дети не концентрировали свое внимание на языковых абстракциях и схемотехнике, многие из них чисто физиологически в таком возрасте не могут себя заставить, не то что целеустремленно изучать, они не могут больше 30 минут вообще во что либо осмысленно погружаться, т.к. мозги еще умеют от природы и Лего не лучший пример перехода к реальной робототехнике. Лего это занимательный игровой конструктор с элементами взрослой игры в программистов и мехатроников. Если здесь есть присутствующие кто после Лего начал изучать реальный R&D, то поймут о чем я говорю. Мое мнение что процесс разработки будущего, это по большей части продумывание и оптимизация алгоритма мехатроники с минимальной нагрузкой требований к механике. При этом IDE такого концепта должна соответствовать в.с. порогу уровня подростка 10 - 16 лет.
Под паллетайзером в моём комментарии речь именно про самоходные тележки/штабелёры с автоматическим управлением, которые возят и устанавливают паллеты, то есть про тот же класс driverless industrial trucks, на который и ссылается ISO 3691‑4. Стандарты по роботам (ISO 10218‑2 и ISO/TS 15066) допускают совместную работу человека и робота только при ограничении энергии и силы до уровней, при которых даже контакт не приводит к травме; это реализуемо для лёгких коллаборативных манипуляторов, но никак не для многосоткилограммовой паллеты, особенно на высоте. Поэтому индустриальная практика для таких случаев - либо ограждённые ячейки, либо очень жёстко организованные общие зоны с ограничением скорости, зонами исключения для людей и системой обнаружения персонала, а не «свободное перемещение» в привычном смысле.
В этом контексте мой тезис был не про то, что «стандарты запрещают любую совместную работу», а про то, что конкретная конфигурация, где тяжёлый самоход с паллетой катается по полу буквально в общем проходе, а главным аргументом безопасности служит возможность ручного вмешательства оператора через кнопку - гриб, идёт вразрез как с ISO 3691‑4, так и с общими принципами риск‑ориентированного проектирования систем безопасности.
Вижу что полетаизеры выполняют работу в зонах со свободным перемещением людей, что категорически не допустимо из соображений техники безопасности, как бы разрабы не стучали себя в грудь кулаками, доказывая 100% безопаснось.
возможность ручного вмешательства оператора для устранения возможных неисправностей.
Полетайзер прет на рабочих и в это время оператор в прыжке нажимает на красную кнопку размером с ладонь? Причин запуска самохода может быть масса.
Ок, с этим проехали, для полного обзора линии чисто снования по полу полетайзеров не достаточно, это выглядит как новостная заметка, как это и есть на данном примере. Интересно что происходит когда поддон ( к слову он деревянный сколоченный гвоздями) с молоком на высоте 3 метра был неудачно установлен и произошел его перекос. Как система реагирует на такие ситуации? В мире есть немало других логистических технологий, начиная от автоматизированных XYZ гантри манипуляторов, до 3D рельсовых матриц хранения в куче с конвейерными треками и для каждого из таких алгоритмов есть экономически обоснованная целесообразность.
Бизнес‑заказчик хочет оценить, насколько эффективно роботизированные технологии смогут справиться с ключевыми процессами внутри склада, такими как перемещение готовых продуктов от конечной точки производственной линии до временных зон хранения (КБО) и последующий вывод продукции на дальнейшую обработку.
Чтоб оценить идею применения С1, в статье недостаточно реальных иллюстраций с зонами, от точки приема до точки выдачи. Можно много рассуждать, но пока все это выглядит очень абстрактно и не факт что экономически логично для клиента.
А я хожу кругами вокруг этих Timekettle W4 Pro с функцией Ai синхронного первеода, с активным шумоподалением и для аудио прослушки. На сегодня они считаютя флагманским по качеству Ai (0,2 с задержка) но честного обзора пока на них нет, возможно из за их стоимости $381 на амазоне
Тема востребована, т.к. направлена на решение вопросов, которые происходят из причин их важности когда идеи нуждаются в прокачке с минимальными затратами и усилиями.О важности MVP в любом стартапе уже давно все сказано, при этом мало кто обсуждает проблемы инициаторов в выборе той или иной среды построения кода, от которого зависит аппаратный дизайн и то, как это легко и доступно увидеть в динамике на этапе идеи с начальными алгоритмами. То о чем здесь пишу, это часть осмысленного и моего проекта создания онлайн лаборатории под свою IDE включая и работу с аппаратной частью и симуляции и много еще всего, что должно работать на всех. Увы я не смогу дальше здесь развивать в подкастах эту тему, т.к. получу бан за промоушинг. Если кому интересно обращайтесь в личке.
У нас несколько другая сфера применения low-code автоматика и робототехника, но подход аналогичный, кубики программистам, их сбор инженерам - архитекторам, на выходе рабочий код управления аппаратным сценарием и аппаратные спецификации всего проекта. Что характерно инструкции для визуального ввода может генерировать обученная модель ИИ, таким образом, что инженеру архитектору достаточно на вербальном уровне поставить задачу (запустить моторо на 10с и остановить, или запустить до момента триггерного срабатывания по значению со стороны датчика положения каретки и т.д.) К разработке программного ядра подход был на построение интерпретаторов команд бинарной логики, применяемых в системах автоматизированного логического управления.
Вообще-то правильным и логичным тоном в любой разработке считается применение встроенного в стенд такого источника питания, как и другой аппаратной части в виде уже существующих готовых модулей с требуемыми функциями и параметрами, которые в дальнейшем могут стать частью прототипа (репликация или как есть), при этом сегодня выбор таких готовых и выставленных на поток, как источников с в.у. характеристиками, так и других модулей, вполне позволяют вести их подбор в качестве универсальных компонентов к той архитектуре устройств, которые Вы разрабатываете сегодня или с идеями на завтра. Такой подход избавит Вас от дальнейших дополнительных затрат в создании прототипов или промышленных образцов.
Лучший интерфейс — тот, который делает жизнь проще, не заставляя задумываться, как он работает.
UX/UI - в свое время это для успеха был кусок работы чуть ли не самым главным в Data Sciense. Помню момент, когда клиенты просто визжали от удовольствия, когда в качестве интерфейса получали свой рабочий кабинет с видами столов и ящиками в которых они любили рыться, что-то находить, далее размещать в отдельные разноцветные папки и передавать их содержимое своим сотрудникам, те, в сою очередь принимали содержимое адресных папок к дальнейшим задачам, которые соответствовали их должности и инструкциям и т.д. и т.п. Ошибки исключались, т.к. в алгоритме были заложены запреты на ошибочные (человеческий фактор или нарушение последовательностей инструкций). Сейчас передо мной стоит более сложная задача - UX/UI IDE разработчика автоматики и робототехники где на ПК возлагаются задачи не только автоматизации процесса генерации исходного кода логического управления, но и функции логического контроллера под внешний I/O аппаратный интерфейс и здесь мне не совсем понятно, что в таком случае должен представлять из себя такой интерфейс(ы). Когда это кнопки с памятью вводимых состояний, дисплей часов для выставления там таймингов, селекторные кнопки для указания номеров USB портов и т.д. и т.п....
А еще практикуется такая фишка среди фрилансеров и всех их подопечных, когда они по договоренности с клиентами - крупными фирмами, демонстрируют другим потенциальным заказчикам "свои производственные площадки" которые по факту не являются ихними. Водят по цехам, IT отделам гостей как по зоопарку.
Почему бы и нет, спросите его, если это просто любопытство, а интерес к стороннему опыту все же продуктивней иметь из первоисточников, впрочем гигачат на данный момент дает вполне адекватное описание платформы и ее применение. :-
LV позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС, в условиях встраиваемых решений, промышленных контроллеров или систем реального времени. Это можно рассматривать как специализированную ОС-подобную среду, полностью разработанную в визуальной среде. Не полный перечень возможностей: Запуск кода на RT-контроллерах с детерминированным исполнением;
Управление потоками, приоритетами задач, прерываниями, синхронизацией и расписанием - то, что выполняет ядро RTOS;
Проектирование логического уровня "ядра" на уровне FPGA - реализация логики взаимодействия между устройствами, шин, интерфейсов; Разработка приложений с параллельными вычислениями, распределенной логикой и управлением событиями - по сути, имитация ядра ОС на прикладном уровне; Управление ресурсами, вводом/выводом, коммуникациями (Modbus, TCP/IP, CAN), памятью и задачами. Вы можете построить систему, где LabVIEW:
Управляет всеми задачами (как диспетчер процессов).
Имеет цикл реального времени с высоким приоритетом (как планировщик).
Реализует драйверы устройств (через FPGA или I/O Nodes).
Управляет прерываниями, вводом-выводом и хранением данных (как ядро).
Работает автономно на хардваре без традиционной ОС.
Важно понимать, что LabVIEW не создает ОС в классическом смысле, но позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС.
Как про "может быть сразу проверена на железе через стандартный USB GPIO.", думаю статья вышла бы не плохая.
здесь требуется конкретика, что проверять со стороны USB GPIO? Выше по ветке я дал описание решения которое применяется в программном контроллере, детали проекта обсуждаются здесь. Если у Вас возникнет желание выпустить авторскую публикацию на хабре с описанием платформы, окажу всяческое содействие. Я не писатель.
LabView это не ради "эмуляции ОС", а ради сокращения цикла "идея - исполнение" при разработке автономных логических систем.
Так что речь не про «берите любую IDE», а про осознанный выбор среды, в которой логика описывается так же наглядно, как монтируется схема — и может быть сразу проверена на железе через стандартный USB GPIO. Впрочем при желании на LV можно и OC создать, для чего, это уже другой вопрос.
Если вы имеете ввиду ПЛК, то с одной стороны мне абсолютно непонятно, как вы к этому внезапно пришли, а с другой стороны чем ПЛК принципиально отличается от микроконтроллера помимо того, что там зашит проприетарный софт ?
пришел не внезапно, а более чем 7 лет по озвученной Вами причине с уходом от проприетарности железа с его содержимым и того букета плюшек который он за собой тянет с клиента. Тема тянет не на одну статью, идея не из лучших отвлекать здесь кого либо на то, что здесь не предусмотрено к обсуждению. На данный момент это коробочное решение со всеми сопутствующими атрибутами и своим сообществом. Если интересно могу скинуть в личке.
Ваш подход тоже прекрасно эмулируется при наличии такого желания и точно так же при эмуляции потребует либо QMP либо решения подобного выше.
Любопытно узнать, возможна ли в QMP реализации или моделирования реального логического контроллера, исполняющего логику в потоке данных или по триггерам/флагам, как это делается в автоматных логических контроллерах? Насколько мне известно среда не дает таких средств разработки.
В свое время лет 5 назад я так же думал о постройке кодогенератора с конфигураотором под MCU, для полигона взял отладочную шилду STM32 и занялся прототайпингом ее эмулятора, чтоб была комфортная GUI обертка под все хотелки разрабов. Настраиваешь GPIO под свой алгоритм и можешь посредством UART управлять состояниями GPIO из под LabView (типа I/O свисток) с возможностью дальнейшей С - прошивки, если результат нравится. Но в какой-то момент остановился, т.к. идея уперлась в массу ограничений, прежде всего концептуальных. Зачем клонировать слонов, если они все ограничивают Вас своей архитектурой, к слову не фонтан какой подходящей для многопортовых контроллеров, где требуется сложная оркестрация, за рамками возможностей RISC да и есть такие IDE визуального программирования (для баловства творческой молодежи).
В конечном итоге я пересмотрел идею в пользу CPU CISC x86 и там все стало на свои места без ограничений с упором на проекты со сложной автоматизацией.
Пардон, если не в тему, но все же это в параллельной экосистеме.
G не про кодогенерацию буквально, если на С вы выполняете описание инструкций, на которых должны функционировать процедуры алгоритма, то на G алгоритм строится из готовых инструкций - узлов. C и G - разные парадигмы, когда G значительно упрощает работу и одновременно исключает человеческий фактор ошибок переводя фокус в иной разрез программирования на потоке с возможностью параллельного выполнения нескольких последовательностей инструкций (потоков) в рамках одного процесса. Программист мыслит потоками данных, а не строками кода.
G, это когда, cреда разработки скрывает генерацию и оптимизацию кода, снижая количество синтаксических и инфраструктурных ошибок и смещая фокус программирования в сторону архитектуры, параллелизма и логики обработки данных.
Если уж пишется тулс для обегчения жизни, то зачем разрабу нужны в.с. познания установочных инструкций производителя MCU. Почему бы не автоматизировать такую мелочь, как впрочем и все подобные рутинные вопросы, чтоб не нагружать абстракцию интерфейса юзера дополнительным комом начальных знаний, когда важен результат, а не рытье инструкций от дата шит.
Вопрос - на каком языке построено логическое ядро софтины? Его работа не должна, не имеет права на баги в разработке конечных или промежуточных исходников? Ответ я предвижу. Почему бы не применить в качестве ядра под токую IDE язык "G" который заточен под потоковое программирование и визуализацию ввода любых инструкцийв один клик, а блоки его кода при их применении не позволят ошибаться в процессе написания ядра. Глядишь и лагание будет сведено к нулю и сам по себе процесс создания исходника будет автоматным программированием, людям не придет в голову, что есть системная инструкция, о которой они не знали или забыли, другие баги...
И еще, при таком концепте Вы вынуждены постоянно следить и обновлять библиотеки всех тех МКшек, которые актуальны или будут развиваться и это тянет за собой шлейф дополнительных пересмотров всего ядра.
Однако конфигуратор выполнен под парадигму - упростить студентам жизнь на 10% и не меняет тотально правила игры подхода в проектировании логики. Мое мнение, что отказ от кодирования с привязкой к языковым методам,именно то, что еще в ожидании, когда все что нужно знать кодеру останется "под капотом" в виде логического ядра, а разработчики будут строить модели своих алгоритмов простыми, немногочисленными инструкциями и их визуальным вводом в общую оркестрацию системы, без заморочек с загрузкой и прошивками, отладками таймингов, поиском библиотек, с визуальной симуляцией кода в работе и т.д. и т.п....
Если бы я решил вести детский робототехнический кружок (мне не нравится слово кружок), я бы так его никогда не назвал, т.к. в названии сидит противоречие будущему и вот почему - Детей нужно сразу погружать в мир взрослой робототехники с реально полезным концептом. Разработка программного обеспечения такого сообщества должна быть интуитивно доступна для генерации исходного кода (оркестрации) и аппаратно модульным, чтоб дети не концентрировали свое внимание на языковых абстракциях и схемотехнике, многие из них чисто физиологически в таком возрасте не могут себя заставить, не то что целеустремленно изучать, они не могут больше 30 минут вообще во что либо осмысленно погружаться, т.к. мозги еще умеют от природы и Лего не лучший пример перехода к реальной робототехнике.
Лего это занимательный игровой конструктор с элементами взрослой игры в программистов и мехатроников. Если здесь есть присутствующие кто после Лего начал изучать реальный R&D, то поймут о чем я говорю.
Мое мнение что процесс разработки будущего, это по большей части продумывание и оптимизация алгоритма мехатроники с минимальной нагрузкой требований к механике. При этом IDE такого концепта должна соответствовать в.с. порогу уровня подростка 10 - 16 лет.
Под паллетайзером в моём комментарии речь именно про самоходные тележки/штабелёры с автоматическим управлением, которые возят и устанавливают паллеты, то есть про тот же класс driverless industrial trucks, на который и ссылается ISO 3691‑4.
Стандарты по роботам (ISO 10218‑2 и ISO/TS 15066) допускают совместную работу человека и робота только при ограничении энергии и силы до уровней, при которых даже контакт не приводит к травме; это реализуемо для лёгких коллаборативных манипуляторов, но никак не для многосоткилограммовой паллеты, особенно на высоте. Поэтому индустриальная практика для таких случаев - либо ограждённые ячейки, либо очень жёстко организованные общие зоны с ограничением скорости, зонами исключения для людей и системой обнаружения персонала, а не «свободное перемещение» в привычном смысле.
В этом контексте мой тезис был не про то, что «стандарты запрещают любую совместную работу», а про то, что конкретная конфигурация, где тяжёлый самоход с паллетой катается по полу буквально в общем проходе, а главным аргументом безопасности служит возможность ручного вмешательства оператора через кнопку - гриб, идёт вразрез как с ISO 3691‑4, так и с общими принципами риск‑ориентированного проектирования систем безопасности.
Вижу что полетаизеры выполняют работу в зонах со свободным перемещением людей, что категорически не допустимо из соображений техники безопасности, как бы разрабы не стучали себя в грудь кулаками, доказывая 100% безопаснось.
возможность ручного вмешательства оператора для устранения возможных неисправностей.
Полетайзер прет на рабочих и в это время оператор в прыжке нажимает на красную кнопку размером с ладонь? Причин запуска самохода может быть масса.
Ок, с этим проехали, для полного обзора линии чисто снования по полу полетайзеров не достаточно, это выглядит как новостная заметка, как это и есть на данном примере. Интересно что происходит когда поддон ( к слову он деревянный сколоченный гвоздями) с молоком на высоте 3 метра был неудачно установлен и произошел его перекос. Как система реагирует на такие ситуации?
В мире есть немало других логистических технологий, начиная от автоматизированных XYZ гантри манипуляторов, до 3D рельсовых матриц хранения в куче с конвейерными треками и для каждого из таких алгоритмов есть экономически обоснованная целесообразность.
Чтоб оценить идею применения С1, в статье недостаточно реальных иллюстраций с зонами, от точки приема до точки выдачи. Можно много рассуждать, но пока все это выглядит очень абстрактно и не факт что экономически логично для клиента.
А я хожу кругами вокруг этих Timekettle W4 Pro с функцией Ai синхронного первеода, с активным шумоподалением и для аудио прослушки. На сегодня они считаютя флагманским по качеству Ai (0,2 с задержка) но честного обзора пока на них нет, возможно из за их стоимости $381 на амазоне
Тема востребована, т.к. направлена на решение вопросов, которые происходят из причин их важности когда идеи нуждаются в прокачке с минимальными затратами и усилиями.О важности MVP в любом стартапе уже давно все сказано, при этом мало кто обсуждает проблемы инициаторов в выборе той или иной среды построения кода, от которого зависит аппаратный дизайн и то, как это легко и доступно увидеть в динамике на этапе идеи с начальными алгоритмами. То о чем здесь пишу, это часть осмысленного и моего проекта создания онлайн лаборатории под свою IDE включая и работу с аппаратной частью и симуляции и много еще всего, что должно работать на всех. Увы я не смогу дальше здесь развивать в подкастах эту тему, т.к. получу бан за промоушинг. Если кому интересно обращайтесь в личке.
У нас несколько другая сфера применения low-code автоматика и робототехника, но подход аналогичный, кубики программистам, их сбор инженерам - архитекторам, на выходе рабочий код управления аппаратным сценарием и аппаратные спецификации всего проекта. Что характерно инструкции для визуального ввода может генерировать обученная модель ИИ, таким образом, что инженеру архитектору достаточно на вербальном уровне поставить задачу (запустить моторо на 10с и остановить, или запустить до момента триггерного срабатывания по значению со стороны датчика положения каретки и т.д.)
К разработке программного ядра подход был на построение интерпретаторов команд бинарной логики, применяемых в системах автоматизированного логического управления.
Вообще-то правильным и логичным тоном в любой разработке считается применение встроенного в стенд такого источника питания, как и другой аппаратной части в виде уже существующих готовых модулей с требуемыми функциями и параметрами, которые в дальнейшем могут стать частью прототипа (репликация или как есть), при этом сегодня выбор таких готовых и выставленных на поток, как источников с в.у. характеристиками, так и других модулей, вполне позволяют вести их подбор в качестве универсальных компонентов к той архитектуре устройств, которые Вы разрабатываете сегодня или с идеями на завтра. Такой подход избавит Вас от дальнейших дополнительных затрат в создании прототипов или промышленных образцов.
UX/UI - в свое время это для успеха был кусок работы чуть ли не самым главным в Data Sciense. Помню момент, когда клиенты просто визжали от удовольствия, когда в качестве интерфейса получали свой рабочий кабинет с видами столов и ящиками в которых они любили рыться, что-то находить, далее размещать в отдельные разноцветные папки и передавать их содержимое своим сотрудникам, те, в сою очередь принимали содержимое адресных папок к дальнейшим задачам, которые соответствовали их должности и инструкциям и т.д. и т.п. Ошибки исключались, т.к. в алгоритме были заложены запреты на ошибочные (человеческий фактор или нарушение последовательностей инструкций).
Сейчас передо мной стоит более сложная задача - UX/UI IDE разработчика автоматики и робототехники где на ПК возлагаются задачи не только автоматизации процесса генерации исходного кода логического управления, но и функции логического контроллера под внешний I/O аппаратный интерфейс и здесь мне не совсем понятно, что в таком случае должен представлять из себя такой интерфейс(ы). Когда это кнопки с памятью вводимых состояний, дисплей часов для выставления там таймингов, селекторные кнопки для указания номеров USB портов и т.д. и т.п....
А еще практикуется такая фишка среди фрилансеров и всех их подопечных, когда они по договоренности с клиентами - крупными фирмами, демонстрируют другим потенциальным заказчикам "свои производственные площадки" которые по факту не являются ихними. Водят по цехам, IT отделам гостей как по зоопарку.
Почему бы и нет, спросите его, если это просто любопытство, а интерес к стороннему опыту все же продуктивней иметь из первоисточников, впрочем гигачат на данный момент дает вполне адекватное описание платформы и ее применение. :-
LV позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС, в условиях встраиваемых решений, промышленных контроллеров или систем реального времени. Это можно рассматривать как специализированную ОС-подобную среду, полностью разработанную в визуальной среде.
Не полный перечень возможностей:
Запуск кода на RT-контроллерах с детерминированным исполнением;
Управление потоками, приоритетами задач, прерываниями, синхронизацией и расписанием - то, что выполняет ядро RTOS;
Проектирование логического уровня "ядра" на уровне FPGA - реализация логики взаимодействия между устройствами, шин, интерфейсов;
Разработка приложений с параллельными вычислениями, распределенной логикой и управлением событиями - по сути, имитация ядра ОС на прикладном уровне;
Управление ресурсами, вводом/выводом, коммуникациями (Modbus, TCP/IP, CAN), памятью и задачами.
Вы можете построить систему, где LabVIEW:
Управляет всеми задачами (как диспетчер процессов).
Имеет цикл реального времени с высоким приоритетом (как планировщик).
Реализует драйверы устройств (через FPGA или I/O Nodes).
Управляет прерываниями, вводом-выводом и хранением данных (как ядро).
Работает автономно на хардваре без традиционной ОС.
Важно понимать, что LabVIEW не создает ОС в классическом смысле, но позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС.
здесь требуется конкретика, что проверять со стороны USB GPIO? Выше по ветке я дал описание решения которое применяется в программном контроллере, детали проекта обсуждаются здесь. Если у Вас возникнет желание выпустить авторскую публикацию на хабре с описанием платформы, окажу всяческое содействие. Я не писатель.
LabView это не ради "эмуляции ОС", а ради сокращения цикла "идея - исполнение" при разработке автономных логических систем.
Так что речь не про «берите любую IDE», а про осознанный выбор среды, в которой логика описывается так же наглядно, как монтируется схема — и может быть сразу проверена на железе через стандартный USB GPIO.
Впрочем при желании на LV можно и OC создать, для чего, это уже другой вопрос.
пришел не внезапно, а более чем 7 лет по озвученной Вами причине с уходом от проприетарности железа с его содержимым и того букета плюшек который он за собой тянет с клиента. Тема тянет не на одну статью, идея не из лучших отвлекать здесь кого либо на то, что здесь не предусмотрено к обсуждению. На данный момент это коробочное решение со всеми сопутствующими атрибутами и своим сообществом. Если интересно могу скинуть в личке.
Берите LabView, на нем можно делать всё.
Любопытно узнать, возможна ли в QMP реализации или моделирования реального логического контроллера, исполняющего логику в потоке данных или по триггерам/флагам, как это делается в автоматных логических контроллерах? Насколько мне известно среда не дает таких средств разработки.