Это для безвыходных "полевых" ситуаций. Когда лого есть, а компьютера нет.Сообщение от Василий Кашуба
Или покурить волшебной травы, тогда воможно, появится желание.
Онлайн-режим - было бы неплохо.
Это для безвыходных "полевых" ситуаций. Когда лого есть, а компьютера нет.
Или покурить волшебной травы, тогда воможно, появится желание.
Онлайн-режим - было бы неплохо.
очень сильно сомневаюсь, что те кто пишет на Си не смогут грамотно писать в графических языках, не говоря уже о просто освоить. А если ты х@вый программист, то ни какой супер язык не поможет и когда в среде чего то нет, всегда есть шанс сослаться на это отсутствие, чтоб скрыть свою низкую подготовку
Ещё раз повторюсь - дело, скорее всего, не в неспособности, а в элементарном нежелании шевельнуть извилинами. Хотя, признаться, я встречал людей, генетически неспособных научиться читать схемы. Даже при их желании и стремлении. Видимо, мозги у них не так устроены. Так ведь и не факт, что они и на текстовых языках смогут чему-нибудь научится программировать.
Ну вот есть у Лого Сименс и аналог, и кнопки, и дисплей, но Сименс почему-то позиционирует их как реле...
Сименс их позиционирует как реле, потому что у них есть возможность программирования с экрана-кнопок. Это дает возможность достать прибор из коробки и прямо на объекте наколхозить систему управления, например оперативно заменив участок релейной схемы, вышедший из строя или нуждающийся в модернизации. Однако эта возможность ограничивает и число блоков, используемых для программирования, и их сложность - используются только относительно простые. А поскольку в итоге сложность программ получается искуственно ограниченной, то ограниченными получаются и вычислительные возможности и в итоге имеем реле, а не ПЛК. Поскольку в случае ПР200 подобного ограничения нет, и более того, ОЛ позволяет уже сейчас создание макросов, то ПР200 - это фактически ПЛК, а не реле, особенно с учетом того, что там стоит достаточно мощный микроконтроллер. Другое дело, что возможность использования ПР200 в настоящее время ограничивается ОЛ, в котором недостаточно гибкий набор блоков, который не позволяет создавать достаточно сложные макросы, точнее сложность есть, но в основном структурно-графическая. Поэтому и возникла просьба - дать возможность написания макросов на С, который имеет развитый набор операторов и функций. С учетом того, что и сам ОЛ и системный софт ПР200 наверняка написаны на С или его клонах - проблема не выглядит особенно трудоемкой. В ОВЕНЕ обещали подумать - что в общем уже хорошо.
Вот уж никогда не возникало даже желание запрограммировать сименс с кнопок.
Да, всё так. Итеративные вычисления, например, в текущем FBD выглядят как сами знаете что.
Интеграция C блоков и ОЛ-ПР это трудоёмкая задача.
Дело в следующем:
1) Само по себе ПР может быть устроено по-разному внутри. Например, ПР200 2017-го года выпуска и ПР2000 2016-го вообще могут иметь внутри разную разводку, разный процессор и т.п.
Для компиляции C кода в пригодный для ПР формат придётся точно знать модель и т.п.
Сейчас эта кухня скрыта внутри ОЛ, а светить её наружу непросто, ведь никто с первого раза не сможет правильно настроить C компилятор, а на второй раз окажется, что льёт программу от старого ПР в новое и беда-печаль.
2) В ПР нет online режима. А в ОЛ есть симуляция. Полагаю, они сделаны вообще независимо друг от друга. Допустим, вы как-то скомпилируете свой блок на C для выполнения в STM32 процессоре внутри ПР. Внимание, вопрос: как этот блок задействовать в симуляции? Компилировать его ещё раз для Intel процессора вашего ноутбука? См. пункт 1. И одного раза-то никто скомпилировать не сможет. Уж два и подавно.
Вспоминаем, что online режима нет, и получается что "при использовании C блоков программу нужно писать вслепую". Кому такое надо? Ни-ко-му.
3) Напомню, что online режима в ОЛ вообще нет. Сам по себе этот факт означает, что для ОВЕН сделать online это трудоёмкая задача.
А скрестить уж C блоки и online режим, значит, архитрудоёмкая.
4) Сам по себе язык С никак не защищает от опечаток, выходов за границы массива и т.п. Эти ошибки встречаются и у зубров, поэтому для массового применения голый C не подходит. Будет слишком много вопросов "у меня ПР зависло" или "у меня ОЛ не открывается", хотя формально дело в кривости C кода. Т.е. нужно как-то на уровне C кода запрещать криворукий код. Это непросто.
5) Возможность программировать ПР на C без ОЛ, скорее, время на ветер. Как-никак, сейчас есть армия ОЛ пользователей, и делать C программирование со своей симуляцией/online не укладывается в понятие "не выглядит особенно трудоемкой"
Вот не знаю хорошо это или плохо. Будут думать над интеграцией С в ПР, зря тратить время на непойми что...
Посмотрим, конечно, что в итоге не получится.
На мой взгляд, совершенно неочевидно как можно скрестить C и ОЛ.
С другой стороны, интеграцию C я никогда и не предлагал. Я предлагал провести интеграцию по p-code (~IL).
Если тов. Филоненко под словами "архитектура ПР совсем другая" имел ввиду то, что ОЛ генерирует бинарный код для STM32, то, конечно, соглашусь, что ситуация безнадёжна.
Вы путаете прошивку контроллера с пользовательской программой.
Доступа к прошивке, где содержится конфигурация портов ввода-вывода, регистров, прерываний и всему прочему вы не получите 100%, ибо если дать юзеру такой доступ, то половина контроллеров будут доведены до состояния при котором он не сможет отвечать на запрос компьютера по USB в течении недели после ввода такой фичи.
То, насколько оно сложно реализуется зависит от используемой модели.
В простейшем случае в прошивке написан набор базовых функций, и пользовательская программа находящаяся на отдельной микросхеме флеш-памяти содержит информацию, какие из них и с какими параметрами нужно вызвать и куда положить результат.
В наиболее вероятном случае во внешней памяти установлен какой нибудь из эмбеддед-линукс и дрова на периферию и пользовательская программа представляет собой каноничную программу под линь.
Возможны и более сложные варианты, в общем, гадать думаю будет излишне.
Не путаю.
32KiB RAM, 128KiB ROM и embedded linux?
Не верю (tm)
А как быть с безэкранными ЛОГО?
Ваши права
