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

Ребят, что реально нужно - это ФБ "формула" с проверкой на переполнение (выход "error"), с поддержкой хотябы минимального набора функций.
Будет внутри возможность ветвления (if-then-else, case и т.п) - ещё лучше.
Чем нравится подход "функциональных блоков" и "макросов" - тем, что результат предсказуем, и базовых блоков этих нужно минимум (надёжность). На булевских схемах ничего большего и не нужно.
Чем не нравится то же на целочисленных и флоатах - нарваться на "переполнение" и прочие артефакты этих арифметик - как 2 пальца. Тем более, даже поддержки отрицательных целых нет.
Если уж введены эти типы, то как-то недоделано, без обработки "исключений".
Если "реле", то всё на логике, если арифметика-математика, то она не должна порождать многочисленных граблей и костылей, выливающихся в паутину ФБ и в плохопредсказуемое поведение программы, нарисованной "релейщиками".

Цитата:

---

Сообщение от pop70

Ребят, что реально нужно - это ФБ "формула" с проверкой на переполнение (выход "error"), с поддержкой хотябы минимального набора функций.
Будет внутри возможность ветвления (if-then-else, case и т.п) - ещё лучше.

---

Смотрите:
1) Есть условный rovki, который ставит по 100-1000 ПРок на разнообразные объекты в месяц
2) Этот самый rovki издревле паял микросхемы, и ОЛ как раз похоже на эти самые микросхемы

Теперь приходите вы, или я с предложением "сделать блок-формулу" или "возможность текстового представления блоков".

Надо ли это условному rovki?

Разумеется, нет:
2.1) rovki уже настолько сросся с микросхемами, что новое ему учить смысла нет. Какой смысл-то? Нарисовать 1000 связей? Да не проблема это. Как представил в голове, остаётся только мышкой пощёлкать и всего делов. Вы только представьте сколько можно нащёлкать за час-два-три. А в обычных программах гораздо меньше 1000 связей, поэтому и вопрос "нащёлкать" вообще не стоит.
2.2) Заказчику без разницы сколько занимает написание программы. Если rovki сказал, что нужно 2 дня мышкой щёлкать, то заказчик заплатит за эти 2 дня.
Если rovki сказал, что "для переделки программы нужна неделя", то он и получит эту неделю. Других вариантов-то нет. Да, тут реальный rovki наверняка заметит, что любая переделка его программы занимает не более 5-15 минут, но, во-первых, не каждый так умеет, а во-вторых, не в конкретных цифрах вопрос.
2.3) Этому самому rovki не нужны конкуренты. Если сделают блок-формулу (if, ещё то-нибудь), то часть программ будет создавать гораздо проще. Разумеется, это сразу подрывает незаменимость. Как же так? Раньше можно было показывать "блок вычисления синуса" на весь экран, и заказчик кивал головой "да, много работы".
Ещё сейчас можно написать PID регулятор (на несколько экранов), и заказчик уж точно поймёт, что это немало работы. Если сделать формулы, то как будет? ПИД регулятор в 10 строк? И кому это нужно?
2.4) Условный rovki реально видел развитие ОЛ. Он на своей шкуре увидел, что даже незначительные доработки ОЛ могут приводить к непредсказуемым последствиям. Если грубо, то "при доработке блока сложения перестали работать сетевые переменные" (конкретную проблему я придумал, но смысл примерно такой).
Вы такие: "давайте добавим блок-формулу". Как это видит rovki: "100% из-за этого сломается что-нибудь старое. Нафиг нужно?"
2.5) У условного rovki свои хотелки в отношении ОЛ. Разумеется, они более важны, чем разнообразные текстовые языки.
2.6) Условному rovki ни отладка, ни online режим не нужен. Во-первых, любую программу можно в голове представить и понять как она будет работать, а где сломается. Во-вторых, есть же симуляция. Запустили схему, пощёлкали, всё поняли. В третьих, есть СКАДА системы, куда можно выгружать данные и рисовать графики.

Поэтому этот условный rovki и будет на подобные предложения отвечать, что "вы не умеете готовить схемы", "текстовые программы невозможно читать-писать", "с графическими программами нет абсолютно никаких проблем" и так далее. С их колокольни это действительно так (см 2.1...2.5).


Теперь со стороны ОВЕН. Им-то вообще нужны эти текстовые языки?
Попробуйте догадаться. Сколько ПР в месяц покупаете вы? Сколько ПР в месяц покупают те, кто просят эти самые текстовые языки для ПР? 1? 0.1?

