PDA

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



Страницы : [1] 2 3

Владимир Ситников
03.04.2016, 17:30
Сейчас ОЛ предлагает возможность программировать в схемном редакторе.
Да, в некоторых случаях это удобно, но некоторые возможности незаслуженно остаются за кадром.

Например:
1) Блок fSEL. Его наверняка можно без проблем сделать в машинных кодах, а в ОЛ сделать невозможно. Умножение на 0 не всегда возвращает верное значение
2) Условные переходы.
3) online-отладка

Было бы хорошо, если бы можно было записывать блоки на более низкоуровневом языке, чем текущие функции-блоки ОЛ.

melky
03.04.2016, 18:33
Товарищ, ну возьмите себе уже Ардуино или STM и не устраивайте балаган.....

Вы как упертый баран, не можете понять, что все ПР сделаны именно ТАК.
Имею ввиду не только фирмы ОВЕН.

Владимир Ситников
03.04.2016, 18:44
Товарищ, ну возьмите себе уже Ардуино или STM и не устраивайте балаган.....

Для ардуино мозги нужны, а у меня их нет (шутка :D)
Если точнее, то в схемотехнике я не силён, и я готов переплачивать за прибор, в котором схемотехнические вопросы решены.


Вы как упертый баран, не можете понять, что все ПР сделаны именно ТАК.
Имею ввиду не только фирмы ОВЕН.
Поговаривают, что бывают и более худшие ПР.

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

melky
03.04.2016, 18:56
vladimirisitnikov потому, что есть языки МЭК, одни ПР поддерживают только FBD (Овен), другие LD и FBD (Zelio и то, есть варианты только LD)
ПР от ABB только LD. и так далее.

и текстовые варианты по концепции поддерживаться не будут.

Надо, используйте другое оборудование.
p.s. на этом все.

lara197a
03.04.2016, 19:07
Сейчас ОЛ предлагает возможность программировать в схемном редакторе.
Да, в некоторых случаях это удобно, но некоторые возможности незаслуженно остаются за кадром.

Например:
1) Блок fSEL. Его наверняка можно без проблем сделать в машинных кодах, а в ОЛ сделать невозможно. Умножение на 0 не всегда возвращает верное значение
2) Условные переходы.
3) online-отладка

Было бы хорошо, если бы можно было записывать блоки на более низкоуровневом языке, чем текущие функции-блоки ОЛ.

Если этого нет в ОЛ, то не значит что это не возможно.
У многих производителей это реализовано, причем очень круто.
В т.ч. и умножение на 0. Только зачем?
К примеру в ЗВБ (ZWorkbench)

ASo
03.04.2016, 19:28
И, да, пока я не видел аргументов, почему среда разработки для ПР должна быть такой унылой.
Задаю наводящий вопрос.
Почему в основу ST положен Pascal, а не C?
Ответив на него, Вам все станет понятно.

Владимир Ситников
03.04.2016, 19:35
Задаю наводящий вопрос.
Почему в основу ST положен Pascal, а не C?
Ответив на него, Вам все станет понятно.

Куда-то не туда наводите. В ОЛ ни ST ни Pascal ни C нет.

ASo
03.04.2016, 19:44
Естественно, нет.
И ответив на наводящий вопрос, Вы поймете, почему нет.

Владимир Ситников
03.04.2016, 20:05
Совсем нет. С и Pascal были придуманы гораздо раньше.
Намек на это Вам уже давали в соседней теме.
Попробуйте ответить еще раз.
1993 это год публикации первого стандарта 61131.
Разумеется, C и Pascal были раньше.

Честно скажу, без понятия. На Pascal немного сложнее написать программу, которая упадёт по segmentation fault, но и на Pascal/ST указателей ведро целое.

В качестве бредогенератора:
* Язык со словами "program, variable, и т.п." "более понятен релейщику"
* Нет указателей -- значит безопасность
* Проще конструкции -- значит меньше шанс ошибиться
* Хороших компиляторов C не было, а компилятор Pascal был
* Создатель ST нежно любил Pascal/Ada/Cobol

Почти наверняка дело в том, что все в то время языком Ada (https://en.wikipedia.org/wiki/Ada_(programming_language)) болели.

Игорюня
03.04.2016, 20:23
Pascal более удобочитаем, чем Cи.

Владимир Ситников
03.04.2016, 20:24
Pascal более удобочитаем, чем Cи.

И это послужило тому, что ST основан на Pascal?
Вот уж вряд ли.

Где Pascal и где C сейчас.

Игорюня
03.04.2016, 20:26
В те времена его очень плотно учили в институтах.

ASo
03.04.2016, 20:29
Совсем нет.
Сделайте 3-ю и последнюю попытку.
Если не удастся, я объясню.
P.S. Доп намек дал Игорюня.

Владимир Ситников
03.04.2016, 20:43
Structured Text is a very powerful highlevel modern programming language with its roots in Ada, Pascal and “C”

Вот такая фраза копипастой переходит из одной книги в другую.
Получается, что в основу положен и Pascal и C.

Давайте свою теорию.

ASo
03.04.2016, 21:02
Повторяю еще раз. Никогда не приводите цитаты и фамилии "авторитетов". Это не прилично. Приводите свои мысли. Учитесь рассуждать, размышлять.

А теперь по делу.
Один мой знакомый профессиональный программист сказал хорошую фразу. "На Паскале можно писать откинувшись в кресле одной левой. С, если писать на С в стиле С, а не Паскаля, что глупо, заставляет всегда быть в стойке." Я с ним полностью согласен. Так, для справки, я когдато писал и на Паскале (DOS, Win16) и С (DOS, Netware), так что не совсем дилетант.

Системы программирования ПЛК и ПР разрабатываются не для профессиональных программистов (они пишут сами системы, драйвера, обработчики....) а для инженеров-прикладников. Специалистов в конкретной предметной области. И проще научить прикладника какомуто программированию, чем из программиста сделать прикладника. Поэтому вот так.
Поэтому Паскаль в КДС (МЭК ******)
Поэтому ФБД для ПР и КДС - схемотехнику и прочему инженеру, работающему со схемами он ближе.
Поэтому и LD в ПР - он близок специалистам-релейщикам (релейная защита и автоматика и подобные специальности)
Поэтому для них чужд С и все ваши изыски. Поэтому они будут править текст в ручную, а не пользоваться регулярными выражениями при поиске-замене.

Конкретно Вам могу посоветовать написать в ОВЕН с просьбой открыть протокол заливки проги и прошивки в конкретное ПР. Схему ПР. И т.п. Естественно, под договор о нераспространении. И создавайте свою среду. Почему нет? Были (а может и остались) у ОВЕНа ПЛК с линуксом для ОЕМщиков. Но это решается не на форуме.

rovki
03.04.2016, 21:18
Свою среду ,не зная особенностей железа ,не будучи инженером прикладником ???? что то страшное может получится ,да же если реализовать ST ,без фдб на ПР...Че то я сочкую (С)

Владимир Ситников
03.04.2016, 21:32
Один мой знакомый профессиональный программист сказал хорошую фразу.
Я бы сказал, что вы тут сами ссылаетесь "на авторитета", но не суть


"На Паскале можно писать откинувшись в кресле одной левой. С, если писать на С в стиле С, а не Паскаля, что глупо, заставляет всегда быть в стойке." Я с ним полностью согласен. Так, для справки, я когдато писал и на Паскале (DOS, Win16) и С (DOS, Netware), так что не совсем дилетант.

Это вообще-то мутная фраза.

Я не буду защищать C (без проблем могу писать на нём, сильно не люблю этот язык за море "undefined behavior"), но и ST недалеко ушёл.
Например, текущий ST вообще невозможно тестировать. Вернее, можно, но для этого нужно заплатить 1500 евро за их test manager (или как он у КДС называется). Жаба не позволяет.
Каким бы плохим C не был, для программ на C можно написать автотесты, и это будет хоть какая-то опора.

В ST всё пишется на интуитивном уровне, и фактически в голове приходится держать все краевые случаи.
Нет возможности просто взять, и проверить что выдаст код на конкретных входах.

http://mbeddr.com/ делают систему программирования микроконтроллеров на подмножестве C.
И не просто делают, а ей активно пользуются.

Из интересного, у них есть механизмы формальной верификации кода: https://vimeo.com/78422792
Например, указываешь, что "после помещения элемента в стек он должен оказаться непустым", и система сама (без написания тестовых методов) находит случай, когда это правило нарушается (если нарушается).

Это я не к тому, что "надо продвигать C программирование в массы", а к тому, что и на C можно ого-го какую штуку сделать.


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


Поэтому Паскаль в КДС (МЭК ******)
Помесь Ada, Pascal, и С.


Поэтому ФБД для ПР и КДС - схемотехнику и прочему инженеру, работающему со схемами он ближе.
Поэтому и LD в ПР - он близок специалистам-релейщикам (релейная защита и автоматика и подобные специальности)
Разница FBD vs LD это разница школ. В США все запали на LD, у нас на FBD, не более.


Поэтому для них чужд С
Вот неужели y0+(y1-y0)/(x1-x0)*(x-x0) записать в виде блоков проще, чем в виде одного блока и упомянутого текста внутри?
В текстовом виде править гораздо проще: скобку переставил, слагаемые переставил и т.п. В схемном виде менять расстановку скобок это ад.


у ОВЕНа ПЛК с линуксом для ОЕМщиков. Но это решается не на форуме.
Вот специально не хотел linux, т.к. надёжность linux непойми какая. Ну, вернее, надёжность коробочки с linux'ом.

Владимир Ситников
03.04.2016, 21:36
не будучи инженером прикладником ????
Не угадали. У меня специальность "прикладная математика и физика". Диплом не красный, так что всё норм будет.

Алексей Геннадьевич
03.04.2016, 21:37
Давайте обсудим вот это.
Язык ДРАКОН

Владимир Ситников
03.04.2016, 21:41
Давайте обсудим вот это.
Язык ДРАКОН

Вот уж не думал, что вы такое предложите.
На это я пойтить не готов.

Хотя, конечно, может быть более крутой альтернативой какому-нибудь SFC.

игорь68
03.04.2016, 21:44
Ну так пусть купить ОВЕН-КИТ . Урезанная до нельзя ПР-ка. Схемотехнику можно за неделю сделать( если знаешь что за микрушки стоят). Сейчас свободно можно скачать софт для разработки на любом железе. И вперед . Делайте. Принесите в ОВЕН или как ROVKI продавайте сами кто вам запрещает. Только ради бога не лезьте с вашими предложениями в ПР и ОЛ. Вам правильно говорят. ОЛ и ПР созданы друг для друга. Изменение одного приведет к изменению другого.

Алексей Геннадьевич
03.04.2016, 21:51
Не угадали. У меня специальность "прикладная математика и физика". Диплом не красный, так что всё норм будет.
Физмат-это очень хорошо. Но прикладное применение - это другая область.
Это там, где прекрасно выстроенная логическая структура вдребезги разбивается о "гонки".

Вот уж не думал, что вы такое предложите.
На это я пойтить не готов.

Хотя, конечно, может быть более крутой альтернативой какому-нибудь SFC.
Это очень крутая альтернатива. Первоначально разрабатывался для "Бурана". Для нужд инженеров-системотехников.
Я запал, честно.

ASo
03.04.2016, 21:53
Разница FBD vs LD это разница школ. В США все запали на LD, у нас на FBD, не более.Это так.
Но и у нас используют LD - релейщики.

Вот неужели y0+(y1-y0)/(x1-x0)*(x-x0) записать в виде блоков проще, чем в виде одного блока и упомянутого текста внутри?
В текстовом виде править гораздо проще: скобку переставил, слагаемые переставил и т.п. В схемном виде менять расстановку скобок это ад.Для этого используют ST. Просто есть много задач, где FBD удобнее. Просто потому, что в автоматике чаще программа управляется потоком данных, а не команд. Классический пример - работать с таймером удобнее в FBD, не нужен пустой вызов, он подразумевается. В вычисления относительно редки.
Впрочем, есть системы только с ФБД и блоком арифметикололических вычислений.
В моих прогах используются ФБ на разных языках - где какой удобнее.

lara197a
03.04.2016, 21:56
...Разница FBD vs LD это разница школ. В США все запали на LD, у нас на FBD, не более....

Тут скорее дело в целевой аудитории, на которую направлен продукт.
К примеру обсуждал я этот вопрос с разработчиками ЗБВ, так вот исходят, вкладываясь в ФБД,
из того, что большей части юзеров и блоки-то соединить под силу с огромным трудом..
А ST- вообще темный лес.

Владимир Ситников
03.04.2016, 22:09
Это так.
Но и у нас используют LD - релейщики.
Для этого используют ST. Просто есть много задач, где FBD удобнее. Просто потому, что в автоматике чаще программа управляется потоком данных, а не команд. Классический пример - работать с таймером удобнее в FBD, не нужен пустой вызов, он подразумевается. В вычисления относительно редки.
Впрочем, есть системы только с ФБД и блоком арифметикололических вычислений.
В моих прогах используются ФБ на разных языках - где какой удобнее.

Тут со всем согласен.
И, да, я прекрасно понимаю, что основная часть программ для ПР, скорее, будет на FBD/LD.
Но вот небольшой ST блок может оказаться очень кстати (даже совсем-совсем простой ST).

Иногда в ST и таймер хорошо выглядит.
С подачи Егора начал ФБ на месте вызывать:
23603

capzap
04.04.2016, 07:02
И вы считаете, что на безлинуксной весрии ПЛК нет косяков ?
За примерами далеко ходить не надо, если рассматривать ОВЕН. ПЛК100, 150, 154 - помирают АКБ.
ПЛК160 - теряет программу
Модуль баттон приходится ставить, чтобы программа не останавливалась.

и т.д. и т.п.

Там, где есть программа, всегда будут ошибки, ибо программы пишут люди.
Другой вопрос, устраняет ли производитель свои косяки или поднимает правую руку и потом опускает ее со словами "да и Х с ним".

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

дело ведь не в линуксе, а в рантайме и тема про ПР

melky
04.04.2016, 09:27
Про ПР я выше написал, у большинства производителей в ПР либо LD либо FBD или два варианта на выбор. Никакого текстового варианта.
Текстовые варианты типа IL, ST это уже в ПЛК.

Извините, а runtime это не ПО ? да, не линукс, но и в нем могут быть ошибки.

rovki
04.04.2016, 18:20
так так ,зачем меня упомянули в суе :D.про то что свиснут планшет уже обсуждали ,при установке внутрь щита замучаются..

Алексей Геннадьевич
04.04.2016, 18:47
так надо было Анатолия остановить, пока он в каскаду не вложился, теперь то уже поздно
У Анатолия планшет оператор пользует(возможно даже свой;)), и с этим всё ясно.
В вашем случае планшет используется как коммуникационный контроллер, и может быть расположен в месте, где пропажу не сразу заметят.

