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

Вид для печати

Показывать 40 сообщений этой темы на одной странице

15.03.2017, 09:57
starmos

Цитата:

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

Файл прошивки для ПР200 занимает 156 КиБ

Я утверждал, что "добавить в ПР поддержку заливки написанных на C функций непросто". Возражения есть? Есть хотя бы пример "вон, у таких-то контроллеров легко совмещаются FBD и C программирование"?

Раз у них есть в ОЛ графический редактор, то они в итоге должны генерировать то, что в схемотехнических САПР называется netlist - список цепей, который описывает какая цепь от какого вывода и к какому идет. Имена выводов известны, какие из них входы, какие выходы - тоже и все это в списке цепей. Макросы уже есть - на одном уровне иерархии вы видите макросы с входами/выходами, а глубже - содержимое макроса, при этом видите те же всходы/выходы. И в итоге все это транслируется в машинные коды. Так в чем проблема обозвать макрос как "написанный на С" и откомпилировать его отдельно, а редактор связей свяжет его по именам переменных (входов/выходов)? Это все уже делается сейчас, только макросы (подпрограммы, модули) сейчас представляются в виде схемы, а не текста. Это просто вы так видите программу в процессе разработки, а на самом деле она в итоге однородна, хоть на чем макросы пиши.
15.03.2017, 10:08
capzap

Цитата:

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

Группе выдавалось задание, они писали программу, прошивали в плату, я по индикаторам и кнопкам принимал итоги. Т.е. весь цикл разработки софта люди проходили на практике.

да здесь на форуме каждую сессию обращаются студенты за помощью в написании программ, им только остается залить готовый проект в контроллер, не кажется Вам что это ложное ощущение что есть практика у всех студентов?
Говорить о поголовном знании Си людьми приходящими в промавтоматику совершенно не стоит, ни о каком возрастании в разы потребления продукции оснащенной макросами на ЯВУ не произойдет, кто умеет пользоваться тот будет, кто нет тот и ни разу не откроет вкладку с такими макросами. Появление текстового языка в ОЛ сведется к дублированию элементов графического языка, стоит только надеятся что этих элементов будет гораздо больше чем сейчас
15.03.2017, 10:17
Владимир Ситников

Цитата:

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

Так в чем проблема обозвать макрос как "написанный на С" и откомпилировать его отдельно, а редактор связей свяжет его по именам переменных (входов/выходов)?

Блин. Такое ощущение, что вы вообще не сталкивались с разработкой компилятора.

Приведу пример: сложно будет поддержать этот "написанный на C" в режиме "симуляции".
Допустим, с помощью лома получилось из C текста получить бинарный код. Внимание, вопрос: как тестировать этот макрос? Как тестировать программу, использующую этот макрос?
Не забываем, что online режима у ПР нет, т.е. возможности "залить в ПР" для теста тоже нет.

Но и сама задача "скомпилировать" непростая. Разрабатывать свой C-компилятор это неблагодарное дело, а прикручивать сторонние непросто.
15.03.2017, 11:01
starmos

Цитата:

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

Блин. Такое ощущение, что вы вообще не сталкивались с разработкой компилятора.
Внимание, вопрос: как тестировать этот макрос? Как тестировать программу, использующую этот макрос?
Но и сама задача "скомпилировать" непростая. Разрабатывать свой C-компилятор это неблагодарное дело, а прикручивать сторонние непросто.

Вы никогда не сталкивались с системами схемотехнического моделирования, Proteus то же? Нарисованная схема моделируется в "реальном" времени, при этом модели могут быть макро (содержать в себе тоже схему) или выполненными в текстовом виде, а микроконтроллер на схеме может моделироваться с учетом его программы, написанной на С. Как они это делают - для меня тоже загадка, но сам факт несомненен. Но такого даже и не надо вовсе.
"Прикрутить" к среде разработки тот или иной компилятор - обычное дело, например софт для микроконтроллеров Atmel можно разрабатывать на С с помощью нескольких компиляторов, это вообще обычно для микроконтроллеров, а что и как компилировать - задается в командных файлах. Сперва видится проход компилятора из схемы в C, макросы на С - пропускаются, а затем проход компилятора С уже полностью. Как вариант.
15.03.2017, 11:08
Eugene.A