3.1) Кто платит, тот и заказывает музыку. Т.е. либо прямо много реальных потребителей ПР должны просить текстовые языки, либо просто руководитель ПР на своём энтузиазме решит "а давайте попробуем". И кому надо пробовать, если можно не пробовать и получать ту же прибыль?
3.2) Условный rovki может обидеться и сказать "раз вы так, уйду к другим ПР"
3.3) Доработка ОЛ это деньги на разработку, тестирование, документирование и т.п. См. 3.1
3.4) Как в любой доработке, есть риски, что "сделаем одно, сломается другое". Выкатывать обновления ОЛ, которые будут работать неправильно крайне опасно. Ведь несколько таких обновлений и инженеры станут вообще обходить ПР стороной.
3.5) Если сделать редактор типа "блокнот", то будет 100500 дурацких вопросов от пользователей "у меня программа не работает", когда на самом деле просто пропущена точка с запятой или что-нибудь в этом духе. Сделать же нормальный редактор -- непростая задача.
3.6) Может, есть конкуренты? Ну, море конкурентов, у которых есть эти самые текстовые языки программирования ПР, и на которые народ из-за этого переходит толпами? Да нет таких.
3.7) Может, ОВЕНу нужна конкуренция между ПР и ПЛК? Безусловно нужно сделать так, чтобы ПР было сравнимо по возможностям с ПЛК. Чтобы было сложнее продавать ПЛК за 20 т.р., когда то же самое умеет ПР за 5 т.р.

В итоге, спроса на "блок-формулу" нет, и этот самый блок не появится.

Цитата:

---

Сообщение от pop70

Если "реле", то всё на логике, если арифметика-математика, то она не должна порождать многочисленных граблей и костылей, выливающихся в паутину ФБ и в плохопредсказуемое поведение программы, нарисованной "релейщиками".

---

На это тоже есть ответ "ПР это реле, а в реле никогда не было формул". Можно смеяться, можно плакать, но на полном серьёзе так говорят.

Владимир вот вы просите ФБ "Блок-Формулу" . Как она конкретно выглядеть по вашему. Предложите свой вариант. У немецкой 8 есть такой блок Блок аналоговых вычислений рассчитывает значение AQ по уравнению,сформированному из определенных пользователем операндов и операторов. 4 типа действий +: - : *(умножить): /(делить). Но я не вижу где мне его использовать в станции управления насосом. Я просто осушаю резервуар по 4 датчика и сообщаю о поломках через облако на телефон. Приведите конкретный пример где это нужно массово. И я уверен Овен скажет да это нужно и выделит на это ресурсы. Овен запускает второй прибор на базе ПР200 без "кодесисовских " примочек. И я думаю что это не последняя разработка.

Цитата:

---

Сообщение от игорь68

Владимир вот вы просите ФБ "Блок-Формулу" . Как она конкретно выглядеть по вашему. Предоите свой вариант. У немецкой 8 есть такой блок Блок аналоговых вычислений рассчитывает значение AQ по уравнению,сформированному из определенных пользователем операндов и операторов. 4 типа действий +: - : *(умножить): /(делить). Но я не вижу где мне его использовать в станции управления насосом. Я просто осушаю резервуар по 4 датчика и сообщаю о поломках через облако на телефон. Приведите конкретный пример где это нужно массово. И я уверен Овен скажет да это нужно и выделит на это ресурсы. Овен запускает второй прибор на базе ПР200 без "кодесисовских " примочек. И я думаю что это не последняя разработка.

---

Это я прошу :)
Как выглядеть?
Элементарно.
Количество и тип входов, количество и тип выходов.
В теле - скрипт, в котором допускается использовать только константы и входные/выходные переменные. Поддержка мат. Функций, проверка на переполнение при расчёте формул из скрипта и установка "спецвыхода" "OW" в случае обнаружения такового в 1 (для возможности обработки в схеме этих ситуаций).
Возможность примитивного ветвления по условию.

"If i1=1
Then q1:=sqrt(i2^2 +i3^2); q2:=2*sin(i4)
Else if i1=2
Then q1:=sqrt(i2^2-i3^2); q3:=log(i4)/3
Else q1:=1; q2:=0
"
А теперь возьмите и нарисуйте то же самое из ФБ, даже имея ФБ мат. Функций, организуйте проверку переполнения...

Цитата:

---

Сообщение от Владимир Ситников

Смотрите:
1) Есть условный rovki,"...

Теперь со стороны ОВЕН. .

---

...
У вас раз троение личности батенька ...За всех всю решил ..И мания величия, однако .

Цитата:

---

Сообщение от rovki

...
У вас раз троение личности батенька ...За всех всю решил ..И мания величия, однако .

---

rovki, диагнозы ставить не ваш конёк. Если по существу есть что -- не стесняйтесь.

Я давно веду пропаганду, что "Флаг в руки командам ОЛ-ПР, создавшим столь высококлассный продукт", и что "ничего нового добавлять в прошивку ПР не нужно"

Тут появляется pop70 и хочет странного, которое явно идёт в разрез с ПР-ОЛ. Вот я наглядно и объяснил почему от введения блока-формулы / блока-скрипта / блока-текстовой-программы одни только минусы как для ОВЕН, так и для текущих массовых потребителей.

игорь68, раньше я предлагал и ОЛ-формулы, и ОЛ-IL (конкретные варианты обсуждались), но сейчас моё понимание в том, что "связка ПР-ОЛ по идеологическим причинам должна быть как электромагнитное реле и ни граммом лучше"

Цитата:

---

Сообщение от Владимир Ситников

