rwg что-то вы погорячились с 1 мс, у меня программа 5 мс по времени работает если верить индикатору ПР200.
я за то, чтобы сами макросы для ОЛ можно было бы писать на С# и подключать их к базе макросов.
мечты, мечты.....
rwg что-то вы погорячились с 1 мс, у меня программа 5 мс по времени работает если верить индикатору ПР200.
я за то, чтобы сами макросы для ОЛ можно было бы писать на С# и подключать их к базе макросов.
мечты, мечты.....
Овен Лоджик работает как работает. P-code, о котором Вы так мечтаете - это те же квадратики, но в виде потока байт. За счёт супероптимизации процентов 10, наверное, выжать удастся по производительности.
У нас и так самый быстрый ПР среди конкурентов.
А шаг ниже - это писать свою программу на С и ASM и прошивать её в STM-ю отладку.
Никаких коварно скрываемых от общественности суперформатов загрузки не существует.
По-моему, вы смотрите со стороны разрабочика ОЛ. Да, для разработчика ОЛ шаг ниже это C или бинарный код STM.Цитата:
Сообщение от Филоненко Владислав
Но для общественности доступны лишь "квадратики ОЛ, которые нужно таскать мышкой".
Для общественности, p-code это и есть тот самый нужный "шаг ниже". Большинству этого самого p-code должно хватить.
Смысл не в "супероптимизации производительности", а в том, чтобы просто иметь возможность генерировать программы для ПР в сторонних редакторах.
Понятно, что соединить вход с выходом в ОЛ проблем не составляет. А, например, записать формулу уже непросто.
О, где можно почитать/попробовать ОЛ p-code?Цитата:
Сообщение от Филоненко Владислав
Цитата:
Сообщение от Филоненко Владислав
В некоторых случаях - массивах например, можно получить и прирост производительности, и уменьшение размера кода.Цитата:
Сообщение от Владимир Ситников
Согласен с автором темы относительно вставки макросов, написанных на ST (или на С). Более-менее серьезные проекты на ПЛК у меня ну никак не обходятся без ST, - те же формулы, или мозго-выносящие ветвистые условия. Просто, в данной ситуации написать пару-тройку строк кода гораздо менее трудоемко, чем воротить все это на FBD. Планировал серьезно применять ПР200 в вентиляции и кондиционировании - платформа и возможности довольно серьезны для этого, НО. Написать что-то стоящее в ОЛ в данном случае, конечно, можно, но человеко-часов я на это затрачу просто уйму! И это не допустимо, потому что, в основном, все решает время. Да-да, последний пример: срочно сделать штучный заказ для нестандартной приточной установки. Если бы в ОЛ была возможность вставки хоть примитивного ST, как, например, в 1Tool у Carel, не задумываясь бы взял ПР200 (очень нравится). А так, :confused: заказал pCOxs с панелькой за 38k. И только из-за отсутствия ST в Лоджике, и отсутствия времени у меня.
Конечно, я понимаю, реализация ST тянет за собой серьезные вложения в разработку IDE Лождик, но в этом случае ПР200 добавил бы себе еще какое-то количество потребителей, это уж точно.
Так это не проблема ОЛ ,скорее ваша ,потому как ОЛ делался для электрошиков ,для которых ваши проблемы вообще не проблемы .Кто на что учился .А так берите ПЛК 63 и все (не считая цены,но ОЛ в этом не виноват) будет быстро у вас .Цитата:
Сообщение от AlexP
Вода камень точит. Кончится тем, что появится возможность программировать ПР "ОВЕН" и на ST. rovki и "электронщики" буду продолжать программировать в ОЛ, а у более продвинутых пользователей появятся альтернативные возможности. Дали бы волю В.Ситникову все бы давно было сделано.Цитата:
Сообщение от AlexP
Интегрировать C и ОЛ намного сложнее, чем какой-нибудь p-code / IL и ОЛ.Цитата:
Сообщение от Адрей
Программировать ПР/ПЛК на C вряд ли будет много желающих.
И уж вряд ли будут желающие вообще весь стек с нуля создавать (ну, на C писать работу с 485, симулятор, online, загрузку программы и т.п.)
Сколько тут умельцев, способных и желающих написать свою прошивку для ПР? Ни-ко-го.
Разве что ради развлечения/хобби.
Поэтому я и говорю, что нужно не STM-32 на C программировать, а делать так, чтобы в ОЛ можно было добавлять программы-макросы, написанные на p-code / IL.
Разумеется, IL программы не вручную писать, а каким-нибудь генератором (компилятором). Например, пишем на ST -- получаем IL, вставляем IL в ОЛ.
Для кучки продвинутых ,которым не хватает денег купить плк63 (12тр) и которые хотят получить альтернативные возможности -то же самое за 6тр ,следует знать что все дополнительные затраты (при бесплатности ОЛ) лягут на цену ПР200 или размажутся на все изделия (скорее всего) ...Халявы бесплатной нет уже давно и это следует знать продвинутым в этой области пользователям.При скрещивании божей коровки и мухомора(внешне похожи) не следует надеятся на здоровое потомство.;)Цитата:
Сообщение от Вольд
Вопрос неправильно поставлен.Цитата:
Сообщение от Владимир Ситников
Правильный вопрос - нафига?
1)Приключений себе на задницу найти можно и более простыми способами.
А если так припекло, то:
2)Сравниваем цену на отладочную плату STM и ПР-200.
3) в промышленности "самопал" недопустим.
Читаем между строк или как?Цитата:
Сообщение от Алексей Геннадьевич
Я же и говорю: никому не впилось программирование ПР на C.
Переводя с русского на русский: прошивка ПР от ОВЕН, а прикладной код на IL. Разумеется, в IL не должно быть возможностей прямого доступа к памяти/портам ввода-вывода, а только оговоренный перечень инструкций.Цитата:
Сообщение от Владимир Ситников
Безопасность кода сохраняется, и всё норм.
Тема "Модули расширения для ПР200" длится примерно эти самые 1-2 года и ничего.Цитата:
Сообщение от Адрей
Поэтому никуда за эти 1-2 года прогресс не сдвинется. Как есть сейчас ПР+ОЛ, так и останется. Как сейчас полезна возможность IL в ОЛ, так и через год-два никуда потребность не денется.
Ну, разве что конкуренты сделают.
Это минус.Цитата:
Сообщение от Филоненко Владислав
Но тема располагается в разделе "Среда программирования OWEN Logic" и ждёт часа, когда на неё обратит внимание тот, кто разрабатывает ОЛ-ПР.
Вы бы для начала лог загрузки пары проектов, выложили. там И два входа на выход, ИЛИ два входа на выход. Может быть и понятней стало, как там загрузка происходит. А Овен это делать точно не будет, тогда ПР будут мешать продажи ПЛК. (и прибыль упадет 100%)
Для начала бы сделал ,что сделал Сергей -автор FLprog .Вот где поле деятельности для программистов http://flprog.ru/forum/1...
Алексей Геннадьевич приводил пример, когда p-code ускорит выполнение ОЛ программ -- массивы:Цитата:
Сообщение от Филоненко Владислав
Ещё один пример -- условные переходы. Сейчас ОЛ программа вся целиком выполняется, а с условным переходом можно пропускать ненужный на текущем этапе код.Цитата:
Сообщение от Алексей Геннадьевич
Конечно, если "архитектура ПР-ОЛ" заключается в том, чтобы ОЛ было унылым, и ПР медленным, то да, действительно такая "архитектура" не позволит ничего сделать.
Неужели действительно архитектура ПР-ОЛ заточена под то, чтобы для ПР было невозможно программировать?
Под программировать я имею ввиду сделать макрос "ПИД с автонастройкой", "вычислить логарифм", "вычислить квадратный корень".
Русским языком же сказано - делайте макросы ,если будут хорошие и популярные разработчики встроят в код .Вот и возьмитесь сделать адаптивный ПИД регулятор на том что есть (один раз по мучайтесь ).В принципиальных электрических схемах нет условных переходов и не чего ...
Русским языком говорю: если нечего сказать -- мимо темы.Цитата:
Сообщение от rovki
Полагаю, вы не понимаете, что макрос логарифма, написанный в ОЛ, и "нормальный макрос логарифма", который можно "встроить в код" это совершенно разные вещи.Цитата:
Сообщение от rovki
Поэтому нужно понимать, что существование макроса "адаптивного ПИД" никак не поможет добавлению в ОЛ нормального "адаптивного ПИД". Его всё равно придётся переделать на нормальном языке программирования.
Должны же понимать, что ОЛ не на электрических схемах пишется?Цитата:
Сообщение от rovki
Должны же понимать, что ПР не на электрических схемах работает? Да, да. Программа выполняется STM процессором, и ни о каких "электрических схемах" (нарисованных в ОЛ) этот процессор не думает.
У него есть набор инструкций и он по очереди их выполняет. Переходы у него есть. Как условные, так и безусловные.
Зачем же электрические схемы приплетать сюда?
К текущей теме схемы никак не относятся, а лишь намекают на неграмотность.
Да как вы не понимаете ,что речь идет о пользователях,а не процессорах ,для них работа в ОЛ должна быть как с железом .Козе понятно ,что все реализуется программно ,а значит последовательно.Поэтому без намеков говорю - Королева из вас не получится никогда ,в лучшем случае Эйнштейн :rolleyes: или Прокурор.Цитата:
Сообщение от Владимир Ситников
И то что будет сделан ПИД в ОЛ не то же самое ,что реализация его в библиотеке ,то же всем понятно. Просто нужна реализация для понятия и отладки алгоритма ,а уж потом реализовать его на любом языке нет проблем .
Да, сейчас для ПР программы можно составлять только через ...барабанная дробь... рисование схем.Цитата:
Сообщение от rovki
Поймите же наконец, что смысл текущей темы и состоит в том, чтобы расширить эти границы. Кто-то по-прежнему будет рисовать схемы, а кто-то будет использовать и более удобные языки.
Вы хоть 100500 раз можете сказать, что "в ОЛ обязательно работа должна быть как с железом", но эти слова ничего не стоят.
Я предлагаю, что должна быть возможность создавать ОЛ макросы-программы и на нормальных языках. Я приводил случаи, когда схемный подход крайне плох (автонастройка, логарифм, массивы, итеративные вычисления и т.п.). Я учитываю, что оба подхода должны будут как-то вместе сосуществовать (если делать по-нормальному, то никаких проблем не будет), и, опять же, там не потребуются космические вливания в разработку/поддержку/документирование ОЛ.
Не нужна. Отлаживать можно и нужно на любом нормальном языке программирования. Делать автонастройку через ОЛ схемы можно либо от безысходности (прямо нужно на ПР, а в ОЛ нормальных средств нет), либо из идейных соображений (кто-то любит кроссворды решать, а кто-то загогулины в ОЛ рисовать).Цитата:
Сообщение от rovki
Если же нужен нормальный промышленный алгоритм (проверенный, рабочий, и т.п.), то делать его в ОЛ схемах подобно смерти.
Я уже много раз говорил, что ОЛ схемы не поддаются тестированию, и сейчас повторю: даже, если кто-то и сделает "макрос автонастройки ПИД", то его невозможно будет проверить. Вдруг через N часов работы там какая-нибудь ошибка окруления накопится? А вдруг он вразнос пойдёт?
Вот найдётся кто-то "идейный", который сделает "макрос автонастройки ПИД". Макрос возьмут и взорвётся объект. Вот здорово будет.... В ОЛ физически нет возможности сделать тест этого самого ПИД регулятора. Вручную что-ли на вход подавать "температуру печи" и щёлкать выполнение "одного цикла"? Тестировать нужно не один сценарий, а много. Тестировать нужно и ошибки датчиков. По-хорошему, при любой модификации алгоритма нужно заново всё перепроверять.
Был уже один, который утверждал, что "в железе законы математики не действуют". Так вот. Смоделировать автонастройку ПИД можно и нужно это делать без всяких мучений с ОЛ.
Более того, при моделировании на нормальном языке, можно сразу в модель подавать разные условия на вход, и сразу видеть как поведёт себя система.
В общем, rovki в руководители проекта разработки софта не годится.
В руководители "рисования схем" -- не исключаю. А к разработке софта (и руководству разработкой) уж точно допускать нельзя.
PS. Понятно, что тема никак не про обсуждение rovki. Тем не менее, некоторые проецируют "о, rovki, это тот, на чьих макросах 100500 проектов построено, значит он дело говорит, а Владимир Ситников никак понять не может". Поэтому и подчёркиваю, что опыт rovki в составлении схем никак не делает ему авторитета в текущей теме (которая больше про "доработку ОЛ" и про "управление проектами разработки софта")
Вы напрасно считаете пользователей ПР дураками.Цитата:
Сообщение от rovki
Любой нормальный инженер АСУ сегодня умеет программировать порой лучше тех, кто учился на программиста.
И если некому пользователю важно, чтобы программирование автоматики было сродни сбора релейной схемы, ему стоит подумать о том, что его призвание - электромонтер или слесарь КИП, а не АСУшник :)
Просто это ПР. РЕЛЕ!Цитата:
Я приводил случаи, когда схемный подход крайне плох (автонастройка, логарифм, массивы, итеративные вычисления и т.п.).
Для таких вещей есть иные системы.
Я понимаю, национальная особенность - есть микросхема - возьми с нее 100% функционала. А лучше 101% Но в целом мир живет по другому.
Так и используйте ,то что вам лично удобнее -ПЛК с кодесис с 5 языками.Границ нет ,есть желание получить ПЛК по цене ПР и все .А ПР оставьте тем кому удобнее схемы рисовать .Вы что же думаете схемы ПК и смарт тиви программисты делают или уже систем с жесткой логикой нет ,особенно в военной технике .Цитата:
Сообщение от Владимир Ситников
Батенька ,вы о чем (о ком) .Ключевое слово Сегодня ,а за долгое время подготовлены миллионы схемотехников .Электронщиков ни как не меньше чем программистов .Электронщики это не те кто схемы Рисует ,а те кто алгоритмы реализует в железе (жесткая логика) и где даже процесс отладки отличается от процесса отладки программы.И принцип работы другой (параллельный) .Для них и сделано ПР .Если ,как пишет Ситников ,работать в ОЛ не удобно и не безопасно,а люди делают проекты замечательные не смотря на это ,то они значит умнее тех кому легко .Цитата:
Сообщение от anthrwpos
В результате получим контроллер с поддержкой МЭК языков и конским ценником.Цитата:
Сообщение от Владимир Ситников
"Конский ценник" поставит крест на нишевом применении ПР. Что я буду логарифмировать в конечном автомате, который работает на дискретных сигналах?
Онлайн-режим для этого намного полезнее.
Нужно правильно оборудование подбирать соответственно выполняемой задаче.Цитата:
Вот найдётся кто-то "идейный", который сделает "макрос автонастройки ПИД". Макрос возьмут и взорвётся объект. Вот здорово будет.... В ОЛ физически нет возможности сделать тест этого самого ПИД регулятора. Вручную что-ли на вход подавать "температуру печи" и щёлкать выполнение "одного цикла"? Тестировать нужно не один сценарий, а много. Тестировать нужно и ошибки датчиков. По-хорошему, при любой модификации алгоритма нужно заново всё перепроверять.
А что-нибудь взорвать всегда помогут. В Чернобыле и Фукусиме с этой задачей справились на "отлично", несмотря на всю защитную автоматику.
Это как?:confused:Цитата:
Был уже один, который утверждал, что "в железе законы математики не действуют".
Можете пояснить?
О, да, слова "конский ценник" всё объясняют.Цитата:
Сообщение от Алексей Геннадьевич
Применю к вам ваши же аргументы: "если добавить онлайн-режим, то конский ценник поставит крест на нишевом применении ПР". Каково?
Да, вы безусловно правы. Если добавить поддержку всех МЭК языков в ОЛ, то цена будет прямо как от космолёта. Но я и не прошу добавлять все языки.
Текущая тема не про МЭК языки для ПР-ОЛ, а про один-единственный "IL язык". Язык, в котором команды тривиальные, расположены по одной на строку и т.п. С его реализацией сложностей быть не должно, учитывая что сам по себе ОЛ уже компилирует в какой-то такой язык свои FBD картинки.
Или речь про то, что "ну, раз ПР-ОЛ можно на IL программировать, то цену-то в 2 раза приподнимем"? По-моему, бред.
Т.е. "ПИД с автонастройкой" это уже за областью применимости ПР?Цитата:
Сообщение от Алексей Геннадьевич
Прямо так, так и было. Пояснил в личку.Цитата:
Сообщение от Алексей Геннадьевич
Вот почему ,вроде тоже (как Ситников) программист Владислав сечет на раз ,а другие продвинутые дальше носа своего не видят ,а потому что одни делают для всех (круг пользователей) ,а другие для себя любимого ,прикрываясь фразами о заботе о других продвинутых пользователей и не думая о последствиях (повышение затрат и цен) ибо это не их товар и не им жить на полученную прибыль или убытки.
Задача была плохо поставлена при разработке ОЛ от того и все последующие проблемы, бесконечные доработки и споры.
Задача была поставлена правильно ,а опыта было маловато .Проблем при использовании ОЛ не было больших ,за исключением переполнения стека.Доработки связаны с увеличением функционала .Вспомним первые версии и последнею -небо и земля .Сменилась платформа и сменился ОЛ ....но он по прежнему поддерживает все платформы и старые проекты -одно это сильно усложнило задачу...Просто одни философствуют ,а другие уже десятки проектов сделали и делают и не нарадуются .
Господа, давайте не устраивать холивар в каждой теме.
Такие темы будут закрываться и убираться в курилку.
Вольд получил бан на 10 дней. starmos получает предупреждение.
Основная логика OL - простая система для широкого круга пользователей. Знакомых с релейкой и работой с шрафическим представлением ФБ. И этого мы, в ближайшее время, менять не планируем.
Однако это не значит, что OL не может развиваться.
Основной язык бесспорно останется FBD. Для основных потребителей данного продукта мы будем продолжать создавать макросы. Включая блоки для вентиляции, управления насосами, ПИД и т.д.
Но добавление редактора для создания макросов на Си подобных языках обдумаем. Большое спасибо за идею.
Для тех, кто больше двух дней читает умные книжки, кому за это платят и есть на это время - всегда готовы предложить ПЛК на CODESYS. На st писать - не переписать. Да и расширенный SFC, на мой взгляд, может дать фору Дракону.
Архитектура и заложенные технические решения кроют ТЗ на ПР раз так в 200.Цитата:
Сообщение от rovki
Именно по этому тут и разразился холивар. Мы сделали слишком хороший (а с современными процессорами) и быстрый ПР - и теперь некоторые хотят из него сделать ПЛК. Задёшево.
В отчете не забыть 146% указать.:)Цитата:
Сообщение от ASo
Возможно и так.Цитата:
Сообщение от Владимир Ситников
Делать это или нет - зависит от стратегии производителей.Цитата:
Текущая тема не про МЭК языки для ПР-ОЛ, а про один-единственный "IL язык". Язык, в котором команды тривиальные, расположены по одной на строку и т.п. С его реализацией сложностей быть не должно, учитывая что сам по себе ОЛ уже компилирует в какой-то такой язык свои FBD картинки.
Пусть его производители пишут и тестируют.Цитата:
Т.е. "ПИД с автонастройкой" это уже за областью применимости ПР?
Мне своего макроса PID с блоком АНР хватает.
ПР200 безусловно хорошее программируемое реле, а когда выйдет весь сортамент блоков расширения - станет ещё лучше.Цитата:
Сообщение от Филоненко Владислав
Вся соль.Цитата:
теперь некоторые хотят из него сделать ПЛК. Задёшево.
Соль, видимо, в том, что часть специалистов пришли в АСУ из программистов на С, и схемы для них - чужое. Вот в недалёком будущем понабежит программистов 1С и баз данных, сокращаемых из банковской сферы и бухгалтерий предприятий, вот тогда начнётся! Будут требовать внедрить в ПР эксель, СУБД.
Я собственными глазами видел сделанный в экселе интернет-магазин и чертежи автомобильного двигателя в вордарте. Правда, можно было быстрее доехать до магазина и отстоять очередь, чем дождаться адекватной реакции от этого интернет-магазина. Зато движок в ворде выглядел отлично - с градиентными заливками, цветной! Правда, сколько времени потратила на него девчонка, делая курсовой - история умалчивает.
Давайте уже закроем эту абсолютно бесперспективную тему.
Никто ничего ни на какой IL язык не компилирует. Точка. ПринцЫп работы ПР радикально иной. :cool:Цитата:
Текущая тема не про МЭК языки для ПР-ОЛ, а про один-единственный "IL язык". Язык, в котором команды тривиальные, расположены по одной на строку и т.п. С его реализацией сложностей быть не должно, учитывая что сам по себе ОЛ уже компилирует в какой-то такой язык свои FBD картинки.
Что бы не отвлекала от дел ... правидныхЦитата:
Сообщение от Филоненко Владислав
Загрузил СТАРЫЙ проект в ПР114 (писался в 51-й) при помощи 99-й версии и все сломалось, хотя ПР обновился до 3.13, залил программу но какие-то нелады с таймерами и чем-то еще.
Разрабы либо не увидели сообщения либо не знаю. У кого есть на руках ПР114-тые попробуйте. Думаю сильно удивитесь.
Скорее всего с делением на ноль. Раньше при делении на ноль получался ноль. В последних релизах NAN и остановка программы.Цитата:
Сообщение от melky
Я например, вообще физик-оптик)Цитата:
Сообщение от Eugene.A
Изучил сперва электронику, а оттуда попал в АСУ)
Схемы для меня - родное, си освоил только как приложение к электронике в программировании прошивки микроконтроллеров. И тем не менее я считаю, что пытаться пародировать схемотехнику при программировании ПР - неудачная затея)
Лучше уж си. Все равно те, кто умеют только релешки крутить никогда не освоят программирование ПР в принципе. По меньшей мере сколько я не знаю релейщиков (в том числе инженеров-релейщиков с огромным стажем), с кем из них не делился своим восторгом относительно ПР-200 никто из них не пожелал ознакомиться с подобным достижением техники)
А я по образованию, вообще инженер по эксплуатации средств связи (факультет Проводная связь), но могу даже на простых радиоэлектронных компонентах, составить схему и рассчитать параметры, хоть усилителя, хоть генератора, хоть приёмника с передатчиком. А вот с иностранными языками проблема, поэтому, хоть КДС, хоть другие языки взять, я выбираю ФБД или СФС.Цитата:
Сообщение от anthrwpos
Если под себя не делают и в припадке не бьются, увидев ПР200/(ну или пофиг какой контроллер) в электрощите-уже хорошо.Цитата:
Сообщение от anthrwpos
Какое интересное утверждение.Цитата:
Сообщение от Адрей
А я-то думал, что язык МЭК берётся тот, на котором данную задачу решить проще всего...
Ой, это я про контроллеры...