Почему бы сишникам просто не использовать ПЛК, программируемые на С, и не лезть со свиным рылом в калашный ряд? Их ведь есть! Если тренд в программировании движется к графическим средам программирования во всех отраслях, попытки развернуть его обратно тщетны. Одна Rational Rose чего стоит - любо дорого - те же функциональные блоки, только в профиль.
Самый ценный в наше время ресурс - интеллектуальный труд. Человеко-час стоит дорого. И если разработка с отладкой ПИД-регулятора с автонастройкой + Modbus для ПР на С займёт месяц - нафига это кому нужно? Это ведь обойдётся дороже любого контроллера, для которого соответствующий функциональный блок просто есть в библиотеке.
Конечно, если вы собираетесь сделать 100500 контроллеров с этим ПИД-регулятором, можно и потрахаться с дешёвым ПР, и написать алгоритм хоть в машинных кодах. Сэкономите на железе, а стоимость разработки размажется тонким слоем на всю партию. Но много ли здесь таких разработчиков? Да и решаются такие задачи совсем по другому, железо используется заказное, вплоть до чипов и дисплеев, со всякими картинками в виде снежинок, краников, батарей отопления и насосов. Получается в итоге какой-нибудь ECL-310, E8, RVD. Никто для таких партий не использует свободно программируемые ПЛК и ПР.
15.03.2017, 11:48
starmos

Цитата:

Сообщение от Eugene.A

Почему бы сишникам просто не использовать ПЛК, программируемые на С, ...

Наверное потому что я в итоге так и не понял - в чем проблема ДОПОЛНИТЬ ОЛ новой возможностью? Вот даже в ОВЕН обещали подумать. Все эти ваши графические языки прекрасны, пока у вас есть функциональный блок, но если его нет, то вы ни за месяц программу не напишете, ни за сколько. А если он есть, но чуть-чуть не подходит, то вы потратите тот же месяц, но не на то чтобы сделать хороший алгоритм, а на то, чтобы приколхозить кривую заплатку для связи этого ФБ с вашей программой. даже если писать чисто на С - ничто не мешает иметь набор отлаженных модулей и использовать их в проектах. Причем это уже сейчас так - все эти прямоугольники, которые вы называете ФБ - существуют только на экране, а в реальности - это те же подпрограммы на С.
15.03.2017, 12:16
Eugene.A

Цитата:

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

в чем проблема ДОПОЛНИТЬ ОЛ новой возможностью?

В том же, что и приколхозить лифт в хрущовку. То, что не предусматривалось при проектировании, приколхозить впоследствии либо невозможно, либо крайне сложно. В итоге можно получить мутанта, в котором жизнь едва теплится, и который глючит при каждом чихе. И всё это ради каких-то хотелок. А если нет нужного функционального блока и вы не можете решить задачу имеющимися средствами, значит, вы либо плохо владеете языком, либо изначально неверно выбрали средства.
15.03.2017, 17:15
AI!

хоть меня в прошлый раз и закидали камнями,
но я всё же думаю, что язык Fort лучше всего подходит для ПР, у ПР сейчас почти такая же логика внутри, только без ветвлений, и код "пишется" не буковками, а схемой, а порядок исполнения - связями.

ИМХО именно развитие в этом направлении поможет победить одну из проблем обратных связей - если макросы оформить в виде процедур языка Fort, тогда работа макроса никогда не нарушится вдруг появившейся внутри макроса этой самой связи...

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

PS жду очередную порцию камней... яиц.... помидоров....
15.03.2017, 17:17
Владимир Ситников

Для полноты картины тут нужен комментарий Максима:

Цитата:

Сообщение от Евстигнеев Максим, апрель 2016

...тема будет закрыта. Очень много флюда и оскорблений... команда OWEN Logic сейчас уделяет бОльшую часть времени на реструктуризацию существующего продукта...

Ещё раз подтвердилось, что связка ПР-ОЛ по идеологическим причинам должна быть как электромагнитное реле и ни граммом лучше.
Очень точно ситуацию передаёт фраза "не жили хорошо, нечего и начинать".
Верхи не хотят, низы ничего дальше схем не понимают и боятся.