так так ,зачем меня упомянули в суе :D.
Прости господи нас грешных, не признали тебя в этом облике сразу...:D

установке внутрь щита замучаются..
Что-то вспомнил как на практике на заводе первый раз был. Там у мастера из шкафчика изготовленного из 10мм стали с соответствующим замком (внутренним) бутыль спирта мужики спёрли.

rovki
04.04.2016, 18:52
Мне сверху видно все ,ты так и знай ....(песня):p

Мордорец
04.04.2016, 18:55
Сейчас ОЛ предлагает возможность программировать в схемном редакторе.
Да, в некоторых случаях это удобно, но некоторые возможности незаслуженно остаются за кадром.

Например:
1) Блок fSEL. Его наверняка можно без проблем сделать в машинных кодах, а в ОЛ сделать невозможно. Умножение на 0 не всегда возвращает верное значение
2) Условные переходы.
3) online-отладка

Было бы хорошо, если бы можно было записывать блоки на более низкоуровневом языке, чем текущие функции-блоки ОЛ.
q
1. Почему FSEL невозможно сделать в ОЛ? И Вы сами когда нибудь в машинных кодах работали?
2. Как вы себе представляете условный переход FBD?
3. Подцепите панель и отлаживайте.

ASo
04.04.2016, 19:25
2. Именно ровно так, как он реализован в КДС - через метки. Я использую и в FBD и в CFC.

PSA
21.10.2016, 04:52
Не угадали. У меня специальность "прикладная математика и физика". Диплом не красный, так что всё норм будет.

Здесь Вы не поняли человека. Под прикладником - он имел ввиду реального инженера с опытом работы на действующем оборудовании.
Только человек знакомый с проблематикой промышленного производства (полевой уровень), с правилами безопасного ведения работ и т.п., может корректно написать программное для ПЛК, и всего что с этим связано!
Дилетанты от "МГУ" и прочих Вузов - могут лишь выступать консультантами, или выполнять часть работ по конкретным тех.заданиям. Не дай боже, они станут писать программное для ПЛК, и всего что с ними связано!
Оторванные руки, упавшие грузоподъёмные, взрывы на предприятиях и смертельные случаи нам гарантированны. А простые инженера, не являются гениями языков программирования высокого уровня. Вот для них и существуют такие языки, что так не нравятся истинным программистам. Ближе к народу надо быть!

melky
21.10.2016, 09:05
а я лично за, если бы можно было писать FBD на C# например, раз ОЛ на нем писан.
Я не говорю про основную программу, а именно блоки для библиотеки элементов.
Ведь внутри там все так же, есть переменные внутренние для его работы, есть внешние. да и внутри все одинаково. И он и в африке И и т.д.

01ZZZ
28.11.2016, 12:47
А я согласен с автором темы.
Тот же мультиплексор вещественных чисел - четыре строчек кода на си.
В плане программных блоков мне нравится набор у сегнетика. У ПР200 легче с экраном работать, хотя возможности реагировать на клавиши в теле программы не хватает. Сброс аварий приходится делать через запись параметра в меню, и паралельно кнопку вешать для удобства.

starmos
07.03.2017, 14:13
Так и не понял в чем собственно сложность предусмотреть возможность программирования не через OL. В ядре ПР200 - STM32, эта штука например поддерживается средой Arduino и соответственно разработанными под Arduino совместимыми оболочками с программированием на релейной логике и FBD. Кому на чем удобнее, как говорится. Возможности у того же ПР200 очень неплохие, а среда программирования ограничивает его использование на уровне управления воротами или заполнения бака. Возьмешься что посложнее делать и потрахаешься. Вместо того чтобы написать пару строк, надо всякие хитрости придумывать.

rwg
07.03.2017, 16:43
Когда мне в первый раз попал в руки ПР200, я про себя возмутился тем, что вместо пары строчек ST приходится городить паутину из блоков и связей, произвольным образом расползающихся по экрану. А когда немного с ПР повозился, нашёл объяснение, в чём состояла авторская задумка. Период исполнения программы строго 1 мсек и программа выполняется линейно, оператор за оператором. Если дать пользователю ST, в программе могут появиться циклы и периодичность исполнения окажется под вопросом. А вот почему целочисленные переменные только беззнаковые я понять не смог.

Владимир Ситников
07.03.2017, 17:16
Период исполнения программы строго 1 мсек и программа выполняется линейно
ОЛ макрос "очередь на N элементов" содержит столько операций, что даже в текущем ОЛ длительность выполнения цикла будет ого-го какая.
На ST это был бы массив, и количество операций от длины массива не зависело бы.

Более того, вычисления плавающей точки (fADD, fSUB, fGT) эмулируются (процессор ПР200 не умеет работать с дробными). Наверняка что-нибудь в духе 1мкс на пару операций с плавающей точкой.
Т.е. тысяча-две fADD и всё. В 1мсек программа уже не уложится.
Если вспомнить, что вместо fSEL любители создают макрос с двумя fMUL и fGT, то один только такой макрос уже отъедает 1мкс.


Если дать пользователю ST, в программе могут появиться циклы и периодичность исполнения окажется под вопросом.

Уверен, если этот аргумент и был, то он явно где-то на последнем месте.

Филоненко Владислав
07.03.2017, 18:35
Владимиру Ситникову - Существует много ПЛК (в т.ч. и у нас) с Линуксом. Стреляет почему то только у крупных фирм-системных интеграторов, и то конечному пользователю поставляется CoDeSys-подобная или ещё более упрощенная среда разработки. Потому что кривая вхождения в профпрограммирование реального времени нереально крута. И никто не хочет пол года своей жизни тратить только на обучение этому. А потом еще и алгоритм писать! Все хотят соединить вход с выходом через логику, добавить мастеров/slave парой щелчков и не углубляться в написание драйверов, прерываний, нюансов межпроцессного и межпроцессорного обмена, ловить неописанные "фичи" оборудования, отлаживаясь по миганию светодиода и т.п.
А на ПР любой читавший в детстве справочник по радиоэлектронике после 2 дней обучения может писать нужные ему программы.
Причем что в ПР, что в ПЛК собственно среда разработки - это даже не 50% труда. А процентов 20-30 в коде и 5-7 в стоимости конечного продукта.

Если Вам хочется творить - приходите в крупную компанию-разработчик ПО для автоматизации, благо их много теперь.
И если Вы сумеете не перегореть за 1,5 года типичного цикла разработки нового изделия - Вы прочитаете свои теперешние посты с улыбкой.

Владимир Ситников
07.03.2017, 19:02
Владимиру Ситникову - Существует много ПЛК (в т.ч. и у нас) с Линуксом
Уже говорил, но повторюсь: я осознанно выбрал вариант без Linux, т.к. надёжность Linux решений для меня под сомнением.
Судить о КДС runtime, конечно, тоже приходится "на веру". Но стабильность/предсказуемость Linux под вопросом. Масса примеров, когда "внезапно взбесившийся modbus драйвер занимает 100% CPU и ПЛК шлёт пламенный привет временам отклика".


Все хотят соединить вход с выходом через логику, добавить мастеров/slave парой щелчков и не углубляться в написание драйверов, прерываний, нюансов межпроцессного и межпроцессорного обмена, ловить неописанные "фичи" оборудования, отлаживаясь по миганию светодиода и т.п
Во во. Именно по-этому и прошу чего-нибудь типа ST или IL в составе OwenLogic.
Так, чтобы можно было создавать программы для ПР, чтобы при этом не приходилось заниматься непотребством квадратиками ОЛ и с драйверами.

Обратите внимание: я не просил возможность заливать бинарный код.
Речь именно о промежуточном p-code (IL, ASM, без разницы как называть). Так, чтобы особенности железа решались прошивкой ОЛ/интерпретатором этого самого p-code, и чтобы при этом не приходилось заниматься непотребством при программировании в ОЛ. Например, чтобы можно было генерировать код в сторонних инструментах.



А на ПР любой читавший в детстве справочник по радиоэлектронике после 2 дней обучения может писать нужные ему программы.
Да, так, всё верно.

Обсуждаемая проблема в текущей теме состоит в том, что тому, кто читал книги чуть более двух дней, в рамках ОЛ будет тесно.
Могут быть проекты (и встречаются), где ограничивающим звеном будет не железо/время/мозги, а именно ОЛ. Именно это печально.

Например, я осознанно не стал выбирать ОЛ, т.к. программировать одними квадратиками это печаль.



Вы прочитаете свои теперешние посты с улыбкой.
Если бы я писал: "покажите формат прошивки, и я сделаю свою более лучшую", то я бы понял где нужно было смеяться.
В теме же вопрос про p-code / IL, и оно никак не связано с программированием реального, нереального или какого там ещё времени.
Вопрос просто про возможность интеграции ОЛ со сторонними генераторами программ.

Для ST, например, кто-то вообще в Excel программы генерирует по шаблону. В ОЛ такое никак, ведь в ОЛ можно только мышкой рисовать.

melky
07.03.2017, 19:43
rwg что-то вы погорячились с 1 мс, у меня программа 5 мс по времени работает если верить индикатору ПР200.
я за то, чтобы сами макросы для ОЛ можно было бы писать на С# и подключать их к базе макросов.
мечты, мечты.....

Филоненко Владислав
09.03.2017, 11:24
Овен Лоджик работает как работает. P-code, о котором Вы так мечтаете - это те же квадратики, но в виде потока байт. За счёт супероптимизации процентов 10, наверное, выжать удастся по производительности.
У нас и так самый быстрый ПР среди конкурентов.

А шаг ниже - это писать свою программу на С и ASM и прошивать её в STM-ю отладку.

Никаких коварно скрываемых от общественности суперформатов загрузки не существует.

Владимир Ситников
09.03.2017, 12:15
А шаг ниже - это писать свою программу на С и ASM и прошивать её в STM-ю отладку.
По-моему, вы смотрите со стороны разрабочика ОЛ. Да, для разработчика ОЛ шаг ниже это C или бинарный код STM.
Но для общественности доступны лишь "квадратики ОЛ, которые нужно таскать мышкой".
Для общественности, p-code это и есть тот самый нужный "шаг ниже". Большинству этого самого p-code должно хватить.


Смысл не в "супероптимизации производительности", а в том, чтобы просто иметь возможность генерировать программы для ПР в сторонних редакторах.

Понятно, что соединить вход с выходом в ОЛ проблем не составляет. А, например, записать формулу уже непросто.


Никаких коварно скрываемых от общественности суперформатов загрузки не существует.

О, где можно почитать/попробовать ОЛ p-code?

Алексей Геннадьевич
09.03.2017, 13:25
Овен Лоджик работает как работает. P-code, о котором Вы так мечтаете - это те же квадратики, но в виде потока байт. За счёт супероптимизации процентов 10, наверное, выжать удастся по производительности.


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

AlexP
10.03.2017, 22:28
Согласен с автором темы относительно вставки макросов, написанных на ST (или на С). Более-менее серьезные проекты на ПЛК у меня ну никак не обходятся без ST, - те же формулы, или мозго-выносящие ветвистые условия. Просто, в данной ситуации написать пару-тройку строк кода гораздо менее трудоемко, чем воротить все это на FBD. Планировал серьезно применять ПР200 в вентиляции и кондиционировании - платформа и возможности довольно серьезны для этого, НО. Написать что-то стоящее в ОЛ в данном случае, конечно, можно, но человеко-часов я на это затрачу просто уйму! И это не допустимо, потому что, в основном, все решает время. Да-да, последний пример: срочно сделать штучный заказ для нестандартной приточной установки. Если бы в ОЛ была возможность вставки хоть примитивного ST, как, например, в 1Tool у Carel, не задумываясь бы взял ПР200 (очень нравится). А так, :confused: заказал pCOxs с панелькой за 38k. И только из-за отсутствия ST в Лоджике, и отсутствия времени у меня.
Конечно, я понимаю, реализация ST тянет за собой серьезные вложения в разработку IDE Лождик, но в этом случае ПР200 добавил бы себе еще какое-то количество потребителей, это уж точно.

rovki
10.03.2017, 23:03
Написать что-то стоящее в ОЛ в данном случае, конечно, можно, но человеко-часов я на это затрачу просто уйму! И это не допустимо, потому что, в основном, все решает время. .
Так это не проблема ОЛ ,скорее ваша ,потому как ОЛ делался для электрошиков ,для которых ваши проблемы вообще не проблемы .Кто на что учился .А так берите ПЛК 63 и все (не считая цены,но ОЛ в этом не виноват) будет быстро у вас .

Вольд
11.03.2017, 13:04
Конечно, я понимаю, реализация ST тянет за собой серьезные вложения в разработку IDE Лождик, но в этом случае ПР200 добавил бы себе еще какое-то количество потребителей, это уж точно.

Вода камень точит. Кончится тем, что появится возможность программировать ПР "ОВЕН" и на ST. rovki и "электронщики" буду продолжать программировать в ОЛ, а у более продвинутых пользователей появятся альтернативные возможности. Дали бы волю В.Ситникову все бы давно было сделано.

Владимир Ситников
11.03.2017, 14:39
Вот как раз это и интересует гурманов как Владимир да и других
Интегрировать C и ОЛ намного сложнее, чем какой-нибудь p-code / IL и ОЛ.
Программировать ПР/ПЛК на C вряд ли будет много желающих.
И уж вряд ли будут желающие вообще весь стек с нуля создавать (ну, на C писать работу с 485, симулятор, online, загрузку программы и т.п.)

Сколько тут умельцев, способных и желающих написать свою прошивку для ПР? Ни-ко-го.
Разве что ради развлечения/хобби.

Поэтому я и говорю, что нужно не STM-32 на C программировать, а делать так, чтобы в ОЛ можно было добавлять программы-макросы, написанные на p-code / IL.
Разумеется, IL программы не вручную писать, а каким-нибудь генератором (компилятором). Например, пишем на ST -- получаем IL, вставляем IL в ОЛ.

rovki
11.03.2017, 14:43
а у более продвинутых пользователей появятся альтернативные возможности. Дали бы волю В.Ситникову все бы давно было сделано.
Для кучки продвинутых ,которым не хватает денег купить плк63 (12тр) и которые хотят получить альтернативные возможности -то же самое за 6тр ,следует знать что все дополнительные затраты (при бесплатности ОЛ) лягут на цену ПР200 или размажутся на все изделия (скорее всего) ...Халявы бесплатной нет уже давно и это следует знать продвинутым в этой области пользователям.При скрещивании божей коровки и мухомора(внешне похожи) не следует надеятся на здоровое потомство.;)