связка ПР-ОЛ по идеологическим причинам должна быть как электромагнитное реле и ни граммом лучше"

---

Как эм реле, нужно убрать аналоговые входы-выходы, убрать все встроенные ФБ, кроме одного элемента ИЛИ-НЕ и "линии задержки" и отключить все макросы.
Один ИЛИ-НЕ и линия задержки позволяет создать все имеющиеся логические элементы, триггеры и счётчики-генераторы-таймеры прямо на холсте проекта. А на "эм реле" большего и не сделать.
Так что, что-то не так с "идеологией". :)
Инты и флоаты, кстати, тоже можно организовать через двоичную "шину данных".
Если постараться - хоть коре i7 нарисовать можно из 1 логического элемента и линии задержки. А потом на нём линукс запустить... Да хоть винду... И запустить ОЛ :)

Цитата:

---

Сообщение от Владимир Ситников

rovki, диагнозы ставить не ваш конёк. Если по существу есть что -- не стесняйтесь.

Я давно веду пропаганду, что "Флаг в руки командам ОЛ-ПР, создавшим столь высококлассный продукт", и что "ничего нового добавлять в прошивку ПР не нужно"

Тут появляется pop70 и хочет странного, которое явно идёт в разрез с ПР-ОЛ. Вот я наглядно и объяснил почему от введения блока-формулы / блока-скрипта / блока-текстовой-программы одни только минусы как для ОВЕН, так и для текущих массовых потребителей.

игорь68, раньше я предлагал и ОЛ-формулы, и ОЛ-IL (конкретные варианты обсуждались), но сейчас моё понимание в том, что "связка ПР-ОЛ по идеологическим причинам должна быть как электромагнитное реле и ни граммом лучше"

---

По существу - пропагандируйте от своего имени ,не преплетая ни меня ни Овен,вас в пресс секретари не нанимали.У кого какие коньки не вам судить .

Цитата:

---

Сообщение от rovki

По существу - пропагандируйте от своего имени ,не преплетая ни меня ни Овен,вас в пресс секретари не нанимали.У кого какие коньки не вам судить .

---

Да ладно Вам. Не обращайте внимания. Владмир просто пытается взять овен "на понял" ;)
Понятно, что некоторые хотелки МОГУТ не вписаться в идеологию ПО, разработанную под "реле с логикой", и потребовать либо заново переосмыслить и переделать ОЛ с нуля, либо костылей, которые не добавят стабильности и "обслуживаемости" самому ОЛ.
Согласен, что промышленную серию просто так не остановишь и не переделаешь безболезненно, что, при смене "идеологии", возрастут затраты на поддержку (и старое тащить, и новое). Как разруливать эту ситуацию - решать производителю и только ему - ему виднее. Просто, не надо за него додумывать, и на основании этих выдумок самим отказываться от функционала, который ПРИНЦИПИАЛЬНО ВОЗМОЖЕН.
Вообще, конечно, развитие мк (микросхем) сейчас дают возможность сближать функциональность контроллеров и простоту программирования ПР, но это требует новых "идеологических решений". Как сможет овен разрулить "новое, сохранив старое" - так и будет.
Наше дело маленькое - просить то, чего "хочется" (формировать спрос) и выбирать тех, чья продукция лучше соответствует хотелкам (выбирать предложения). Не будем формировать спрос мы - производитель сам его сформирует как удобнее ему и предложит "походить по базару".

Цитата:

---

Сообщение от pop70

Это я прошу :)
Как выглядеть?
Элементарно.
Количество и тип входов, количество и тип выходов.
В теле - скрипт, в котором допускается использовать только константы и входные/выходные переменные. Поддержка мат. Функций, проверка на переполнение при расчёте формул из скрипта и установка "спецвыхода" "OW" в случае обнаружения такового в 1 (для возможности обработки в схеме этих ситуаций).
Возможность примитивного ветвления по условию.

"If i1=1
Then q1:=sqrt(i2^2 +i3^2); q2:=2*sin(i4)
Else if i1=2
Then q1:=sqrt(i2^2-i3^2); q3:=log(i4)/3
Else q1:=1; q2:=0
"
А теперь возьмите и нарисуйте то же самое из ФБ, даже имея ФБ мат. Функций, организуйте проверку переполнения...

---

Возможно задам самый глупый вопрос ДЛЯ ЧЕГО ЭТО ВЕТВЛЕНИЕ НУЖНО? Где в контроле датчика уровня резервуара я это буду использовать. Или это ветвление мне нужно для отключения аварийного насоса и подключения резервного. Я тут открыл один станок для производства пластиковых окон одно известной фирмы. Скажем 7
из 10 заводиков с объёмом до 20 окон в смену это заводы этой фирмы.Так внутри стоит зарубежный аналог ПР114( регулирует температуру тена ). Производитель как то смог написать софт для реле без математических блоков. Пока мне удобно делать КНС на ПР я и буду делать. Не будет ПР соберу схему на компараторе и трех четырех микросхемах простой логики и получу такой же блок управления КНС. Что вы будете делать с блоком ветвления я не знаю.