Флаг в руки командам ОЛ-ПР, создавшим столь высококлассный продукт. Ну и специальный флаг в руки "электронщикам", чтобы с тем же рвением накладывали вето на добавление в ПР-ОЛ любой функции, которая испортит гордое название Реле.
15.03.2017, 17:27
игорь68

Цитата Сообщение от starmos Посмотреть сообщение
в чем проблема ДОПОЛНИТЬ ОЛ новой возможностью?
Да в том что нужна стабильная рабочая версия без глюков и косяков. Откройте немецкий софт пятилетней давности и откройте версию за 2016 год. Удивитесь что нечего не поменялось только добавились новые ФБ. А все остальное как было так и есть . Сменили железо вот новые ФБ и новые функции (сеть модем и тд и тп). Больше нечего не меняют и не добавляют. У овен такая же история поменяли железо. Добавили "плюшкию" . Все косяки и баги уберите и достаточно. Мы же не заводи в гараже 250 тонный Белаз для поездки в магазин за булкой хлеба. И не грузим в Акушку 4 стиральных машинки и два холодильника. Каждому продукту свое применение.
Правильно сказали выше если у вас нет нужного ФБ под ваш проект то просто выбрали не тот продукт.
15.03.2017, 17:31
Владимир Ситников

Цитата:

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

Мы же не заводи в гараже 250 тонный Белаз для поездки в магазин за булкой хлеба.

А теперь посмотрите на процессор ПР200 и подумайте над своими словами.
Как раз процессор в ПР200 это и есть тот самый БелАЗ, на котором возят булку хлеба (ОЛ).
15.03.2017, 17:33
Владимир Ситников

Цитата:

Сообщение от AI!

Идею вижу в следующем - схема транслируется в команды языка

Это обсуждали много раз (называется словом p-code).
Такое направление принято (и "электронщиками" и ОВЕНом) бесполезным, противоречащим концепции Реле и не имеющим смысла.
15.03.2017, 18:36
Vyachep

По аппаратной части ПР200 тянет на что-то типа ПЛК-лайт.
В Зелио "всего лишь" Atmega128.
15.03.2017, 18:54
IVM

В цифровой схемотехнике есть такое понятие - гонки фронтов. Интересно как в ОЛ решают эту проблему если схема получается большая и присутствуют обратные связи.
15.03.2017, 18:56
Владимир Ситников

Цитата:

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

В цифровой схемотехнике есть такое понятие - гонки фронтов. Интересно как в ОЛ решают эту проблему если схема получается большая и присутствуют обратные связи.

Если схема большая, значит просто неверно выбран инструмент -- ОЛ-ПР )
15.03.2017, 19:07
IVM

Вложений: 1

И еще один вопрос. Почему в ОЛ нет языка LD ? Это тот самый язык, на котором прекрасно описываются релейные-контактно схемы (РКС). РКС понятны любоиу электрику. Это первое и самое простое, что надо было реализовать в ПР. LD реализован в ПР всех известных производителей.
15.03.2017, 19:15
IVM

Цитата:

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

Если схема большая, значит просто неверно выбран инструмент -- ОЛ-ПР )

Намекаете, что этот вопрос никак не решен ? Тогда это большая печаль.
15.03.2017, 19:23
Владимир Ситников

Цитата:

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

РКС понятны любоиу электрику

Во-первых, ОЛ делался для "электронщиков", а не для электриков.
Во-вторых, всё равно на LD никто не пишет (ведь, его в ОЛ нет :D )
15.03.2017, 19:26
Владимир Ситников

Цитата:

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

Намекаете, что этот вопрос никак не решен ? Тогда это большая печаль.

Намекаю на то, что
1) Если большой проект и выбран инструмент ОЛ-ПР, то выбор инструмента неверен. Именно этот аргумент много раз упоминали выше
2) Вопрос решён. У элементов ОЛ схемы (у блоков и "линий задержки") можно явно указывать порядок выполнения. Разумеется, все элементы выполняются строго последовательно и никакие два элемента схемы ОЛ одновременно не выполняются.
15.03.2017, 19:27
capzap

Цитата:

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