Алексей Геннадьевич
11.03.2017, 15:13
Сколько тут умельцев, способных и желающих написать свою прошивку для ПР? Ни-ко-го.
Разве что ради развлечения/хобби.

Вопрос неправильно поставлен.
Правильный вопрос - нафига?
1)Приключений себе на задницу найти можно и более простыми способами.
А если так припекло, то:
2)Сравниваем цену на отладочную плату STM и ПР-200.
3) в промышленности "самопал" недопустим.

Владимир Ситников
11.03.2017, 15:18
Вопрос неправильно поставлен
Читаем между строк или как?

Я же и говорю: никому не впилось программирование ПР на C.


я и говорю, что нужно не STM-32 на C программировать, а делать так, чтобы в ОЛ можно было добавлять программы-макросы, написанные на p-code / IL.
Переводя с русского на русский: прошивка ПР от ОВЕН, а прикладной код на IL. Разумеется, в IL не должно быть возможностей прямого доступа к памяти/портам ввода-вывода, а только оговоренный перечень инструкций.

Безопасность кода сохраняется, и всё норм.

Владимир Ситников
11.03.2017, 15:30
Он может и появится через 1-2 года но к тому времени и ПР должна быть уровнем выше да это уже будет другой прибор это уж точно.

Тема "Модули расширения для ПР200" длится примерно эти самые 1-2 года и ничего.
Поэтому никуда за эти 1-2 года прогресс не сдвинется. Как есть сейчас ПР+ОЛ, так и останется. Как сейчас полезна возможность IL в ОЛ, так и через год-два никуда потребность не денется.

Ну, разве что конкуренты сделают.

Владимир Ситников
12.03.2017, 15:35
К сожалению, я уже не работаю с ПР-ми
Это минус.

Но тема располагается в разделе "Среда программирования OWEN Logic" и ждёт часа, когда на неё обратит внимание тот, кто разрабатывает ОЛ-ПР.

murdemon
12.03.2017, 15:49
Вы бы для начала лог загрузки пары проектов, выложили. там И два входа на выход, ИЛИ два входа на выход. Может быть и понятней стало, как там загрузка происходит. А Овен это делать точно не будет, тогда ПР будут мешать продажи ПЛК. (и прибыль упадет 100%)

rovki
12.03.2017, 18:55
Для начала бы сделал ,что сделал Сергей -автор FLprog .Вот где поле деятельности для программистов http://flprog.ru/forum/1...

Владимир Ситников
12.03.2017, 22:09
Итак, ещё раз.
Никаких макросов на ST в ПР не запишешь.
Никакого ускорения макросов с помощью "волшебных технологий" не будет. Архитектура не позволяет.

Алексей Геннадьевич приводил пример, когда p-code ускорит выполнение ОЛ программ -- массивы:


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

Ещё один пример -- условные переходы. Сейчас ОЛ программа вся целиком выполняется, а с условным переходом можно пропускать ненужный на текущем этапе код.


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

Под программировать я имею ввиду сделать макрос "ПИД с автонастройкой", "вычислить логарифм", "вычислить квадратный корень".

rovki
12.03.2017, 22:41
Русским языком же сказано - делайте макросы ,если будут хорошие и популярные разработчики встроят в код .Вот и возьмитесь сделать адаптивный ПИД регулятор на том что есть (один раз по мучайтесь ).В принципиальных электрических схемах нет условных переходов и не чего ...

Владимир Ситников
12.03.2017, 22:51
Русским языком же сказано - делайте макросы ,если будут хорошие и популярные разработчики встроят в код .Вот и возьмитесь сделать адаптивный ПИД регулятор на том что есть (один раз по мучайтесь ).В принципиальных электрических схемах нет условных переходов и не чего ...

Русским языком говорю: если нечего сказать -- мимо темы.


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


В принципиальных электрических схемах нет условных переходов и не чего ...
Должны же понимать, что ОЛ не на электрических схемах пишется?
Должны же понимать, что ПР не на электрических схемах работает? Да, да. Программа выполняется STM процессором, и ни о каких "электрических схемах" (нарисованных в ОЛ) этот процессор не думает.
У него есть набор инструкций и он по очереди их выполняет. Переходы у него есть. Как условные, так и безусловные.

Зачем же электрические схемы приплетать сюда?
К текущей теме схемы никак не относятся, а лишь намекают на неграмотность.

rovki
13.03.2017, 00:09
Р
Зачем же электрические схемы приплетать сюда?
К текущей теме схемы никак не относятся, а лишь намекают на неграмотность.
Да как вы не понимаете ,что речь идет о пользователях,а не процессорах ,для них работа в ОЛ должна быть как с железом .Козе понятно ,что все реализуется программно ,а значит последовательно.Поэтому без намеков говорю - Королева из вас не получится никогда ,в лучшем случае Эйнштейн :rolleyes: или Прокурор.
И то что будет сделан ПИД в ОЛ не то же самое ,что реализация его в библиотеке ,то же всем понятно. Просто нужна реализация для понятия и отладки алгоритма ,а уж потом реализовать его на любом языке нет проблем .

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

Вы хоть 100500 раз можете сказать, что "в ОЛ обязательно работа должна быть как с железом", но эти слова ничего не стоят.
Я предлагаю, что должна быть возможность создавать ОЛ макросы-программы и на нормальных языках. Я приводил случаи, когда схемный подход крайне плох (автонастройка, логарифм, массивы, итеративные вычисления и т.п.). Я учитываю, что оба подхода должны будут как-то вместе сосуществовать (если делать по-нормальному, то никаких проблем не будет), и, опять же, там не потребуются космические вливания в разработку/поддержку/документирование ОЛ.


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

Если же нужен нормальный промышленный алгоритм (проверенный, рабочий, и т.п.), то делать его в ОЛ схемах подобно смерти.
Я уже много раз говорил, что ОЛ схемы не поддаются тестированию, и сейчас повторю: даже, если кто-то и сделает "макрос автонастройки ПИД", то его невозможно будет проверить. Вдруг через N часов работы там какая-нибудь ошибка окруления накопится? А вдруг он вразнос пойдёт?

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

Был уже один, который утверждал, что "в железе законы математики не действуют". Так вот. Смоделировать автонастройку ПИД можно и нужно это делать без всяких мучений с ОЛ.
Более того, при моделировании на нормальном языке, можно сразу в модель подавать разные условия на вход, и сразу видеть как поведёт себя система.


В общем, rovki в руководители проекта разработки софта не годится.
В руководители "рисования схем" -- не исключаю. А к разработке софта (и руководству разработкой) уж точно допускать нельзя.


PS. Понятно, что тема никак не про обсуждение rovki. Тем не менее, некоторые проецируют "о, rovki, это тот, на чьих макросах 100500 проектов построено, значит он дело говорит, а Владимир Ситников никак понять не может". Поэтому и подчёркиваю, что опыт rovki в составлении схем никак не делает ему авторитета в текущей теме (которая больше про "доработку ОЛ" и про "управление проектами разработки софта")

anthrwpos
13.03.2017, 05:50
Да как вы не понимаете ,что речь идет о пользователях,а не процессорах ,для них работа в ОЛ должна быть как с железом .

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

ASo
13.03.2017, 07:41
Я приводил случаи, когда схемный подход крайне плох (автонастройка, логарифм, массивы, итеративные вычисления и т.п.).Просто это ПР. РЕЛЕ!
Для таких вещей есть иные системы.
Я понимаю, национальная особенность - есть микросхема - возьми с нее 100% функционала. А лучше 101% Но в целом мир живет по другому.

rovki
13.03.2017, 08:04
Да, сейчас для ПР программы можно составлять только через ...барабанная дробь... рисование схем.
Поймите же наконец, что смысл текущей темы и состоит в том, чтобы расширить эти границы. Кто-то по-прежнему будет рисовать схемы, а кто-то будет использовать и более удобные языки.

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

rovki
13.03.2017, 08:15
Вы напрасно считаете пользователей ПР дураками.
Любой нормальный инженер АСУ сегодня умеет программировать порой лучше тех, кто учился на программиста.
И если некому пользователю важно, чтобы программирование автоматики было сродни сбора релейной схемы, ему стоит подумать о том, что его призвание - электромонтер или слесарь КИП, а не АСУшник :)
Батенька ,вы о чем (о ком) .Ключевое слово Сегодня ,а за долгое время подготовлены миллионы схемотехников .Электронщиков ни как не меньше чем программистов .Электронщики это не те кто схемы Рисует ,а те кто алгоритмы реализует в железе (жесткая логика) и где даже процесс отладки отличается от процесса отладки программы.И принцип работы другой (параллельный) .Для них и сделано ПР .Если ,как пишет Ситников ,работать в ОЛ не удобно и не безопасно,а люди делают проекты замечательные не смотря на это ,то они значит умнее тех кому легко .

Алексей Геннадьевич
13.03.2017, 08:17
Да, сейчас для ПР программы можно составлять только через ...барабанная дробь... рисование схем.
Поймите же наконец, что смысл текущей темы и состоит в том, чтобы расширить эти границы. Кто-то по-прежнему будет рисовать схемы, а кто-то будет использовать и более удобные языки.

Вы хоть 100500 раз можете сказать, что "в ОЛ обязательно работа должна быть как с железом", но эти слова ничего не стоят.
Я предлагаю, что должна быть возможность создавать ОЛ макросы-программы и на нормальных языках. Я приводил случаи, когда схемный подход крайне плох (автонастройка, логарифм, массивы, итеративные вычисления и т.п.). Я учитываю, что оба подхода должны будут как-то вместе сосуществовать (если делать по-нормальному, то никаких проблем не будет), и, опять же, там не потребуются космические вливания в разработку/поддержку/документирование ОЛ.
В результате получим контроллер с поддержкой МЭК языков и конским ценником.
"Конский ценник" поставит крест на нишевом применении ПР. Что я буду логарифмировать в конечном автомате, который работает на дискретных сигналах?
Онлайн-режим для этого намного полезнее.


Вот найдётся кто-то "идейный", который сделает "макрос автонастройки ПИД". Макрос возьмут и взорвётся объект. Вот здорово будет.... В ОЛ физически нет возможности сделать тест этого самого ПИД регулятора. Вручную что-ли на вход подавать "температуру печи" и щёлкать выполнение "одного цикла"? Тестировать нужно не один сценарий, а много. Тестировать нужно и ошибки датчиков. По-хорошему, при любой модификации алгоритма нужно заново всё перепроверять.
Нужно правильно оборудование подбирать соответственно выполняемой задаче.
А что-нибудь взорвать всегда помогут. В Чернобыле и Фукусиме с этой задачей справились на "отлично", несмотря на всю защитную автоматику.

Был уже один, который утверждал, что "в железе законы математики не действуют".
Это как?:confused:
Можете пояснить?

Владимир Ситников
13.03.2017, 10:30
В результате получим контроллер с поддержкой МЭК языков и конским ценником.
"Конский ценник" поставит крест на нишевом применении ПР. Что я буду логарифмировать в конечном автомате, который работает на дискретных сигналах?
Онлайн-режим для этого намного полезнее.

О, да, слова "конский ценник" всё объясняют.
Применю к вам ваши же аргументы: "если добавить онлайн-режим, то конский ценник поставит крест на нишевом применении ПР". Каково?

Да, вы безусловно правы. Если добавить поддержку всех МЭК языков в ОЛ, то цена будет прямо как от космолёта. Но я и не прошу добавлять все языки.

Текущая тема не про МЭК языки для ПР-ОЛ, а про один-единственный "IL язык". Язык, в котором команды тривиальные, расположены по одной на строку и т.п. С его реализацией сложностей быть не должно, учитывая что сам по себе ОЛ уже компилирует в какой-то такой язык свои FBD картинки.

Или речь про то, что "ну, раз ПР-ОЛ можно на IL программировать, то цену-то в 2 раза приподнимем"? По-моему, бред.



Нужно правильно оборудование подбирать соответственно выполняемой задаче.
А что-нибудь взорвать всегда помогут. В Чернобыле и Фукусиме с этой задачей справились на "отлично", несмотря на всю защитную автоматику.
Т.е. "ПИД с автонастройкой" это уже за областью применимости ПР?


Это как?:confused:
Можете пояснить?
Прямо так, так и было. Пояснил в личку.

rovki
13.03.2017, 10:33
Вот почему ,вроде тоже (как Ситников) программист Владислав сечет на раз ,а другие продвинутые дальше носа своего не видят ,а потому что одни делают для всех (круг пользователей) ,а другие для себя любимого ,прикрываясь фразами о заботе о других продвинутых пользователей и не думая о последствиях (повышение затрат и цен) ибо это не их товар и не им жить на полученную прибыль или убытки.

Вольд
13.03.2017, 10:33
Задача была плохо поставлена при разработке ОЛ от того и все последующие проблемы, бесконечные доработки и споры.

rovki
13.03.2017, 10:46
Задача была поставлена правильно ,а опыта было маловато .Проблем при использовании ОЛ не было больших ,за исключением переполнения стека.Доработки связаны с увеличением функционала .Вспомним первые версии и последнею -небо и земля .Сменилась платформа и сменился ОЛ ....но он по прежнему поддерживает все платформы и старые проекты -одно это сильно усложнило задачу...Просто одни философствуют ,а другие уже десятки проектов сделали и делают и не нарадуются .

Николаев Андрей
13.03.2017, 10:47
Господа, давайте не устраивать холивар в каждой теме.
Такие темы будут закрываться и убираться в курилку.
Вольд получил бан на 10 дней. starmos получает предупреждение.

Основная логика OL - простая система для широкого круга пользователей. Знакомых с релейкой и работой с шрафическим представлением ФБ. И этого мы, в ближайшее время, менять не планируем.
Однако это не значит, что OL не может развиваться.
Основной язык бесспорно останется FBD. Для основных потребителей данного продукта мы будем продолжать создавать макросы. Включая блоки для вентиляции, управления насосами, ПИД и т.д.
Но добавление редактора для создания макросов на Си подобных языках обдумаем. Большое спасибо за идею.

Для тех, кто больше двух дней читает умные книжки, кому за это платят и есть на это время - всегда готовы предложить ПЛК на CODESYS. На st писать - не переписать. Да и расширенный SFC, на мой взгляд, может дать фору Дракону.

Филоненко Владислав
13.03.2017, 10:54
Задача была поставлена правильно ,а опыта было маловато .Проблем при использовании ОЛ не было больших ,за исключением переполнения стека.Доработки связаны с увеличением функционала .Вспомним первые версии и последнею -небо и земля .Сменилась платформа и сменился ОЛ ....но он по прежнему поддерживает все платформы и старые проекты -одно это сильно усложнило задачу...Просто одни философствуют ,а другие уже десятки проектов сделали и делают и не нарадуются .

