Возможность программирования на более низком, чем ОЛ схемы уровне

[Владимир Ситников]

Все, ВСЕ программисты, пришедшие не из отрасли, включая Ситникова, наступали на эти грабли.

А вот это звучит как необоснованные инсинуации. О каком-таком наступлении речь?

Но вопрос правда интересный, и варианты реализации (с возможностями реализации) мы обязательно обсудим.

Обсудите вопрос написания макросов на C и кросс-компиляцией под конкретную версию ПР?

Мало того, что "не взлетит" (например, будет тяжело скрестить С блок с симуляцией), так на рынке уже есть подобный опыт. Есть славные приборы МЗТА, у которых среда программирования это FBD, и каждый может дописать ФБ на языке C.
При этом, на форуме там ни единого обсуждения на этот счёт, значит на C эти блоки никому не впились.

[rovki]

значит на C эти блоки никому не впились[/B].

Вот тут соглашусь ,реле так реле ,а для остального есть ардуино и ПЛК И значит и времени тратить на это не зачем ,есть уже озвученные хотелки ,которые прошли вопрос согласования ....

[capzap]

очень сильно сомневаюсь, что те кто пишет на Си не смогут грамотно писать в графических языках, не говоря уже о просто освоить. А если ты х@вый программист, то ни какой супер язык не поможет и когда в среде чего то нет, всегда есть шанс сослаться на это отсутствие, чтоб скрыть свою низкую подготовку

[Eugene.A]

те кто пишет на Си не смогут грамотно писать в графических языках

Ещё раз повторюсь - дело, скорее всего, не в неспособности, а в элементарном нежелании шевельнуть извилинами. Хотя, признаться, я встречал людей, генетически неспособных научиться читать схемы. Даже при их желании и стремлении. Видимо, мозги у них не так устроены. Так ведь и не факт, что они и на текстовых языках смогут чему-нибудь научится программировать.

[anthrwpos]

Вот тут соглашусь ,реле так реле ,а для остального есть ардуино и ПЛК И значит и времени тратить на это не зачем ,есть уже озвученные хотелки ,которые прошли вопрос согласования ....

Вообще нужно сразу понимать, что если у свободно программируемого прибора есть аналоговые входа и/или выхода, то это заведомо ПЛК, а не реле.
И запросы к таким приборам у пользователей будут как к ПЛК
ПР-200 это однозначно ПЛК. Какое из него реле, когда там даже кнопки и дисплей есть?

ЗЫ Был у нас один ардуинщик... Проработал месяца два) На производстве слово ардуино вообще ругательство, ибо там ни гальванразвязок, ни защиты, ничего.

[Eugene.A]

Ну вот есть у Лого Сименс и аналог, и кнопки, и дисплей, но Сименс почему-то позиционирует их как реле...

[starmos]

Ну вот есть у Лого Сименс и аналог, и кнопки, и дисплей, но Сименс почему-то позиционирует их как реле...

Сименс их позиционирует как реле, потому что у них есть возможность программирования с экрана-кнопок. Это дает возможность достать прибор из коробки и прямо на объекте наколхозить систему управления, например оперативно заменив участок релейной схемы, вышедший из строя или нуждающийся в модернизации. Однако эта возможность ограничивает и число блоков, используемых для программирования, и их сложность - используются только относительно простые. А поскольку в итоге сложность программ получается искуственно ограниченной, то ограниченными получаются и вычислительные возможности и в итоге имеем реле, а не ПЛК. Поскольку в случае ПР200 подобного ограничения нет, и более того, ОЛ позволяет уже сейчас создание макросов, то ПР200 - это фактически ПЛК, а не реле, особенно с учетом того, что там стоит достаточно мощный микроконтроллер. Другое дело, что возможность использования ПР200 в настоящее время ограничивается ОЛ, в котором недостаточно гибкий набор блоков, который не позволяет создавать достаточно сложные макросы, точнее сложность есть, но в основном структурно-графическая. Поэтому и возникла просьба - дать возможность написания макросов на С, который имеет развитый набор операторов и функций. С учетом того, что и сам ОЛ и системный софт ПР200 наверняка написаны на С или его клонах - проблема не выглядит особенно трудоемкой. В ОВЕНЕ обещали подумать - что в общем уже хорошо.

[Василий Кашуба]

Сименс их позиционирует как реле, потому что у них есть возможность программирования с экрана-кнопок. Это дает возможность достать прибор из коробки и прямо на объекте наколхозить систему управления, например оперативно заменив участок релейной схемы, вышедший из строя или нуждающийся в модернизации....

Вот уж никогда не возникало даже желание запрограммировать сименс с кнопок.

[Владимир Ситников]

Другое дело, что возможность использования ПР200 в настоящее время ограничивается ОЛ, в котором недостаточно гибкий набор блоков, который не позволяет создавать достаточно сложные макросы, точнее сложность есть, но в основном структурно-графическая.

Да, всё так. Итеративные вычисления, например, в текущем FBD выглядят как сами знаете что.

Поэтому и возникла просьба - дать возможность написания макросов на С, который имеет развитый набор операторов и функций. С учетом того, что и сам ОЛ и системный софт ПР200 наверняка написаны на С или его клонах - проблема не выглядит особенно трудоемкой.

Интеграция 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, то, конечно, соглашусь, что ситуация безнадёжна.

[ASo]

Еще раз повторяю - ЭТО РЕЛЕ!!!
Здесь пытаются сказать - переделайте ПР200 в ПЛК63. А что входы-выходы соизмеримы, экран по знакоместам одинаков, кнопки.... Вперед, только цена в 2 раза меньше ПЛК. А дальше я например потребую "мозги наружу" (онлайн отладка) и много ПЛК-шных финтюклюшек.
Поймите, это другой тип устройства.