Во-первых, ОЛ делался для "электронщиков", а не для электриков.
Во-вторых, всё равно на LD никто не пишет (ведь, его в ОЛ нет :D )

а чем сишники будут лучше, со своими for( ; ; )
15.03.2017, 19:36
smk1635

Цитата:

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

Во-первых, ОЛ делался для "электронщиков", а не для электриков.
Во-вторых, всё равно на LD никто не пишет (ведь, его в ОЛ нет :D )

Для электронщиков - это ПЛК.

А главное назначение ПР - замена релейки. Так что LD как раз очень в тему был.

А почему его нет, ну так это вопрос к разработчикам.
15.03.2017, 20:00
rovki

Цитата:

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

Если схема большая, значит просто неверно выбран инструмент -- ОЛ-ПР )

Ответ не правильный.При наличии макросов остается хорошая читаемость проекта с чилом элементов и ФБ более 100.Любым инструментом нужно хорошо владеть ,а это приходит с опытом ,а не бесконечной говорильней .
Для исключения гонок и наоборот для их пременения (в сдвигающих регистрах ,стеках) используются явные связи.
15.03.2017, 20:03
rovki

Цитата:

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

А главное назначение ПР - замена релейки. .

Неужели я мало областей применеия привел с примерами ПР+ОЛ,что бы делать такие заключения ...
15.03.2017, 20:09
rovki

Цитата:

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

Во-первых, ОЛ делался для "электронщиков", а не для электриков.
Во-вторых, всё равно на LD никто не пишет (ведь, его в ОЛ нет :D )

Не знаю как сейчас ,но ранее по специальности было ,например у меня (специальность 0608 -"Электронно-вычислительные машины, комплексы, системы и сети") -инженер электрик..
17.03.2017, 06:32
anthrwpos

Цитата:

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

Во-первых, ОЛ делался для "электронщиков", а не для электриков.
Во-вторых, всё равно на LD никто не пишет (ведь, его в ОЛ нет :D )

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

Стоит всерьез задуматься, для чего-же на самом деле предназначены эти приборы, либо для чего их применяют в большинстве случаев и сделать упор на поддержку их реального применения.
Сейчас я так подозреваю, ПР занимает нишу бюджетных ПЛК, где они замечательно смотрятся. Возможно серьезные улучшения с привлечением финансов не имеют смысла, ибо ударят в конечном итоге по цене и прибор вылетит из бюджетного сегмента.
17.03.2017, 08:17
ASo

Цитата:

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

Не знаю как сейчас ,но ранее по специальности было ,например у меня (специальность 0608 -"Электронно-вычислительные машины, комплексы, системы и сети") -инженер электрик..

У меня тот же номер (по старому классификатору, потом перешли на 5-ти значную нумерацию), но специальность - инженер-системотехник.

Цитата:

Сообщение от Адрей

В паскале много букв, а на си одни скобки что гораздо удобней и приятней писать программу по скорости. Отличий Си от паскаля практически нет. Язык С актуальней тем более все программы сред микроконтроллеров на ассемблере и на С с кучей библиотек для STM32.

Давным-давно один мой знакомый профессиональный программист сказал следующее. "На Паскале пожно писать откинувшись в кресле одной левой. С, если писать на нем в стиле С, а не Паскаля, заставляет всегда быть в тонусе" И я с ним согласен.
17.03.2017, 10:11
starmos

Цитата:

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

У меня тот же номер (по старому классификатору, потом перешли на 5-ти значную нумерацию), но специальность - инженер-системотехник.

Давным-давно один мой знакомый профессиональный программист сказал следующее. "На Паскале пожно писать откинувшись в кресле одной левой. С, если писать на нем в стиле С, а не Паскаля, заставляет всегда быть в тонусе" И я с ним согласен.

Я начинал программировать на Паскале, потом переключился на С, т.к. он больше распространен для микроконтроллеров. Не помню никаких проблем с освоением или размещением тела в кресле. На самом деле существует некий алгоритм программы, который более или менее удобно реализовать на том или ином языке. В этом вопросе Паскаль и С практически не отличаются, только синтаксисом, главным образом. Причем даже тот факт что С вроде имеет больше возможностей по работе с "железом", не так очевиден, на фоне того, что например язык VHDL, применяемый для программирования ПЛИС по синтаксису ближе к Паскалю (правда есть подобный язык Verilog - этот ближе к С). Как вам кстати VHDL? Тоже вполне себе стандарт, предназначен для описания аппаратуры - необязательно именно С.
17.03.2017, 10:26
Владимир Ситников