Архитектура и заложенные технические решения кроют ТЗ на ПР раз так в 200.
Именно по этому тут и разразился холивар. Мы сделали слишком хороший (а с современными процессорами) и быстрый ПР - и теперь некоторые хотят из него сделать ПЛК. Задёшево.

Алексей Геннадьевич
13.03.2017, 12:25
Просто это ПР. РЕЛЕ!
Для таких вещей есть иные системы.
Я понимаю, национальная особенность - есть микросхема - возьми с нее 100% функционала. А лучше 101% Но в целом мир живет по другому.
В отчете не забыть 146% указать.:)

О, да, слова "конский ценник" всё объясняют.
Применю к вам ваши же аргументы: "если добавить онлайн-режим, то конский ценник поставит крест на нишевом применении ПР". Каково?
Возможно и так.


Текущая тема не про МЭК языки для ПР-ОЛ, а про один-единственный "IL язык". Язык, в котором команды тривиальные, расположены по одной на строку и т.п. С его реализацией сложностей быть не должно, учитывая что сам по себе ОЛ уже компилирует в какой-то такой язык свои FBD картинки.
Делать это или нет - зависит от стратегии производителей.

Т.е. "ПИД с автонастройкой" это уже за областью применимости ПР?
Пусть его производители пишут и тестируют.
Мне своего макроса PID с блоком АНР хватает.


Архитектура и заложенные технические решения кроют ТЗ на ПР раз так в 200.
Именно по этому тут и разразился холивар. Мы сделали слишком хороший (а с современными процессорами) и быстрый ПР - и теперь некоторые хотят из него сделать ПЛК. Задёшево.
ПР200 безусловно хорошее программируемое реле, а когда выйдет весь сортамент блоков расширения - станет ещё лучше.


теперь некоторые хотят из него сделать ПЛК. Задёшево.
Вся соль.

Eugene.A
13.03.2017, 13:11
Соль, видимо, в том, что часть специалистов пришли в АСУ из программистов на С, и схемы для них - чужое. Вот в недалёком будущем понабежит программистов 1С и баз данных, сокращаемых из банковской сферы и бухгалтерий предприятий, вот тогда начнётся! Будут требовать внедрить в ПР эксель, СУБД.
Я собственными глазами видел сделанный в экселе интернет-магазин и чертежи автомобильного двигателя в вордарте. Правда, можно было быстрее доехать до магазина и отстоять очередь, чем дождаться адекватной реакции от этого интернет-магазина. Зато движок в ворде выглядел отлично - с градиентными заливками, цветной! Правда, сколько времени потратила на него девчонка, делая курсовой - история умалчивает.

Филоненко Владислав
13.03.2017, 13:35
Давайте уже закроем эту абсолютно бесперспективную тему.


Текущая тема не про МЭК языки для ПР-ОЛ, а про один-единственный "IL язык". Язык, в котором команды тривиальные, расположены по одной на строку и т.п. С его реализацией сложностей быть не должно, учитывая что сам по себе ОЛ уже компилирует в какой-то такой язык свои FBD картинки.

Никто ничего ни на какой IL язык не компилирует. Точка. ПринцЫп работы ПР радикально иной. :cool:

rovki
13.03.2017, 14:00
Давайте уже закроем эту абсолютно бесперспективную тему.
cool:
Что бы не отвлекала от дел ... правидных

melky
13.03.2017, 18:08
Загрузил СТАРЫЙ проект в ПР114 (писался в 51-й) при помощи 99-й версии и все сломалось, хотя ПР обновился до 3.13, залил программу но какие-то нелады с таймерами и чем-то еще.

Разрабы либо не увидели сообщения либо не знаю. У кого есть на руках ПР114-тые попробуйте. Думаю сильно удивитесь.

Василий Кашуба
13.03.2017, 19:15
Загрузил СТАРЫЙ проект в ПР114 (писался в 51-й) при помощи 99-й версии и все сломалось, хотя ПР обновился до 3.13, залил программу но какие-то нелады с таймерами и чем-то еще....
Скорее всего с делением на ноль. Раньше при делении на ноль получался ноль. В последних релизах NAN и остановка программы.

anthrwpos
13.03.2017, 19:28
Соль, видимо, в том, что часть специалистов пришли в АСУ из программистов на С, и схемы для них - чужое.
Я например, вообще физик-оптик)
Изучил сперва электронику, а оттуда попал в АСУ)
Схемы для меня - родное, си освоил только как приложение к электронике в программировании прошивки микроконтроллеров. И тем не менее я считаю, что пытаться пародировать схемотехнику при программировании ПР - неудачная затея)
Лучше уж си. Все равно те, кто умеют только релешки крутить никогда не освоят программирование ПР в принципе. По меньшей мере сколько я не знаю релейщиков (в том числе инженеров-релейщиков с огромным стажем), с кем из них не делился своим восторгом относительно ПР-200 никто из них не пожелал ознакомиться с подобным достижением техники)

Василий Кашуба
13.03.2017, 19:49
Я например, вообще физик-оптик)
Изучил сперва электронику, а оттуда попал в АСУ)
Схемы для меня - родное, си освоил только как приложение к электронике в программировании прошивки микроконтроллеров. И тем не менее я считаю, что пытаться пародировать схемотехнику при программировании ПР - неудачная затея)
Лучше уж си. Все равно те, кто умеют только релешки крутить никогда не освоят программирование ПР в принципе. По меньшей мере сколько я не знаю релейщиков (в том числе инженеров-релейщиков с огромным стажем), с кем из них не делился своим восторгом относительно ПР-200 никто из них не пожелал ознакомиться с подобным достижением техники)
А я по образованию, вообще инженер по эксплуатации средств связи (факультет Проводная связь), но могу даже на простых радиоэлектронных компонентах, составить схему и рассчитать параметры, хоть усилителя, хоть генератора, хоть приёмника с передатчиком. А вот с иностранными языками проблема, поэтому, хоть КДС, хоть другие языки взять, я выбираю ФБД или СФС.

Алексей Геннадьевич
13.03.2017, 20:25
Все равно те, кто умеют только релешки крутить никогда не освоят программирование ПР в принципе. По меньшей мере сколько я не знаю релейщиков (в том числе инженеров-релейщиков с огромным стажем), с кем из них не делился своим восторгом относительно ПР-200 никто из них не пожелал ознакомиться с подобным достижением техники)
Если под себя не делают и в припадке не бьются, увидев ПР200/(ну или пофиг какой контроллер) в электрощите-уже хорошо.


Текущий уровень среды ОЛ рассчитан на людей возраста 35-60 лет. Если добавить в ОЛ язык LD то добавится люди с АСУ 25-45 лет. Если добавить язык Си то возраст потребления станет по моложе 16-50 лет. Собственно языки мэк видимо и рассчитаны под все слои развития общества.
Какое интересное утверждение.
А я-то думал, что язык МЭК берётся тот, на котором данную задачу решить проще всего...
Ой, это я про контроллеры...

melky
13.03.2017, 20:51
Василий Кашуба , программа точно не останавливается, но попробую проверить. Она неадекватно себя ведет даже в эмуляции.

Eugene.A
13.03.2017, 20:55
никто из них не пожелал
Это ключевое слово. Без желания никогда ничего путного не происходило. А программирование на С кто-нибудь из них освоил?

ASo
13.03.2017, 21:08
Если добавить в ОЛ язык LD то добавится люди с АСУ 25-45 лет.А на LD пишет кто нибудь, кроме а)РЗАшников б)пришедших из "американской" школы программирования промконтроллеров?

sdy
14.03.2017, 02:13
Но добавление редактора для создания макросов на Си подобных языках обдумаем. Большое спасибо за идею.


Вот это давно пора!
Как вспоминаю свой проект с битовой логикой в ОЛ - трясти начинает. Заглянул в него на днях - трешак полный, хоть и вроде всё в переменных - но без бутылки не разобраться 100%.

ferret_maybe
14.03.2017, 06:53
Я пишу, и очень удачно, потому что я с электриков релейщиков. В американских школ учебу и не проходил так как я с деревни а вот с советскими схемами в основном и работаю и их кстати очень удобно переносить в LD. А вот асушников на LD пока не встречал, но это не говорит о том, что LD плох, а вот на тех кто долек от схемотехники насмотрелся и что они творят я молчу. Не будет азов и практики релейно логики так и будут ставить плк и панели чтобы пускателем насоса управлять.
Вопрос думаю не в языке программирования, а в формальных методах написания программ для автоматизированных систем. LD и FBD - в принципе занимают одинаковый уровень иерархии языков MЭК 61131-3 и созданы для преемственности, на них легко и удобно написать небольшую программу (что и представлено в программируемых реле), ST и SFC - используются в большинстве для написания сложных и больших систем. Тем не менее SFC можно реализовать и через LD, FBD или ST, что и обеспечит удобство читаемости кода и дальнейшей поддержки.
Скриптовый язык и в среде разработки будет только плюсом.

starmos
14.03.2017, 07:03
Но добавление редактора для создания макросов на Си подобных языках обдумаем. Большое спасибо за идею.


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

melky
14.03.2017, 07:27
Учитывая, что сам ОЛ написан на С# (если разработчики не врут, а не должны так как для работы требуется NET) то правильнее будет сделать на нем.
Опять же, пользователям можно предоставить механизмы, которые будут заложены в мозгах ПР.

з.ы. разобрался почему программу глючит на ПР114 в новых версиях - КОГДА разработчики ВЕРНУТ на место переменные по умолчанию для СЕТЕВЫХ переменных ??????????????????????????

ASo
14.03.2017, 08:06
Я пишу, и очень удачно, потому что я с электриков релейщиков.Ну а я - из системотехников. Когдато, как и ровки, помнил на изусть почти всю 74** (или к155, если так удобнее) с точностью до распиновки. Поэтому мне удобнее FBD/CFC, что по сути одно и тоже. И?

capzap
14.03.2017, 09:53
призываю компанию ОВЕН срочно двигаться в ногу со временем - счет идет уже даже не на месяцы, на недели.


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

народ пишет (http://www.owen.ru/forum/showthread.php?t=26081&highlight=%E1%E8%E1%EB%E8%EE%F2%E5%EA%E0), но что то как то ...

Николаев Андрей
14.03.2017, 10:23
Именно поэтому спор и не имеет смысла. Именно поэтому же 5 языков программирования МЭК. Кому коньяк, кому ликер, а кому минералочку.
До настоящего момента язык FBD в постсоветском пространстве самый распространенный, ну не считая тех, кто 2 часа книжку почитав скучает от квадратиков :) При этом выпускники профильных специальностей по определению им владеют. Даже в техникумах начинают учить языкам МЭК.
Эти же выпускники, в принципе, могут освоить и семейство Си и др. языков. Но только зачем, когда их уже научили FBD МЭК? Тем более что речь не просто об операторах и ООП. Здесь речь о философии создания проекта, организации цикла и т.д. Все, ВСЕ программисты, пришедшие не из отрасли, включая Ситникова, наступали на эти грабли.

К сожалению бросить все и начать делать данную задачу прямо сейчас невозможно. Мы все обычно работаем в режиме дефицита ресурсов. Ну у кого работа есть.

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

При этом надо точно понимать, что отхода от МЭК мы точно не планируем. И программистам из 1С так же придется принимать эту философию.

Владимир Ситников
14.03.2017, 10:33
Все, ВСЕ программисты, пришедшие не из отрасли, включая Ситникова, наступали на эти грабли.
А вот это звучит как необоснованные инсинуации. О каком-таком наступлении речь?


Но вопрос правда интересный, и варианты реализации (с возможностями реализации) мы обязательно обсудим.
Обсудите вопрос написания макросов на C и кросс-компиляцией под конкретную версию ПР?

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

rovki
14.03.2017, 11:49
значит на C эти блоки никому не впились[/B].
Вот тут соглашусь ,реле так реле ,а для остального есть ардуино и ПЛК ;) И значит и времени тратить на это не зачем ,есть уже озвученные хотелки ,которые прошли вопрос согласования ....

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

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

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

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

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

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

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

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

Владимир Ситников
14.03.2017, 14:30
Другое дело, что возможность использования ПР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
14.03.2017, 14:37
Еще раз повторяю - ЭТО РЕЛЕ!!!
Здесь пытаются сказать - переделайте ПР200 в ПЛК63. А что входы-выходы соизмеримы, экран по знакоместам одинаков, кнопки.... Вперед, только цена в 2 раза меньше ПЛК. А дальше я например потребую "мозги наружу" (онлайн отладка) и много ПЛК-шных финтюклюшек.
Поймите, это другой тип устройства.

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

Не пойму вашей логики - "поскольку ЗАЯВЛЕНО что это реле, то онлайн отладка по рангу не положена"? Существует какой-то список возможностей, которые реле должно иметь, а которые ни в коем случае не должно, а если аппаратно такая возможность есть, то её надо задушить? Всего лишь хочется взять по максимуму от архитектуры и да за вдвое меньшую чем у ПЛК63 цену. Возможно ПЛК63 имеет какие-то свои достоинства ЕЩЕ, но я не вижу причин на этом основании ограничивать возможности ПР200. Аппаратно-то все есть уже ведь. И да - онлайн отладка тоже бы не помешала, но я даже и не надеюсь, не до хорошего, пусть хотя бы повысят возможности в программировании.

ASo
14.03.2017, 14:56
Никаких, кроме затрат на НИОКР для платформы ПР200. В этом то все и дело.
Ну не просто же так в него не установили РТ КДС?

ASo
14.03.2017, 17:27
Я это предлагал еще для ПЛК. Для "особенных потребов" выпустить в продажу тушку с базовым софтом и бибками для считывания температур.... Принципиальной схемой.
Компилятор С потребитель приобретет самостоятельно.
Собственно, классическая процессорная плата с обвязкой.
ОВЕН отказался со ссылкой на нехватку рессурсов для поддержания этого. И я его понимаю и согласен.

rwg
14.03.2017, 18:15
Сименс их позиционирует как реле, потому что у них есть возможность программирования с экрана-кнопок.

А как быть с безэкранными ЛОГО?

melky
14.03.2017, 20:02
и таки онлайн у Сименс есть, хоть LOGO! и реле, хоть с экраном хоть без...

anthrwpos
14.03.2017, 20:11
1) Само по себе ПР может быть устроено по-разному внутри. Например, ПР200 2017-го года выпуска и ПР2000 2016-го вообще могут иметь внутри разную разводку, разный процессор и т.п.

Вы путаете прошивку контроллера с пользовательской программой.
Доступа к прошивке, где содержится конфигурация портов ввода-вывода, регистров, прерываний и всему прочему вы не получите 100%, ибо если дать юзеру такой доступ, то половина контроллеров будут доведены до состояния при котором он не сможет отвечать на запрос компьютера по USB в течении недели после ввода такой фичи.

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

Алексей Геннадьевич
14.03.2017, 20:26
Вот уж никогда не возникало даже желание запрограммировать сименс с кнопок.
Это для безвыходных "полевых" ситуаций. Когда лого есть, а компьютера нет.
Или покурить волшебной травы, тогда воможно, появится желание.:D

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

Алексей Геннадьевич
14.03.2017, 20:37
ЗЫ Был у нас один ардуинщик... Проработал месяца два) На производстве слово ардуино вообще ругательство, ибо там ни гальванразвязок, ни защиты, ничего.
И чем дело с ним закончилось? что взорвать успел? Или не дали поля для деятельности, и уволился?

Владимир Ситников
14.03.2017, 20:54
Вы путаете прошивку контроллера с пользовательской программой.
Не путаю.


В наиболее вероятном случае во внешней памяти установлен какой нибудь из эмбеддед-линукс
32KiB RAM, 128KiB ROM и embedded linux?
Не верю (tm)

игорь68
14.03.2017, 21:24
Это по моему некогда не закончиться. Да не нужны здесь СИ и тому подобная дребедень. ЭТО РЕЛЕ. И все ваши внешние редакторы отладчики компиляторы и прочие в ОЛ НЕНУЖНЫ. Если не умеешь читать однолинейные схемы или не можешь отличит ТМ2 от ЛА3 то это не для тебя . Если я не хочу себе забивать голову ПЛК или СПК и разбираться в коде то я не лезу с советами на ветку по кодесис. Вон команда-аппарат на реле и кулачковых контактах начиная с ФАУ -2 и посей день в космос летает без всяких СИ. Потому что надежно.
От себя. Сделает ОВЕН как у немцев возможность сохранить прошивку в PDF формате с возможностью обратной конвертации замечательно. Не сможет ну что будем ездить на объекты или через ROVKIны железки будем делать это удаленно.
Сделает Овен как у француза всплывающие окошко где буду кнопочки (входа ) и лампочки (выхода) для режима симулятор хорошо. Нет сможет будем тыкать мышкой по экрану.
А если Овен в помощь Ревака Юрию посадит еще одного человека который будет за маленькую денежку при четком и нормальном ТЗ делать макросы для пользователя это будет вообще замечательно.

Владимир Ситников
14.03.2017, 21:59
Это по моему некогда не закончиться. Да не нужны здесь СИ и тому подобная дребедень. ЭТО РЕЛЕ. И все ваши внешние редакторы отладчики компиляторы и прочие в ОЛ НЕНУЖНЫ.
Вот на это ответьте, пожалуйста:

Не пойму вашей логики - "поскольку ЗАЯВЛЕНО что это реле, то онлайн отладка по рангу не положена"? Существует какой-то список возможностей, которые реле должно иметь, а которые ни в коем случае не должно, а если аппаратно такая возможность есть, то её надо задушить? Всего лишь хочется взять по максимуму от архитектуры и да за вдвое меньшую чем у ПЛК63 цену...

starmos верно сказал.
Сейчас же получается, что "политика партии" состоит в том, чтобы ОЛ было унылым. Хозяин-барин.



Если не умеешь читать однолинейные схемы или не можешь отличит ТМ2 от ЛА3 то это не для тебя
Перефразирую: если только и умеешь, что читать однолинейные схемы, то нечего говорить за архитектуру ПР-ОЛ.
Или так: создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться.

ASo
14.03.2017, 22:24
Или так: создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться.Для удобства можете считать и так.
Именно поэтому и появились "языки МЭК" как инструмент для инженера-ТЕХНОЛОГА, а не программиста.
Тем не менее, в той же промэлектронике во всю используют стандартные одноплатные компьютеры (начиная от ушедшего, но до сих пор используемого в нашей нефтянке micro PC == IBM/PC-XT, продолжая PC/104 и т.д.) но они программируются профессиональными программистами.
И что?

anthrwpos
15.03.2017, 07:12
И чем дело с ним закончилось? что взорвать успел? Или не дали поля для деятельности, и уволился?

Уволился по общей несовместимости с остальным персоналом)
Взорвать ничего не успел, несмотря на то, что чего-то там даже понакрутил на котельной.


Не путаю.
Тогда вы должны понимать, что пользовательская программа не зависит от версии разводки платы и тому подобного. И пользователь однозначно будет писать программу не под STM-контроллер, а под конкретную среду исполнения.

32KiB RAM, 128KiB ROM и embedded linux?
Не верю (tm)
Если это всё что там есть, тогда конечно полноценный линух не влезет. А так это вполне могут быть остатки от всей памяти, которые даны пользователю на свои нужды)

Именно поэтому и появились "языки МЭК" как инструмент для инженера-ТЕХНОЛОГА, а не программиста.
Я не знаю, конечно разные бывают предприятия, но по-моему, весьма маловероятно, чтобы ТЕХНОЛОГ занимался автоматизацией.
Он даст задачу АСУшнику, а АСУШник уже скажет, что нужно для этого купить и сам будет всё программировать.
У нас например, технологи вообще компьютером пользоваться не умеют)

starmos
15.03.2017, 07:32
После прочтения комментариев, у меня вот такой вопрос возник еще: откуда берутся такие специалисты, которые схемы читать умеют, а программировать нет настолько, что для них надо "костыли" придумывать, вроде языков МЭК? Слов нет - МЭК это стандарт для ПЛК, потребность в нем возникла в то время, когда ПЛК встречались не часто, а специалистов по релейно-контактным и логическим схемам было полно. Вот чтобы их вовлечь в процесс и потребовались языки МЭК. Но время-то прошло уже и немало, сейчас языки МЭК имеют смысл потому что устоялись в предметной области, но почему это ограничивает развитие? С 1993 года я 15 лет отработал преподавателем в ВУЗе по специальности "Автоматизация технологических процессов и производств". С 90-х годов студентам давались и программирование на C, в том числе для микроконтроллеров и схемы и логические и релейно-контактные и разработка печатных плат, в том числе микроконтроллерных - все это с практическими занятиями. Как раз ПЛК, что характерно, давались ограниченно, т.к. в ВУЗе современных не было, а новые были дороги, поэтому и был упор на разработку устройств на микроконтроллерах. Но в середине 2000-х появились и ПЛК и при этом С остался, такие задачи, как последовательный интерфейс и работа в сетях TCP/IP - в том числе для микроконтроллеров давались, понятие о работе с базами данных - давалось. Я не думаю что ВУЗ или кафедра в этом отношении уникальны - изучение опыта других вузов, их методичек, скорее говорит о том, что там кое где еще и круче все. Уже 8 лет я в ВУЗе не работаю, но знаю что основные элементы программы остались, за новинками и современными тенденция ми - следят. Очень многие мои студенты работают по специальности (больше чем я ожидал даже), хотя реально немногие сталкиваются с созданием своих микроконтроллерных устройств. Так откуда до сих пор берутся "специалисты", которые тут высказываются на тему - "нам С не нужен, мы в программировании не понимаем, а только в схемах"?

Алексей Геннадьевич
15.03.2017, 08:30
ASo
starmos
Сей спор ведётся ещё со времён Фон-Неймана, который шпынял и троллил коллег которые пользовались новомодным языком-ассемблером. "Что это за математики-программисты такие, что машинный код в голове удержать не могут?
Моё мнение - если на написание программы на FBD и её отладку+ПНР уйдёт неделя, а на то-же самое на С - месяц, то выбор очевиден даже при равных зарплатах инженера АСУ и программиста.

Так откуда до сих пор берутся "специалисты", которые тут высказываются на тему - "нам С не нужен, мы в программировании не понимаем, а только в схемах"?
Оттуда-же, откуда и электрики не знающие закон Ома. И приводчики, которые на привод смотрят как баран на новые ворота.

Уволился по общей несовместимости с остальным персоналом)
Взорвать ничего не успел, несмотря на то, что чего-то там даже понакрутил на котельной.
Считал себя самым умным при нулевом опыте?

capzap
15.03.2017, 08:44
даже сименс беря неплохие деньги за обучение, выдает лишь бумажку прослушал курс лекций, какое преподование в ВУЗах языка? Прямо все досконально изучают, как Вы это определяли, каждым персонально сидели в общяге и репетиторствовали, если всё сводилось к сбору рефератов то у Вас ложно представление о своем курсе. Просто поражает слышать от одного и того же человека, что инженеры ОВЕНа не могут создать идеальный продукт, но в ВУЗах у нас выпускают каждый год гениев, вроде и те и те обычно заканчивают одни и те же институты

Vyachep
15.03.2017, 09:39
Позвольте тоже набросить на вентилятор.

Зачем всякие p-code и написание новых функциональных блоков на С?
Даёшь кроссплатформенный тулчейн, который можно прикрутить к любой из распространенных сред разработки, чтобы ни один программист обделенным не ушел... :cool:

Владимир Ситников
15.03.2017, 09:47
Если это всё что там есть, тогда конечно полноценный линух не влезет. А так это вполне могут быть остатки от всей памяти, которые даны пользователю на свои нужды)
Файл прошивки для ПР200 занимает 156 КиБ
Файл прошивки для ПР110 занимает 32 КиБ


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

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

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

Ежу понятно, что сделать "окружение" можно, если очень захотеть. Другое дело, что, если изначально такой цели не стояло, то прикрутить такое окружение пост-фактум непросто.

starmos
15.03.2017, 09:48
даже сименс беря неплохие деньги за обучение, выдает лишь бумажку прослушал курс лекций, какое преподование в ВУЗах языка? Прямо все досконально изучают, как Вы это определяли, каждым персонально сидели в общяге и репетиторствовали, если всё сводилось к сбору рефератов то у Вас ложно представление о своем курсе. Просто поражает слышать от одного и того же человека, что инженеры ОВЕНа не могут создать идеальный продукт, но в ВУЗах у нас выпускают каждый год гениев, вроде и те и те обычно заканчивают одни и те же институты

Про преподавание языка С я сказал - были и практические работы. Например, кроме работы преподавателем, я занимался разработкой систем на микроконтроллерах, у меня постоянно были готовые платы, которые я использовал для отладки софта - их же я использовал и для обучения. Группе выдавалось задание, они писали программу, прошивали в плату, я по индикаторам и кнопкам принимал итоги. Т.е. весь цикл разработки софта люди проходили на практике. Сейчас стендов для разработки/отладки еще больше и они в разы доступнее.
Когда я писал про "инженеров ОВЕНа" - я просто выражал удивление. Вполне возможно множества, вызывающие мое удивление, пересекаются - не вижу тут противоречия.

Владимир Ситников
15.03.2017, 09:57
Позвольте тоже набросить на вентилятор.
Не позволю!


Зачем всякие p-code
Я приводил конкретные примеры как это поможет с обычными ОЛ проектами: формулы, итеративные вычисления (==ПИД с автонастройкой), автоматическое тестирование.
И, вполне вероятно, добавление подобного должно быть безболезненным для ОЛ.

Вариация же "добавить C" и более сложна в реализации, и менее надёжна, и непонятно какую задачу решает.



Даёшь кроссплатформенный тулчейн, который можно прикрутить к любой из распространенных сред разработки, чтобы ни один программист обделенным не ушел... :cool:
Как это позволит решить что-нибудь из АСУТП области?

Если в Новосибирске, приходи 4-го апреля на https://2017.jbreak.ru/ -- расскажу почему C для ПЛК это боль.

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

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



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

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

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

Владимир Ситников
15.03.2017, 10:17
Так в чем проблема обозвать макрос как "написанный на С" и откомпилировать его отдельно, а редактор связей свяжет его по именам переменных (входов/выходов)?
Блин. Такое ощущение, что вы вообще не сталкивались с разработкой компилятора.

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


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

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

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

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

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

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

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

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

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

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

PS жду очередную порцию камней... яиц.... помидоров....

Владимир Ситников
15.03.2017, 17:17
Для полноты картины тут нужен комментарий Максима (http://www.owen.ru/forum/showthread.php?t=23740&p=205320&viewfull=1#post205320):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rovki
15.03.2017, 20:09
Во-первых, ОЛ делался для "электронщиков", а не для электриков.
Во-вторых, всё равно на LD никто не пишет (ведь, его в ОЛ нет :D )
Не знаю как сейчас ,но ранее по специальности было ,например у меня (специальность 0608 -"Электронно-вычислительные машины, комплексы, системы и сети") -инженер электрик..

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

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

ASo
17.03.2017, 08:17
Не знаю как сейчас ,но ранее по специальности было ,например у меня (специальность 0608 -"Электронно-вычислительные машины, комплексы, системы и сети") -инженер электрик..У меня тот же номер (по старому классификатору, потом перешли на 5-ти значную нумерацию), но специальность - инженер-системотехник.


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

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

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

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

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

Инженерный образец ПР200 -- конец декабря 2014: http://www.owen.ru/forum/showthread.php?t=17153&page=12&p=157505&viewfull=1#post157505
Тогда же и очередные обсуждения о необходимости online режима:

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

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

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

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

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

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

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

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

Владимир Ситников
17.03.2017, 11:00
Для этого нужно найти первую версию ОЛ и посмотреть её возможности.

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

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

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

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

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

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

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

Василий Кашуба
17.03.2017, 11:14
А какого лешего сравнивать самую первую версию ОЛ и связку ОЛ-ПР200?

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

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

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

Владимир Ситников
17.03.2017, 11:18
Говорить про нестабильность при опыте использования ОЛиПР =0 аморально ;)

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


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

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

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

rovki
17.03.2017, 11:48
Если нужно что-то новое -- пущай делают ПР100500, но уж 200-ую не трогают.
Согласен ,только за счет страждущих ;) - двое ,трое скинутся :p

Владимир Ситников
17.03.2017, 11:51
А какого лешего сравнивать самую первую версию ОЛ и связку ОЛ-ПР200?Приведу полную цитату от anthrwpos

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

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

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

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



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



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

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



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

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

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

melky
17.03.2017, 12:08
з.ы. не надо ничего добавлять в основное поле программы ОЛ, пусть так и остается FBD.
Речь то о том, чтобы сам макрос можно было написать на IL (C, C#) и т.д.

Основную программу НЕ ТРОГАЙТЕ своими IL(C) руками :)