Цитата:

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

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

Инженерный образец ПР200 -- конец декабря 2014: http://www.owen.ru/forum/showthread....l=1#post157505
Тогда же и очередные обсуждения о необходимости online режима:

Цитата:

Сообщение от Алексей Геннадьевич

Своё мнение уже озвучивал. 40-50 В/В. Больше на ОЛ не потяну, нужно программу в динамике видеть.

Воз, очевидно, никуда не ездил.

Раньше (с апреля 2016) я предлагал возможности "автоматического тестирования программ" и ST через интеграцию ОЛ со сторонними программами (эта тема, и смежная про "экспорт-импорт самих ОЛ программ в машиночитаемом виде").
Но сейчас стало видно, что "электронщики" протестуют, а верхи либо не понимают, либо осознанно игнорируют.

Я теперь тоже буду поддерживать тех, кто говорит, что развитие ОЛ вредно. Как-никак, есть шанс испортить шикарный и идеальный почти во всех отношениях софт.

Цитата:

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

"Не жили хорошо, нечего и начинать"...
Флаг в руки командам ОЛ-ПР, создавшим столь высококлассный продукт
17.03.2017, 10:29
Василий Кашуба

Цитата:

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

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

Для этого нужно найти первую версию ОЛ и посмотреть её возможности. Потом у пользователей появились свои хотелки, которые разработчики стали выполнять, ну и как говорится в поговорке, "Аппетит приходит во время еды", дальше больше, то дайте аналоговые входы, то дайте макросы, теперь дайте другие языки программирования.
17.03.2017, 10:47
Сергей0308

Раньше помимо ОЛ была облегчённая версия программы, для составления самых простых алгоритмов, вся программа словами описывалась, вот это жесть была, но я успел и на ней несколько программ сделать, короче кто хочет программу буквами составлять эту программу воскресить, сразу все разговоры стихнут!
17.03.2017, 10:55
rovki

Цитата:

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

Я теперь тоже буду поддерживать тех, кто говорит, что развитие ОЛ вредно. Как-никак, есть шанс испортить шикарный и идеальный почти во всех отношениях софт.

Развитие аля Ситников точно вредно .
А вот мое предложение по существу ,в конве развития - неоходимо добавить в настройках прибота ,режим работы ЗАГРУЗКА (там где мастер,слейв,загрузка).Это даст возможность удаленной(езернет,вайфай и RS485) загрузки проекта в ПР200 по одному из выбранных слотов ,помимо юсби .Для этого нужно поднять загрузку по выбранному уарту .Удаленная загрузка это то что очень нехватает пользователям ,что сократит затраты на поездки и уменьшит время отладки ,доработки,замена на новое пр200 при выходе из строя .:rolleyes: С ПР114 такая задача решалась переключением тумблера ...
17.03.2017, 11:00
Владимир Ситников

Цитата:

Сообщение от Василий Кашуба

Для этого нужно найти первую версию ОЛ и посмотреть её возможности.

Первая версия ОЛ с поддержкой ПР200 ничем не отличается от современной. Вот где реальная стабильность!
17.03.2017, 11:01
rovki

Речь о пр110 и первой ОЛ ,а перед ней изилоджик
17.03.2017, 11:04
Владимир Ситников

Цитата:

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

Речь о пр110 и первой ОЛ ,а перед ней изилоджик

А какого лешего сравнивать самую первую версию ОЛ и связку ОЛ-ПР200?

Есть ПР200. Под него дорабатывали ОЛ. Получилась связка ОЛ-ПР200.
Эта связка уже в неизменном виде несколько лет.
Ошибки исправляют, новых не добавляют. Лепота!

И правильно: нечего новые возможности добавлять. От них только нестабильность повышается.
17.03.2017, 11:09
rovki