Владимир Ситников
17.03.2017, 12:11
Речь то о том, чтобы сам макрос можно было написать на IL (C, C#) и т.д.
Не не не. Речи про IL, C, C# уже не идёт.

Scream
17.03.2017, 12:17
В flprog ардуино тоже программируется блоками, однако есть возможность создать свой блок и описать его на С, это очень удобно и верная мысль.
Вся программа рисуется блоками, однако есть возможность тем, кому надо написать свои на С, я за такой подход, но лично для меня приоритетнее конечно онлайн отладка, без неё вообще не представляю как можно писать серьёзные программы.

Newcomer
17.03.2017, 12:37
Господа, все очень просто. Деньги правят миром.

Активных противников развития ОЛ двое - это представители фирмы "ОВЕН" и патриарх форума rovki.

В фирме "ОВЕН" против потому, что если сделать классным ОЛ, то ПР ОВЕН начнет сильно конкурировать с ПЛК ОВЕН. ПР ОВЕН много дешевле ПЛК ОВЕН, и если многие перейдут с ПЛК на ПР, то объемы продаж ПЛК уменьшатся, ПР увеличатся, а общая выручка от продаж уменьшится. Кто же на это пойдет ?

rovki против потому, что боится увеличения цены ПР ОВЕН, т.к. это может ударить по его малому бизнесу. Всем известно, что rovki кроме ПР в своих системах автоматизации ничего не использует.

Такая вот загогулина. ;)

melky
17.03.2017, 12:51
Newcomer да не начнет он конкурировать никогда, причиной этому сам ПР, то есть его firmware (прошивка). То, что в нее заложат для работы IL, C, C# только это и будет работать.

Ну например в прошивке УЖЕ заложены математические функции, вот сделав макрос мы малюем в нем квадратики a, b на ADD, далее на SUB и т.д.
А имея механизм на некоем языке, ну например С, мы просто создаем макрос, указываем входы, выходы и пишем там (a+b)*c((b-a)/d) = выход. Ну как-то так...

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

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

Newcomer
17.03.2017, 12:56
В ПЛК ОВЕН прямого доступа к процу то же нет. melky, мыслить надо глобально. Ты плохо читал мой первый пост. Умные люди сперва бабки считают, а уже потом начинают думать о технической стороне вопроса.

Владимир Ситников
17.03.2017, 12:59
А имея механизм на некоем языке, ну например С, мы
...запросто можем обратиться по несуществующему адресу в памяти и взорвать установку нахрен.
Любители таких ощущений пусть программируют на C, и в ПР-ОЛ с этим лезть уж точно не нужно.


Тем же способом могли бы добавить работу с массивами без дроча рисования квадратиками...
И правильно, что не делают. Упомянутое рисование квадратиков это и есть овнополагающяя концепция ПР-ОЛ.


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

Василий Кашуба
17.03.2017, 12:59
Хороший всё таки ПР200 получился, если вокруг него такие жаркие споры между программистами и электронщиками.

Владимир Ситников
17.03.2017, 13:03
Хороший всё таки ПР200 получился, если вокруг него такие жаркие споры между программистами и электронщиками.

Да, да. Главное ничего не менять! Лучше уж точно не станет.

Newcomer
17.03.2017, 13:04
Хороший всё таки ПР200 получился, если вокруг него такие жаркие споры между программистами и электронщиками.

Спор как раз о том, как сделать ПР200 много лучше. Мешает этому конфликт интересов.

capzap
17.03.2017, 13:07
В ПЛК ОВЕН прямого доступа к процу то же нет. melky, мыслить надо глобально. Ты плохо читал мой первый пост. Умные люди сперва бабки считают, а уже потом начинают думать о технической стороне вопроса.

может тогда поделитесь, почему Вас больше интересовала черепаха, чем возможность писать в плк на Си, этой возможности ни кто ведь не скрывает http://www.kipshop.ru/CoDeSys/steps/codesys_v23_ru.pdf стр.215

Серёга Букашкин
17.03.2017, 13:07
...запросто можем обратиться по несуществующему адресу в памяти и взорвать установку нахрен.
Любители таких ощущений пусть программируют на C, и в ПР-ОЛ с этим лезть уж точно не нужно.
Элементы на Си точно могут сломать программу. Чистый ОЛ хотя бы гарантирует отсутствие системных ошибок или зависания. Но дать возможность для желающих самим делать подобие макроса на Си - это было бы хорошим инструментом для продвинутых и закрыло бы этот вопрос. Но доступа к ресурсам всё равно не дадут, к прерываниям например, так что это все бесперспективно.

Newcomer
17.03.2017, 13:10
может тогда поделитесь, почему Вас больше интересовала черепаха, чем возможность писать в плк на Си, этой возможности ни кто ведь не скрывает http://www.kipshop.ru/CoDeSys/steps/codesys_v23_ru.pdf стр.215

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

Еще раз выражаю благодарность В.Ситникову за его бескорыстный труд на благо всех.

Попробуйте то же самое сделать на C, о результатах доложите. ;) Один уже недавно пробовал, кажется до сих пор пробует. ;)

capzap
17.03.2017, 13:12
Легко. В.Ситников любезно предоставил инструментарий при помощи которого я легко решил свою задачу.

не уловил связи, создаете в КДС внешнюю библиотеку, заголвочный файл формируется сам, а дальше только Ваша фантазия в написании сишного кода на чем угодно, что Вам S3 не предоставил?

Владимир Ситников
17.03.2017, 13:15
Элементы на Си точно могут сломать программу. Чистый ОЛ хотя бы гарантирует отсутствие системных ошибок или зависания. Но дать возможность для желающих самим делать подобие макроса на Си - это было бы хорошим инструментом для продвинутых и закрыло бы этот вопрос.

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

В общем одни расходы, а доходов никаких. Разве что мифическая фраза "возможность самим делать подобие макроса на Си".

Newcomer
17.03.2017, 13:20
не уловил связи, создаете в КДС внешнюю библиотеку, заголвочный файл формируется сам, а дальше только Ваша фантазия в написании сишного кода на чем угодно, что Вам S3 не предоставил?

Фантазировать это хорошо. ;) При помощи Hardella решить мою задачу было много проще. Все ясно ?

capzap
17.03.2017, 13:24
Фантазировать это хорошо. ;)

вот именно, с чего решили что в ОЛ как то будет отличаться формат написания программ на других языках, не входящих в МЭК и это непременно вызовет массовый ажиотаж программистов начать использовать именно ПР, еще и про деньги какие то начали делать выводы

Newcomer
17.03.2017, 13:28
вот именно, с чего решили что в ОЛ как то будет отличаться формат написания программ на других языках, не входящих в МЭК и это непременно вызовет массовый ажиотаж программистов начать использовать именно ПР, еще и про деньги какие то начали делать выводы

Я про использование С в ОЛ вообще ничего и никогда не писал. Я доходчиво объяснил из-за чего на самом деле весь сыр-бор в теме разгорелся. Если не понимаете простых вещей, то это ваши проблемы.

melky
17.03.2017, 13:28
Владимир Ситников - запросто можно обратиться только к памяти функционального блока, в рамках которого реализована функция (макрос) на С или другом языке - иначе макрос перестает работать везде, как в ПР так и в симуляции ОЛ.
Вопрос в реализации...

Скажем есть область памяти для переменных, отвели пользователю от сих до сих, при проверке в ОЛ за диапазоном - ОШИБКА и невозможность загрузить программу в ПР.

Я ведь не говорю, о прямом программировании ПР на другом языке. Я говорю о том, же, о чем вы сами когда-то говорили, о возможности писать функции простым способом a+b-(c+d) а не квадратиками внутри макроса. ессно с большим функционалом, например расчете логарифмов, косинусов, синусов и т.д. в общем ряда готовых функций, внедренных в прошивку ПР и возможности их использовать при вызове.

Владимир Ситников
17.03.2017, 13:39
Владимир Ситников - запросто можно обратиться только к памяти функционального блока, в рамках которого реализована функция (макрос) на С или другом языке - иначе макрос перестает работать везде, как в ПР так и в симуляции ОЛ.

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

Пример того, кто пытается прикрутить C к ПЛК действительно показателен. "до сих про пытается".


Я ведь не говорю, о прямом программировании ПР на другом языке. Я говорю о том, же, о чем вы сами когда-то говорили, о возможности писать функции простым способом a+b-(c+d) а не квадратиками внутри макроса

Делать в ОЛ какой-то свой (не 61131) язык дело неблагодарное.
Делать ST в ОЛ будет тяжело и долго. Посмотрите сколько делают ОЛ 1.9. Уже вышла версия? Может, там много новых возможностей? Может, там кардинально ПР дорабатывалось?

Ничего этого нет, и тут ОВЕН верен своей стабильности.
a+b-(c+d) сделать непросто, да и патриарх не позволит, в чём будет прав.


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

Ну, да, раз в год, может, и будет появляться один новый блок. Логарифм, косинус, корень.
А, может, и не будет, ведь макросы-то есть. Зачем в прошивку смуту вносить?

rovki
17.03.2017, 14:05
Господа, все очень просто. Деньги правят миром.

rovki против потому, что боится увеличения цены ПР ОВЕН, т.к. это может ударить по его малому бизнесу. Всем известно, что rovki кроме ПР в своих системах автоматизации ничего не использует.

Такая вот загогулина. ;)
Да использую только ПР .Но никогда свои интересы (цена) не ставил выше общих ,из них и исхожу .Для меня цена не имеет значения ,ибо цена оборудования в 10-100000 раз выше.

rovki
17.03.2017, 14:23
Не понял -Ситникова подменили что ли или клон ?:confused:

melky
17.03.2017, 14:46
продался Овену :)

rovki
17.03.2017, 14:51
продался Овену :)

Жалко, не успел за фрактовать .;) есть задачи.

Newcomer
11.04.2017, 21:59
Начал работать с ПР200. Первые впечатления очень хорошие. Конструктив и внешний вид просто замечательные. Плохо, что ПР200 можно программировать только на FBD. Была бы возможность программировать ПР200 на текстовом языке цены бы ему не было. Недавно появился ПЛК110-MS4, для которого ИнСАТ сделал мощнейшую интегрированную среду разработки. В этой среде, в частности, есть PLC Lodgic с четырьмя языками программирования. Почему бы фирме ОВЕН не заказать у ИнСАТ PR Logic на 2 языка программирования.

Владимир Ситников
11.04.2017, 22:10
Начал работать с ПР200. Первые впечатления очень хорошие. Конструктив и внешний вид просто замечательные. Плохо, что ПР200 можно программировать только на FBD.

Известно же, что для реле никакие другие языки кроме FBD не подходят. Да и в ОЛ как раз реализован именно язык FBD. Совпадение?

rovki
11.04.2017, 22:51
Начал работать с ПР200. Первые впечатления очень хорошие. Конструктив и внешний вид просто замечательные. Плохо, что ПР200 можно программировать только на FBD. Была бы возможность программировать ПР200 на текстовом языке цены бы ему не было. Недавно появился ПЛК110-MS4, для которого ИнСАТ сделал мощнейшую интегрированную среду разработки. В этой среде, в частности, есть PLC Lodgic с четырьмя языками программирования. Почему бы фирме ОВЕН не заказать у ИнСАТ PR Logic на 2 языка программирования.
А вас чем не устраивает плк 63 с 5 языками ?

Newcomer
11.04.2017, 22:57
Известно же, что для реле никакие другие языки кроме FBD не подходят. Да и в ОЛ как раз реализован именно язык FBD. Совпадение?

У LOGO только FBD, у Zelio Logic - FBD и LD. У ПР200 надо бы FBD и С. Взять готовый компилятор C и внедрить его в среду разработки. Таким образом делали самопальные среды разработки много лет назад, еще во времена когда ПК работали из под DOS. Ну а во времена, когда есть Visual Studio и прочие мощнейшие пакеты сделать классную среду разработки не так уж и сложно.

Newcomer
11.04.2017, 23:03
А вас чем не устраивает плк 63 с 5 языками ?

Куда деваться если у заказчика в проекте заложен ПР200. Скажешь заказчику надо бы ПЛК63, а он ответит, что ПР200 в 2 раза дешевле. Вот и приходится корячиться на FBD.

Василий Кашуба
11.04.2017, 23:04
У LOGO только FBD, у Zelio Logic - FBD и LD. У ПР200 надо бы FBD и С. Взять готовый компилятор C и внедрить его в среду разработки. Таким образом делали самопальные среды разработки много лет назад, еще во времена когда ПК работали из под DOS. Ну а во времена, когда есть Visual Studio и прочие мощнейшие пакеты сделать классную среду разработки не так уж и сложно.
Может возьмётесь?

Сергей0308
11.04.2017, 23:10
Куда деваться если у заказчика в проекте заложен ПР200. Скажешь заказчику надо бы ПЛК63, а он ответит, что ПР200 в 2 раза дешевле.

Значит полагают, что это легко выполнить на ПР200, были бы сомнения, наверно ПЛК бы заложили, чтобы деньги зря не тратить(если ПР200 не справится)?!

Василий Кашуба
11.04.2017, 23:11
Куда деваться если у заказчика в проекте заложен ПР200. Скажешь заказчику надо бы ПЛК63, а он ответит, что ПР200 в 2 раза дешевле. Вот и приходится корячиться на FBD.
Зачем корячиться, ведь ФБД это так просто. :)

rovki
11.04.2017, 23:11
Куда деваться если у заказчика в проекте заложен ПР200. Скажешь заказчику надо бы ПЛК63, а он ответит, что ПР200 в 2 раза дешевле. Вот и приходится корячиться с FBD.
Ну и заказчики пошли -говорят не то что нужно сделать ,а какой лапатой копать :confused: А на Ардуино еще в 10 раз дешевле ,там и FBD и СИ ...

Newcomer
11.04.2017, 23:13
Значит полагают, что это легко выполнить на ПР200, были бы сомнения, наверно ПЛК бы заложили, чтобы деньги зря не тратить(если ПР200 не справится)?!

Заказчик во все тонкости не вникает. Что такое цена он хорошо знает, а все остальное ему не интересно.

Сергей0308
11.04.2017, 23:15
Да и согласен с ровки, заказчик должен задачу озвучить, в идеале ТЗ, а вы уже выбираете, что лучше подходит, иначе ерунда может получится!

Newcomer
11.04.2017, 23:16
Зачем корячиться, ведь ФБД это так просто. :)

Это смотря какие задачи на нем решать.

Василий Кашуба
11.04.2017, 23:19
Это смотря какие задачи на нем решать.
Пока что все задачи, которые передо мной стояли я решил.

Сергей0308
11.04.2017, 23:25
Если не изменяет память производитель уже определил для чего задумана ПР - замена релейной логики, с чем она без проблем справится!

Newcomer
11.04.2017, 23:27
Если не изменяет память производитель уже определил для чего задумана ПР - замена релейной логики, с чем она без проблем справится!

Согласен, только не она, а оно. ;)

Василий Кашуба
11.04.2017, 23:34
Если не изменяет память производитель уже определил для чего задумана ПР - замена релейной логики, с чем она без проблем справится!
Вот только ПР может решать не только задачи релейной логики, но и кое что по серьёзней, например вычисление тригонометрических функций.

Владимир Ситников
11.04.2017, 23:35
Вот только ПР может решать не только задачи релейной логики, но и кое что по серьёзней, например вычисление тригонометрических функций.

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

Сергей0308
11.04.2017, 23:37
Вот только ПР может решать не только задачи релейной логики, но и кое что по серьёзней, например вычисление тригонометрических функций.

Это уже сами потребители придумали, боюсь во много раз больше, чем заложено в ОЛ!

Василий Кашуба
11.04.2017, 23:39
А микроскоп может решать задачи забивания гвоздей.
Как-никак, вычислять тригонометрию на ПР это то же самое, что использовать ардуино в пром. автоматике.
Зато в молоток нельзя микробы разглядывать.

Newcomer
11.04.2017, 23:43
Как-никак, вычислять тригонометрию на ПР это то же самое, что использовать ардуино в пром. автоматике.

В ПР200 заложен достаточно мощный ЦП, который легко справится с математическими вычислениями.

rovki
12.04.2017, 07:43
Есть Ардуино в промышленном исполнении по цене выше ПР

Алексей Геннадьевич
12.04.2017, 07:50
Ну и заказчики пошли -говорят не то что нужно сделать ,а какой лапатой копать :confused: А на Ардуино еще в 10 раз дешевле ,там и FBD и СИ ...
Не заказчик, а мечта толкового инспектора Ростехнадзора. План по штрафам можно быстро выполнить.

Заказчик во все тонкости не вникает. Что такое цена он хорошо знает, а все остальное ему не интересно.
Даже то, что дешёвая машинка с поставленной задачей не справится?

Вот только ПР может решать не только задачи релейной логики, но и кое что по серьёзней, например вычисление тригонометрических функций. Видел на форуме применение ПР для крана с расчётом угла и вылета стрелы для определения максимально допустимой массы. Тригонометрия, однако.

Филоненко Владислав
12.04.2017, 08:08
Вот только ПР может решать не только задачи релейной логики, но и кое что по серьёзней, например вычисление тригонометрических функций.
Да, мы сделали слишком хороший ПР и теперь страдаем.
Все желания, в конце концов, сводятся к:
Сделайте нам супер среду для программирования, чтобы на ПР влезало не в 20 раз больше, чем на обычной ПР той же цены, а в 100 раз. И еще и приборы продавайте за 3 (лучше 2) копейки.

Филоненко Владислав
12.04.2017, 08:20
Не понял -Ситникова подменили что ли или клон ?:confused:

Нет, Анатолий, просто человек понял.
С чем его и поздравляю.

И подал хорошую идею - нужны спецблоки - пишите, и синус сделают и косинус и арктангенс. Технических проблем добавить новые блоки (в разумном количестве) нет.

Сергей0308
12.04.2017, 08:43
Нет, Анатолий, просто человек понял.
С чем его и поздравляю.

И подал хорошую идею - нужны спецблоки

Надеюсь это никак не связано с концлагерем, для перевоспитания "заблудших" овец? Есть же макросы, что ещё за спец блоки хотите? Может проще добавить наиболее востребованные макросы в ОЛ?!

starmos
12.04.2017, 09:07
Да, мы сделали слишком хороший ПР и теперь страдаем.
Все желания, в конце концов, сводятся к:
Сделайте нам супер среду для программирования, чтобы на ПР влезало не в 20 раз больше, чем на обычной ПР той же цены, а в 100 раз. И еще и приборы продавайте за 3 (лучше 2) копейки.

Действительно, какие ужасные желания - потребители хотят получать качественный продукт, по максимально возможно (!) дешевой цене - просто бизнесужастик какой-то. Кстати Генри Форд когда-то решил что удовлетворение подобных желаний потребителей и есть обязанность (он так считал) бизнеса и заработал миллионы и основал компанию своего имени, которая уже существует 100 лет и вывел в Штаты в лидеры автомобилизма. Но нам подобные идеи не подходят, поэтому мы просто призадушим ПР200, чтобы пользователям не мечталось всякое. Я уже думаю что у ОВЕНа просто случайно получился такой удачный контроллер (контроллер это, это вы его пытаетесь в ПР утрамбовать ногами) и они сами от этого удивились. Добавление возможности программирования на С, ХОТЯ БЫ в виде создания макросов в рамках ОЛ, сразу расширит сферу применения ПР200 и соответственно объем реализации устройств. Но да, формально это уже не будет чистое ПР, а это ересь? А за ересь - жгут, не так ли?

Алексей Геннадьевич
12.04.2017, 09:45
Да, мы сделали слишком хороший ПР и теперь страдаем.
В 3 смены выпускать приходится и всё равно не можете покрыть спрос?:D В таком случае поздравляю: кризис у вас вышел на "отлично".


Все желания, в конце концов, сводятся к:
Сделайте нам супер среду для программирования, чтобы на ПР влезало не в 20 раз больше, чем на обычной ПР той же цены, а в 100 раз. И еще и приборы продавайте за 3 (лучше 2) копейки.
Вы таки и про другие хотелки не забывайте, транзисторные выхода на 2А 24в в модулях расширения ПР200.

Владимир Ситников
12.04.2017, 09:48
Нет, Анатолий, просто человек понял.
С чем его и поздравляю.
За поздравления спасибо.

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

В итоге, гораздо интереснее троллить тех, кто просит "синус" или "ST" или "C" для ПР, чем пытаться выпросить что-то в ПР-ОЛ.

Например, язык "С" в ПР, очевидно, не нужен. Язык "ST", очевидно, нужен, но теперь он пойдёт за компанию с "C" под эгидой "Москва для москвичей", то есть "ПР для FBD".
А уж зачем запихивать синус в реле -- отдельный вопрос. Ещё бы гиперболические синусы просили...

rovki
12.04.2017, 10:08
А уж зачем запихивать синус в реле -- отдельный вопрос. Ещё бы гиперболические синусы просили...
Так делали же мы солнечные часы ,там и использовали ,что бы освещением управлять -делов то .Не ПЛК же ставить что бы лампочку зажечь .

Филоненко Владислав
12.04.2017, 10:27
Действительно, какие ужасные желания - потребители хотят получать качественный продукт, по максимально возможно (!) дешевой цене - просто бизнесужастик какой-то. Кстати Генри Форд когда-то решил что удовлетворение подобных желаний потребителей и есть обязанность (он так считал) бизнеса

Таки Генри Форд при попытке потребителя заказать Форд Т любого не чёрного цвета посылал его в пешее эротическое путешествие. И заработал миллионы. А 99 % всех кастомных гаражей по запиливанию авто по желанию клиента канули в лету. 1% отказался от удовлетворения желаний клиента, загнал его в стойло (с опциями за дикие деньги) и тоже заработал миллионы.

Покажите мне на рынке качественный продукт за дешёвую цену. Овен тут уникум - но у всего есть пределы. Добавление функционала макросов на С (чтобы клиент сэкономил 5к) стоит несколько миллионов - либо увеличиваем цену, либо кто-то выступает спонсором.

Scream
12.04.2017, 10:45
Добавление функционала макросов на С (чтобы клиент сэкономил 5к) стоит несколько миллионов - либо увеличиваем цену, либо кто-то выступает спонсором.

;) несколько...
А как именно клиент сэкономит 5к? Есть возможность сейчас что-то докупить за 5к?
У компании на ПР200 один клиент?
Что за детские подсчеты?

Eugene.A
12.04.2017, 10:52
Есть ещё пример успешной компании, которая забивает на хотелки потребителей. Она просто создала религию и в качестве идолов выставила пастве свои продукты. И тогда любой глюк по воле богов превращается в фичу.
Идеология давно оседлала экономику. Рулят всем дизайнеры и менеджеры с экономистами. Лозунг "Спрос рождает предложение" давно устарел. Предложение первично. Создайте предложение, а спрос мы вам обеспечим, мобилизовав маркетологов и рекламщиков.
А мнение инженеров, проектировщиков, конструкторов, экспертов никого не волнует. Дизайнер создаёт облик продукта, а уж мотор в этот продукт инженер из кожи вылезет, а запихает.
https://www.youtube.com/watch?v=UoKlKx-3FcA
А уж то, что продукт получился одноразовым, не подлежащим ремонту - так ведь и задумывалось? Да и сервисы кормить надо. Вот и появляются авто, в которых для замены лампочки в фаре надо снять колесо, подкрылки, поднять машину на подъёмнике, изогнуться червяком и вслепую, весь измазавшись и ободрав пальцы, вытащить наконец злосчастную лампочку. Один маленький прогноз - скоро и лампочки будут чипованные, чтобы левые не подходили к правой фаре.
И смартфоны вспыхивают в кабине пилотов по этой же причине. Ну не тянет батарейка все хотелки, которые туда запихали.
Хотите и ПР довести до этой кондиции? Чтобы было семь красных перпендикулярных линий, но одна зелёная?

starmos
12.04.2017, 11:11
Таки Генри Форд при попытке потребителя заказать Форд Т любого не чёрного цвета посылал его в пешее эротическое путешествие. И заработал миллионы. А 99 % всех кастомных гаражей по запиливанию авто по желанию клиента канули в лету. 1% отказался от удовлетворения желаний клиента, загнал его в стойло (с опциями за дикие деньги) и тоже заработал миллионы.

Покажите мне на рынке качественный продукт за дешёвую цену. Овен тут уникум - но у всего есть пределы. Добавление функционала макросов на С (чтобы клиент сэкономил 5к) стоит несколько миллионов - либо увеличиваем цену, либо кто-то выступает спонсором.

Посылал, да. Но постоянно снижал цену, без ухудшения качества. У вас БЫ тоже получилось - аппаратно все ведь есть уже и даже серийно выпускается. Вон народ постоянно поминает синусы - кому-то надо значит. Причем кому-то надо одинарной точности, кому-то двойной, а кто-то и таблицей обойдется, зато быстро - понапишете блоков в ОЛ? А ведь есть еще и тангенсы... Да, может большинству и не понадобится эта возможность, если им даже не удается объяснить зачем она. Суть в том, что те, кому она МОЖЕТ понадобится тут на форуме в основном не присутствуют, т.к. даже не смотрят на ПР200 из-за специфического языка программирования. Сколько народу пишет на Arduino? На С пишут в основном. Приколхозивают эту штуку везде, где можно - может они обратили бы внимание? "Arduino - это несерьезно, это не промышленное изделие, ростехнадзор бла-бла." Подобные разговоры бессмысленны как ветер, потому что это снобизм ни на чем не основанный, как и разговоры что какой-то язык программирования лучше или хуже. Потому что ВСЕ процессоры работают с машинными кодам, а уж из чего их получать - не суть важно. И историю с Arduino я привожу как показательный пример - аппаратура стоит дешево, оболочек под разные языки уже понаписали тучу и людям не потребовались миллионы, ни несколько, ни сколько - ЭТО ЧУДО, воистину. Вы всерьез сообщаете что разработка даже всего ОЛ с нуля стоила несколько миллионов? Мне кажется вы переплатили.
Опять вернусь к Arduino, извиняюсь - ваш процессор, стоящий в ПР200, аналогичен одному из вариантов упомянутого Arduino, который естественно поддерживается (или поддержка планируется) всеми оболочками, в том числе и с языками LD, FB и т.д. Т.е. просто даже доработав прошивку ПР200 до совместимости, вы сразу получаете все эти ID безвоздмездно, т.е. ДАРОМ. А если свяжетесь с автором и дадите ему подзаработать, то он свою оболочку под вас заточит дополнительно и это не будет стоить несколько миллионов даже в сумме. Это конечно "не промышленный подход", но тем кто об этом подумал, я сразу же хочу сказать, что процессору ПР200 начихать на все "подходы" оптом - он просто тупо выполняет свой машинный код и он весь для него одинаков. Это все были рассуждения на тему, если что. По вашим расценкам на разработчиков, наверное на пару сотен тысяч рублей вышло?

ASo
12.04.2017, 11:20
Намек - почему ОВЕН для ПЛК взял чужую среду разработки, башляя за каждую лицензию в каждый экземпляр ПЛК, а не написал свою? Сколько стоит адаптировать РТ КДС для конкретной модели ПЛК в человеко-часах?

Алексей Геннадьевич
12.04.2017, 11:30
"Arduino - это несерьезно, это не промышленное изделие, ростехнадзор бла-бла." Подобные разговоры бессмысленны как ветер, потому что это снобизм ни на чем не основанный,
Долгие и напряжённые беседы в прокуратуре и Ростехнадзоре предстоят вам в случае всяких "форсмажоров" с оборудованием.
Вам там и за снобизм, и за сертификацию с промбезопасностью пояснят максимально развёрнуто.
В тяжёлом случае предоставят помещение для круглосуточной непрерывной медитации на N лет.
Вам не доводилось беседовать с конструктором, который там имел аудиенцию из-за несчастного случая на разработанном им оборудовании?

Newcomer
12.04.2017, 11:30
Например, язык "С" в ПР, очевидно, не нужен. Язык "ST", очевидно, нужен

Для С не надо делать компилятор, можно взять готовый. Для ST надо делать компилятор, а это дополнительные расходы, связанные с разработкой и тестированием.

Есть такие ПЛК EVCO. По конструктиву и техническим характеристикам очень похож на ПР200. Этот ПЛК можно программировать на FBD и С. Стоит этот ПЛК в 2 раза дороже ПР200.

Владимир Ситников
12.04.2017, 11:35
Для С не надо делать компилятор, можно взять готовый. Для ST надо делать компилятор, а это дополнительные расходы, связанные с разработкой и тестированием.

"Есть готовый компилятор" != "компилятор легко встроить в ОЛ"

Да, для C есть готовый компилятор.
Но встроить компилятор в ОЛ -- непростая задача.
Каждый встречный-поперечный будет выходить за границы массивов и спрашивать "у меня простейшая программа не работает".

Интеграция по p-code в этом плане гораздо безопаснее и одновременно с этим дешевле в разработке/поддержке.

Newcomer
12.04.2017, 11:43
"Есть готовый компилятор" != "компилятор легко встроить в ОЛ"

Да, для C есть готовый компилятор.
Но встроить компилятор в ОЛ -- непростая задача.
Каждый встречный-поперечный будет выходить за границы массивов и спрашивать "у меня простейшая программа не работает".