Говорить про нестабильность при опыте использования ОЛиПР =0 аморально ;)Консерваторский подход в промышленности ни есть зло .Наш путь ЭВОЛЮЦИЯ ,а не Революция :D
17.03.2017, 11:14
Василий Кашуба

Цитата:

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

А какого лешего сравнивать самую первую версию ОЛ и связку ОЛ-ПР200?

Есть ПР200. Под него дорабатывали ОЛ. Получилась связка ОЛ-ПР200.
Эта связка уже в неизменном виде несколько лет.
Ошибки исправляют, новых не добавляют. Лепота!

И правильно: нечего новые возможности добавлять. От них только нестабильность повышается.

Приведу полную цитату от anthrwpos

Цитата:

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

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

Почему тогда, в то иремя релейщики не набежали? Если б набежали, сейчас был бы язык IL.
17.03.2017, 11:18
Владимир Ситников

Цитата:

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

Говорить про нестабильность при опыте использования ОЛиПР =0 аморально ;)

Именно. Выслушивать слова "сделайте же Си" от тех, кто ОЛ не запускал действительно печально.

Цитата:

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

Консерваторный подход в промышленности ни есть зло .Наш путь ЭВОЛЮЦИЯ ,а не Революция :D

Очень верно. Вот есть рабочая связка ПР200-ОЛ и не нужно её трогать. Ну, разве что добавить поддержку модулей ПР-М.
А все остальные изменения ОЛ и прошивки ПР это как журавль в мышеловке. Кому он нужен? Правильно, никому.

Если нужно что-то новое -- пущай делают ПР100500, но уж 200-ую не трогают.
17.03.2017, 11:48
rovki

Цитата:

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

Если нужно что-то новое -- пущай делают ПР100500, но уж 200-ую не трогают.

Согласен ,только за счет страждущих ;) - двое ,трое скинутся :p
17.03.2017, 11:51
Владимир Ситников

Цитата:

Сообщение от Василий Кашуба

Цитата:

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

А какого лешего сравнивать самую первую версию ОЛ и связку ОЛ-ПР200?

Приведу полную цитату от anthrwpos

Мощность ПР110 и ПР114 гораздо меньше, чем мощность ПР200. Я не предлагал "программировать ПР110 на ST". И anthrwpos не предлагал.

Поэтому я реально не понимаю зачем заводить разговор "в ПР110 и первой версии ОЛ вообще макросов не было".
Текущая тема относится к ПР200, и смотреть на самую первую версию ОЛ вообще нелогично.

А вот трезво оценить как именно по факту используется ПР200 anthrwpos предлагал:

Цитата:

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

для чего их применяют в большинстве случаев и сделать упор на поддержку их реального применения

Очевидно, что под словами "их" имелся ввиду современный прибор ПР200, а не древние и более слабые ПР110.

Цитата:

Сообщение от Василий Кашуба

Почему тогда релейщики не набежали?

Так они набежали!
И схемотехники, и "электронщики-художники", и много кто ещё. Все как один заявили, что всё в ОЛ хорошо и ничего менять не нужно.

Цитата:

Сообщение от Василий Кашуба

Если б набежали, сейчас был бы язык IL.

Действительно считаете, что много кто будет составлять программы на IL при работающем FBD?
По-моему, на IL пишут в двух случаях:
1) Безысходность (если другого языка нет)
2) А, нет. Только 1ый вариант

Я, конечно, в текущей теме (что год назад, что сейчас) и занимался только тем, что предлагал добавить IL в ОЛ. Но план был в том, чтобы человеку не приходилось работать с IL, а сам IL использовался как промежуточный формат программ между ОЛ и другими программами.

AI! а эту же тему высказался:

Цитата:

Сообщение от AI!

я всё же думаю, что язык Fort лучше всего подходит для ПР, у ПР сейчас почти такая же логика внутри, только без ветвлений, и код "пишется" не буковками, а схемой, а порядок исполнения - связями.
ИМХО именно развитие в этом направлении поможет ...

Смысл тот же, с отличием в том, что Fort не относится к 61131.
17.03.2017, 11:52
capzap

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

Показывать 40 сообщений этой темы на одной странице

Текущее время: 08:55. Часовой пояс GMT +3.