Интеграция по p-code в этом плане гораздо безопаснее и одновременно с этим дешевле в разработке/поддержке.

Все можно сделать при желании, но желания у разработчиков ОВЕН нет. В этом вся проблема.

starmos
12.04.2017, 11:53
Долгие и напряжённые беседы в прокуратуре и Ростехнадзоре предстоят вам в случае всяких "форсмажоров" с оборудованием.


Поясните пожалуйста, в чем состоит принципиальная ущербность Arduino как платформы? Мне очень хочется понять, на чем базируются все эти страшилки про прокуратуру. То что в своем нынешнем виде это неудобно применять в промышленных/ЖКХ установках - это понятно, но это просто вопрос исполнения. Но если выпустить СОВМЕСТИМОЕ устройство в нужном корпусе (его практически уже выпустили - это ПР200)? В чем коренное и фундаментальное отличие?

starmos
12.04.2017, 12:00
"Есть готовый компилятор" != "компилятор легко встроить в ОЛ"

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

Интеграция по p-code в этом плане гораздо безопаснее и одновременно с этим дешевле в разработке/поддержке.

Это просто капец. В ОЛ УЖЕ есть компилятор, потому что ПР200 не исполняет программу в виде квадратиков, но только в виде машинных кодов. А поскольку я не верю, что в ОВЕН писали ОЛ с трансляцией напрямую в машинные коды, то могу предположить что каждому функциональному блоку соответствует подпрограмма в виде текста на С. И вся эта графическая картинка СНАЧАЛА транслируется в С, а ЗАТЕМ, встроенным компилятором, уже в ассемблер и машинные коды.

Ну будут спрашивать и что? Сейчас не спрашивают?

Владимир Ситников
12.04.2017, 12:01
Все можно сделать при желании, но желания у разработчиков ОВЕН нет. В этом вся проблема.

Проблема в другом. Те, кто просят ничего не понимают в программировании, взаимодействии среды с компилятором.

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

Я не говорю "нужно брать плк", я про то, что p-code даже в ПР гораздо проще и надежнее, чем С

Алексей Геннадьевич
12.04.2017, 12:11
Поясните пожалуйста, в чем состоит принципиальная ущербность Arduino как платформы? Мне очень хочется понять, на чем базируются все эти страшилки про прокуратуру.
Нет у ардуино ущербности. Просто это инструмент разработчика. Придумали электронную приблуду, обкатали её на ардуино, потом сваяли печатку,корпус и в массовое производство.
И не страшилки, а реальность. Заказчик всегда дешевле хочет, чтобы себе в кармане денег побольше оставить. А любая авария оборудования будет благополучно скинута на вас. Т.К. у ардуино нет сертификата на промприменение, то с вами даже разговаривать не станут, тем более смотреть блестяще написанный код.



То что в своем нынешнем виде это неудобно применять в промышленных/ЖКХ установках - это понятно, но это просто вопрос исполнения. Но если выпустить СОВМЕСТИМОЕ устройство в нужном корпусе (его практически уже выпустили - это ПР200)?
Уже выпускается. Цена за штуку соответственно, зубастая. Примерно на полведра обычных ардуин.

В чем коренное и фундаментальное отличие?
Наличие промышленного исполнения и сертификата.


Мне так кажется из документации. Отладка там пока не сделана нормально вроде.
И это тоже.
Ардуинщики почему-то пачками под забором не валяются.

starmos
12.04.2017, 12:17
Наличие промышленного исполнения и сертификата.

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

Владимир Ситников
12.04.2017, 12:24
Это просто капец. В ОЛ УЖЕ есть компилятор, потому что ПР200 не исполняет программу в виде квадратиков, но только в виде машинных кодов. А поскольку я не верю, что в ОВЕН писали ОЛ с трансляцией напрямую в машинные коды, то могу предположить что каждому функциональному блоку соответствует подпрограмма в виде текста на С. И вся эта графическая картинка СНАЧАЛА транслируется в С, а ЗАТЕМ, встроенным компилятором, уже в ассемблер и машинные коды.

Ну будут спрашивать и что? Сейчас не спрашивают?

Сейчас про указатели в ОЛ точно не спрашивают. Про указатели в КДС - спрашивают.

Разумеется, пр200 выполняет мышиные коды. Но это не значит, что внутри там именно С.
Да, внутри ОЛ есть компилятор, но это не значит, что встроить компилятор С в среду вообще возможно.

Очень интересно выглядят все эти предложения "давайте С, вон есть море компиляторов". Потом начнётся "а как же онлайн", "а как же замена программы на ходу", и прочее прочее, которое для С сделать не так-то и просто.

Алексей Геннадьевич
12.04.2017, 12:25
Вот и договорились - в самой платформе ущербности нет, а промышленное исполнение и сертификат уже есть у ОВЕН или могут быть им получены. сертифицируется каждое исполнение изделия.


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

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

Newcomer
12.04.2017, 12:44
я про то, что p-code даже в ПР гораздо проще и надежнее, чем С

А что такое p-code ?

Владимир Ситников
12.04.2017, 14:19
А что такое p-code ?



P-код (https://ru.wikipedia.org/wiki/P-%D0%BA%D0%BE%D0%B4) (Пи-код) — концепция аппаратно-независимого исполняемого кода в программировании, часто его определяют как «Ассемблер для гипотетического процессора». Этот термин обычно применяется для обозначения реализаций виртуальной машины для языка Паскаль (например, в UCSD p-System), иногда также используется в качестве синонима термину байт-код для различных виртуальных машин (например, виртуальная Java-машина, байт-код CIL в платформе .NET и т. п.).

Переводя с русского на русский, это промежуточный код. Прямого доступа к железу нет, в результате программа получается надёжнее, и её проще переносить с одной платформы на другую.

starmos
12.04.2017, 14:32
в результате программа получается надёжнее, и её проще переносить с одной платформы на другую.

Было условно: программа -> С -> машинный код.
Стало: программа -> p-code -> C -> машинный код.
Каждая -> это соответствующий компилятор, увеличение объема программы и ухудшение быстродействия (за счет ухудшения оптимальности), а также возможность ошибок.
Программа определенно не станет надежнее, а переносить её - куда? У вас уже есть "p-code" - это тот язык, на котором написаны функциональные блоки.

Владимир Ситников
12.04.2017, 14:46
Было условно: программа -> С -> машинный код.
Стало: программа -> p-code -> C -> машинный код.
Каждая -> это соответствующий компилятор, увеличение объема программы и ухудшение быстродействия (за счет ухудшения оптимальности), а также возможность ошибок.
Да, стрелки примерно такие, но цепочка "p-code -> C -> машинный код" делается 1 раз и именно она зашивается в прошивку.
Т.е. ПР умеет выполнять p-code, и для ОЛ не приходится связываться с C и мышиными кодами. В ОЛ остаётся более простая операция "FBD -> p-code".



Программа определенно не станет надежнее, а переносить её - куда? У вас уже есть "p-code" - это тот язык, на котором написаны функциональные блоки.
Да хоть бы между разными ПР переносить.
ПР200 и ПР114 это разные платформы.

starmos
12.04.2017, 15:01
Да, стрелки примерно такие, но цепочка "p-code -> C -> машинный код" делается 1 раз и именно она зашивается в прошивку.


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

melky
12.04.2017, 15:05
starmos а вы считаете что с выходом новой версии ОЛ сейчас не так ?, не замечали, что ОЛ меняет прошивку ПР и иногда разработчики выкладывают без серьезной проверки версии, что народу приходится откатываться ?

starmos
12.04.2017, 15:08
Я думаю это не сознательная политика, а просто следствие переходного периода. В идеале внутренняя прошивка должна меняться реже, чем версии ОЛ.

Newcomer
12.04.2017, 15:50
Переводя с русского на русский, это промежуточный код. Прямого доступа к железу нет, в результате программа получается надёжнее, и её проще переносить с одной платформы на другую.

Текстовый язык какой будет ?

melky
12.04.2017, 15:57
starmos а она и меняется реже, иногда же исправляют ошибки самого ОЛ или дорабатывают интерфейс, а иногда дела касается и сам ПР, тогда идет смена прошивки

Владимир Ситников
12.04.2017, 16:03
Текстовый язык какой будет ?

???

В чём вопрос? В ПР, наверное, никогда текстовых языков не будет, ведь "Слава КПСС", т.е. "Слава FBD!"

А исходная мысль была в том, что к p-code можно прикрутить хоть какой язык. Хоть FBD, хоть ST.

ASo
12.04.2017, 18:35
Можно. Сколько это займет человеко-часов?

Newcomer
12.04.2017, 19:18
Можно. Сколько это займет человеко-часов?

Смотря кто делать будет. У людей со светлыми головами много времени не займет. ИнСАТ работу заказать, быстро сделают.

Newcomer
12.04.2017, 19:20
А исходная мысль была в том, что к p-code можно прикрутить хоть какой язык. Хоть FBD, хоть ST.

ST надо с нуля делать, Операторы, встроенные функции, прочее. Много времени уйдет на разработку и тестирование.

Владимир Ситников
12.04.2017, 19:29
Можно. Сколько это займет человеко-часов?

Основной вопрос не "сколько займёт прикручивание ST к p-code", а "сколько у ОВЕН займёт прикручивание p-code к ОЛ-ПР".
Прикрутить p-code к ОЛ (например, сделать ОЛ-блок с полем ввода IL программы, или ОЛ-блок куда вставляется прямо base64 p-code) и задокументировать не должно быть сложной задачей.

Ну, допустим, программист думает недели полторы над форматом хранения-обмена этим самым p-code.
Потом 3 дня добавляется новый блок с полем ввода для p-code в ОЛ.
Потом неделю делается загрузка из этого формата (распознавание вставленной программы в понятное ОЛ представление)
Потом ещё неделя на запись p-code в *.owl.
Потом ещё неделя на скрещивание нового блока с имеющимся в ОЛ компилятором.
Потом ещё неделя на скрещивание нового блока с имеющейся в ОЛ симуляцией.
Потом документатор документирует. Допустим, это тоже неделя (там писать-то день или два, но попутно будет тратиться время программиста на пояснение, поэтому пишем суммарно неделю).

Итого 7 мифических человеко-недель = 1.5 (формат) + 0.6 (блок) + 1 (чтение) + 1 (запись) + 1 (компилятор) + 1 (симуляция) + 1 (документация)

Без понятия какая компенсация в ОВЕН, но грубо можно оценить как 400 т.р. == 200 т.р. (со всеми налогами) * 2 мес


Прикручивание же ST к p-code можно вообще за пределами ОВЕН делать.
Реальный пример: лично я прикрутил ST к управлению быстрыми входами-выходами ПЛК110. Суммарно работы заняли менее месяца на выходных.

ASo
12.04.2017, 19:45
Ну да, ну да....
И что же ОВЕН никак не может прикрутить новые CDS SP к СПК? А Инсат на 2..3 года(!) задержал выход МС4, которая и сейчас "сырая"?

Владимир Ситников
12.04.2017, 20:27
Ну да, ну да....
Ну, да.

Hardella работает, а варианта от ОВЕН (или ещё кого-то) на горизонте не видно.

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


И что же ОВЕН никак не может прикрутить новые CDS SP к СПК?
А как это относится к ОЛ-ПР?
Как-никак, на КДС ОВЕН вряд ли имеет ощутимое влияние.
Работать же "со своим p-code" должно быть гораздо проще.


А Инсат на 2..3 года(!) задержал выход МС4, которая и сейчас "сырая"?
Так программа МС4 посложнее, чем p-code блок для ОЛ.

ASo
12.04.2017, 20:48
Генератор p-code из ST кто напишет?

По поводу альтернативы Харделлы. Видимо, никому не нужны быстрые входы-выходы. Это стандартно. Многие кричат "сделай", как сделают - нужно единицам.

Newcomer
12.04.2017, 21:03
Генератор p-code из ST кто напишет?

По поводу альтернативы Харделлы. Видимо, никому не нужны быстрые входы-выходы. Это стандартно. Многие кричат "сделай", как сделают - нужно единицам.

Землекопу точно не надо,;) а кому-то очень даже надо, например мне. В.Ситников сделал большое и важное дело. Альтернативы Hardella действительно нет.

Филоненко Владислав
12.04.2017, 21:27
Это просто капец. В ОЛ УЖЕ есть компилятор, потому что ПР200 не исполняет программу в виде квадратиков, но только в виде машинных кодов. А поскольку я не верю, что в ОВЕН писали ОЛ с трансляцией напрямую в машинные коды, то могу предположить что каждому функциональному блоку соответствует подпрограмма в виде текста на С. И вся эта графическая картинка СНАЧАЛА транслируется в С, а ЗАТЕМ, встроенным компилятором, уже в ассемблер и машинные коды.

Ну будут спрашивать и что? Сейчас не спрашивают?

Это не капец, а незнание архитектуры ПО ПР. Нет там никакого транслятора в машинные коды. Добавить макросы на С===переделать ПР полностью, включая и прошивку и среду разработки.

smk1635
12.04.2017, 21:29
Пока мы не освоим микропроцессорный язык микроконтроллеров так и будим плестись в хвосте и выискивать баги и ждать новых версий. Как уже сказали выше что ПР200 очень удачное решение но есть ограничение по ОЛ это правда. Нужно открыть второе дыхание популярности, это открыть возможность работы на микроконтроллерном уровне, нужен физический старт а далее пойдет все своим чередом. Линукс тоже делался на энтузиастах.

Угу. А потом, в случае чего, заказчик, да же имея на руках исходный код программы, будет судорожно метаться в поисках кто бы мог разобраться в коде. Попутно твердо уверовав, что ПР200 ни куда не годится.
Вот зачем это Овен?

Владимир Ситников
12.04.2017, 21:53
Генератор p-code из ST кто напишет?

А хоть кто.
Вполне возможно, прямо в p-code напишут. Точно так же, как сейчас "из спортивного интереса" рисуют ОЛ картинки на 1000+ элементов.

Ну и диадемовая черепаха, в конце концов, чем плоха?



По поводу альтернативы Харделлы. Видимо, никому не нужны быстрые входы-выходы. Это стандартно. Многие кричат "сделай", как сделают - нужно единицам.

Я пример приводил к тому, что много кто говорил, что "мой подход нерабочий". По факту же, подход оказался рабочий.
Так и тут: много кто говорит, что нужно много миллионов и вообще невозможно, а вариант с p-code может оказаться вполне рабочим. Вариант с C, разумеется, и рассматривать смысла нет.


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

Вот текущая Яндекс Метрика черепахи (19 декабря это дата запуска сайта):
30521