Просмотр полной версии : ПР200 и ST
Виктор_К
14.04.2021, 16:40
добрый день! слышал что для ПР будет поддержка ST, это действительно так!? если да, то когда это планируется!?
Виктор_К
15.04.2021, 16:05
я так понимаю, данной информацией никто не владеет! жаль((((
Виктор_К
15.04.2021, 16:26
спасибо, я тоже такое слышал, хотел уточнить, и хотя бы примерные сроки узнать! а то производительности хватает, а функционала не всегда хватает!
Это будет в новой реле. И в ,,старом ПР" этого не будет. PS. Не ждите что это будет Аля кодесис. Максимум простая математика внутри макроса.
Ревака Юрий
16.04.2021, 08:51
... а то производительности хватает, а функционала не всегда хватает!
А можно узнать чего ждете от ST, и чего именно не хватает?
добрый день! слышал что для ПР будет поддержка ST, это действительно так!? если да, то когда это планируется!?
ПР ОВЕН никогда не будет поддерживать ST. ;)
Андрей Посохов
16.04.2021, 10:24
ПР ОВЕН никогда не будет поддерживать ST. ;)
ПР ОВЕН будет поддерживать ST :)
Работы уже начались. По срокам будет известно позднее.
Первым этапом сделаем написание макросов на ST, а дальше будем расширяться.
Очень хотелось бы от всех услышать, какой функционал и в каком виде хотели бы видеть в рамках ST?
ПР ОВЕН будет поддерживать ST :)
Работы уже начались. По срокам будет известно позднее.
Первым этапом сделаем написание макросов на ST, а дальше будем расширяться.
Очень хотелось бы от всех услышать, какой функционал и в каком виде хотели бы видеть в рамках ST? Да для начала хотя бы арифметику, а далее хотелок накидаем:)
Виктор_К
16.04.2021, 13:48
А можно узнать чего ждете от ST, и чего именно не хватает?
добрый день! наверное основное что мне нужно, это история событий, просто сейчас это очень громоздко( ну и более удобная реализация пошагового управления!
Оператор CASE кране необходим. Лучше сделать так чтобы ПР можно было программировать на трех языках: ST, LD, FBD. Тогда точно ПР ОВЕН не будет равных.
Виктор_К
16.04.2021, 14:04
да и читаемость будет лучше с ST!) просто пр вообще очень удачный продукт, мне кажется самое идеальное сочетание ФУНКЦИОНАЛ+ПРОИЗВОДИТЕЛЬНОСТЬ+КАЧЕСТВО+ЦЕНА!!! если ОВЕН так и будет держать, да еще и st добавит, ему конкурентов не будет!!!!
Первым этапом сделаем написание макросов на ST, а дальше будем расширяться.
Макросы лучше писать не на ST, а на C, ибо можно будет использовать готовый компилятор и библиотеки.
Я бы от радости прыгал, если даже возможность писать макросы появилась на языке высокого уровня. Даже простейшие if (input1 == input2){output1 = 0.65}.
Сейчас так печально переделывать при необходимости эти картинки... Да и наглядность алгоритма отличная. Хотя, может дело привычки.
Вот мне интересно. У нeмца нет ST. У француза нет ST. У электрика нет ST. Даже у японца нет ST. Так зачем это на ПР? Я так понимаю это просят ардуинщики. Бедная служба поддержки. Вас завалят тоннами кода без комментариев и ещё будут требовать разобраться почему этот код не работает.
Виктор_К
17.04.2021, 14:19
Вот мне интересно. У нeмца нет ST. У француза нет ST. У электрика нет ST. Даже у японца нет ST. Так зачем это на ПР? Я так понимаю это просят ардуинщики. Бедная служба поддержки. Вас завалят тоннами кода без комментариев и ещё будут требовать разобраться почему этот код не работает.
а многие только и пишут на ST! и выбирают контроллеры с поддержкой ST или с поддержкой CoDeSys!
Вот мне интересно. У нeмца нет ST. У француза нет ST. У электрика нет ST. Даже у японца нет ST. Так зачем это на ПР? Я так понимаю это просят ардуинщики. Бедная служба поддержки. Вас завалят тоннами кода без комментариев и ещё будут требовать разобраться почему этот код не работает.
да! это важное замечание. желательно написать в инструкции, что ST всегда будетв Beta-режиме и техподдержка запросы по данному языку программирования обрабатывать тоже не будет.
А у других производителей нет ST? потому что на нем нечего писать. такой гибкости в работе с математикой нет ни у кого из них! программируемые реле по функционалу уже подбирающиеся к контроллерам - это чисто "российское чудо". просто за бугром никто не запаривается - хочешь релейкой шлепать вот тебе программируемое реле, хочешь математику, энкодеры, и прочие плюшки - бери ПЛК. все. другого не дано!
Как помню статистику 70%или80% всех ПЛК в мире работают на LD. Программируемые реле в основном на FBD .
Если бы все всегда делали одинаково, никакого развития бы не было.
Сергей0308
18.04.2021, 10:05
Да это пофиг, главное - нормальный текстовый язык.
Вам контроллеров не хватает? Пишите программы для них, я не указываю, просто от этого всем хуже будет, даже Вам, стоимость реле ниже, Вам за аналогичную программу могут меньше заплатить!
Пусть у каждого будет своё поле и он на нём будет "пастись", не надо поля других пытаться захватить, а то люди станут голодными и злыми, боюсь, ни к чему хорошему это не приведёт!
Быть может потому что это статистику делают проекты которые заменяются 1..5 физических реле ? я не про Вас)))
Дураков мало ,что бы из пушки стрелять по воробьям . Кроме того я говорю о том на каких языках работает большенство ПЛК в мире (выпускаются) ,а не о том какие проекты делаются на них . Тут надо быть или законодателем моды или следовать мировой тенденции и не изобретать велосипед (сам же велосипед совершенствовать можно и нужно) ибо неизвестно как сие чудо(мутант) отзовется...
Вот из нескольких источников -
https://controleng.ru/wp-content/uploads/RTEmagicC_ce59630eaf.gif.gif
Встречал , но сейчас не нашел более свежие данные , но тенденция пока такая же .
Вам контроллеров не хватает? Пишите программы для них, я не указываю, просто от этого всем хуже будет, даже Вам, стоимость реле ниже, Вам за аналогичную программу могут меньше заплатить!
Пусть у каждого будет своё поле и он на нём будет "пастись", не надо поля других пытаться захватить, а то люди станут голодными и злыми, боюсь, ни к чему хорошему это не приведёт!
Согласен , как это чудо отзовется не известно . Одно знаю точно ,кто схемы рисует ,тот и будет рисовать дальше (и в макросах) , а кто все жизнь писал ,то будет раздваивать личность (проект делать , плюясь на FDB , а макросы на ST)/ Вот и спрашивается - а стоит ли ограниченные ресурсы (программисты) отвлекать на нескольких пользователей ,для которых ПЛК роскошь (дорого) и хочется перейти на ПР . Если это можно сделать без ущерба для остальных польpователей FBD (под ущербом я имею ввиду - очередные баги , откладывание сроков реализации пожеланий основных пользователей , удорожание итд) , то я не против- есть, так есть...
Дураков мало ,что бы из пушки стрелять по воробьям . Кроме того я говорю о том на каких языках работает большенство ПЛК в мире (выпускаются) ,а не о том какие проекты делаются на них . Тут надо быть или законодателем моды или следовать мировой тенденции и не изобретать велосипед (сам же велосипед совершенствовать можно и нужно) ибо неизвестно как сие чудо(мутант) отзовется...
Вот из нескольких источников -
https://controleng.ru/wp-content/uploads/RTEmagicC_ce59630eaf.gif.gif
Встречал , но сейчас не нашел более свежие данные , но тенденция пока такая же .
Это американский рынок, американская школа. Ну, и страны их инженерной школы.
Европейская школа ближе к ФБД, как бы они не назывались.
Как помню статистику 70%или80% всех ПЛК в мире работают на LD. Программируемые реле в основном на FBD.
https://controleng.ru/wp-content/uploads/RTEmagicC_ce59630eaf.gif.gif
Ерунду про то, что 70% или 80% всех ПЛК в мире работают на LD писать не надо.
То что представлено в диаграмме надо понимать так: в 2007 г. в 95% производимых в мире ПЛК была возможность программирования ПЛК на LD. Но это не означает, что 95% пользователей программировали ПЛК на LD. LD удобен при программировании релейных схем, но это весьма примитивный язык и далеко на нем не уедешь. В диаграмме представлены данные на 2007 г., которые не отражают нынешние реалии.
Если в ОВЕН действительно сделают возможным программирования своих ПР на ST, то это будет огромным плюсом. Также надо заметить, что никто не принуждает программировать ПР на ST. Каждый будет выбирать тот язык, который ему удобен.
Вы бы еще сслыку на свои догадки дали бы ,цены бы не было
Вы много видели ПЛК которые многоязычные ?
И не показалась странным- зачем давать возможность работать на LD , который по вашему мнению не используется ,а просто довесок
Это американский рынок, американская школа. Ну, и страны их инженерной школы.
Европейская школа ближе к ФБД, как бы они не назывались.
А ST , то где ?
Для выходцев из программистов. Ну и ряд задач удобнее писать на ST.
Вы много видели ПЛК которые многоязычные ?
Достаточно много, причем со своими средами разработки.
Вы бы еще сслыку на свои догадки дали бы ,цены бы не было
Вы много видели ПЛК которые многоязычные ?
И не показалась странным- зачем давать возможность работать на LD , который по вашему мнению не используется ,а просто довесок
Посмотрите список ПЛК, которые программируются в среде CODESYS, он огромен.
Для выходцев из программистов. Ну и ряд задач удобнее писать на ST.
Так я говорил про "выходцев" ,почему ими стали . и что для них удобней , согласен.
Посмотрите список ПЛК, которые программируются в среде CODESYS, он огромен.
Посмотрите список всех ПЛК в мире, он еще более огромен, на порядок .. Что бы было проще - возьмите бренды мировые и оцените сколько используют кодесис . Нам не дано оценить ,нет статистики ,поэтому остается ссылаться на тех кто занимается анализом или статистикой профессионально , а так -сколько людей ,столько и мнений ...
Достаточно много, причем со своими средами разработки.
В штуках, сколько ? Речь не про свои среды разработки ... Да и вопрос вроде не вам задавал ...
Посмотрите список всех ПЛК в мире, он еще более огромен, на порядок .. Что бы было проще - возьмите бренды мировые и оцените сколько используют кодесис . Нам не дано оценить ,нет статистики ,поэтому остается ссылаться на тех кто занимается анализом или статистикой профессионально , а так -сколько людей ,столько и мнений ...
CODESYS используют такие бренды как Bosch, АВВ, WAGO, Hitachi, Beckhoff, Lenze, Moeller, Fastwel и т.д (список огромный). ПЛК Siemens то же можно программировать на 6 языках. Все продвинутые фирмы, производители ПЛК, используют системы программирования стандарта МЭК 61131-3.
Вроде мы говорим про МИР , а не Европу . Кроме того ,первоначально разговор был о языках используемых (пикторграмма) ,ясно что если кодесис ,то в равной степени поддержен и LD & ST .
А так же языки программирования перечисленные в МЭК, не означает что плк программируется в кодесис исключительно.
Вроде мы говорим про МИР , а не Европу . Кроме того ,первоначально разговор был о языках используемых (пикторграмма) ,ясно что если кодесис ,то в равной степени поддержен и LD & ST .
rovki, не надо лезть в бутылку. Ваша карта бита. ;)
rovki, не надо лезть в бутылку. Ваша карта бита. ;)
Бита будет тогда ,когда ссылку дадите на исследование , а не личный опыт и ощущения .:p
Вот список основных производителей PLC ,отметьте те ,кто использует ST ( не обязательно кодесис)
https://ru.qaz.wiki/wiki/List_of_programmable_logic_controller_manufacturer s
Или вот топ 20-
https://roboticsandautomationnews.com/2020/07/15/top-20-programmable-logic-controller-manufacturers/33153/
тут можно ознакомиться с финансами- https://ladderlogicworld.com/plc-manufacturers/
Ваш ход ?
Вроде мы говорим про МИР , а не Европу.
Ну да, мир, эти знаменитые африканские контроллеры...
Давайте подождем, и увидим как те кто пришел с МК на ПР, живо начнут писать только текстом. В остальном, так называемые активные пользователи, здесь на форуме сидят только чтоб найти как можно больше косяков у Овен, поэтому дополнительное поле непаханное им только на руку
Ну да, мир, эти знаменитые африканские контроллеры...
Давайте подождем, и увидим как те кто пришел с МК на ПР, живо начнут писать только текстом. В остальном, так называемые активные пользователи, здесь на форуме сидят только чтоб найти как можно больше косяков у Овен, поэтому дополнительное поле непаханное им только на руку
Да нет ,не Африка , а Америка и Азия .
Не надо о других судить ... Люди работают (делают проекты и находят баги ) и спасибо им за работу ,которую не доделали производители ,а не "косяки ищут".
Да С++ ооочень похож буквами на ST :rolleyes: для МК есть FBD(LD) - FLProg ( не для программистов)
Ладно ,заканчиваю, информацию дал для анализа (умеющий зреть , да увидит) . А то сейчас налетят ,заклюют . Если 2,3 то ладно...а так здоровье с годами становиться важнее:rolleyes: Всем спасибо, до новых встреч в эфире
Ладно ,заканчиваю, информацию дал для анализа (умеющий зреть , да увидит) . А то сейчас налетят ,заклюют . Если 2,3 то ладно...а так здоровье с годами становиться важнее:rolleyes: Всем спасибо, до новых встреч в эфире
Ну Вы же теоретик, сименсовский тиа портал уже перешёл с FBD на ST по умолчанию, как Вам такое Анатолий
Ладно ,заканчиваю
Мудрое решение. ;) Отрицать очевидное тяжелое занятие.
Под разговорами о необходимости текстового языка в ПР ОВЕН, кажется, подведена черта. Разработчики ОВЕН приняли мудрое решение и скоро текстовый язык появится. По другому и быть не могло. В ПР ОВЕН используется мощный ЦП и использовать его возможности всего на 5% крайне неразумно. Трудно представить какое поле для творчества откроется, если хотя бы в макросах появится текстовый язык.
Ну Вы же теоретик, сименсовский тиа портал уже перешёл с FBD на ST по умолчанию, как Вам такое Анатолий
Богу-боговое ,кесарю -кесарево. Я уже писал про законодателей моды, мода приходит и уходит(все имеют право на ошибку) ,а тенденция останется , пока я не увижу общею тенденцию ,выводов делать не буду. А пока статистика такова(см.рис) ...
Мудрое решение. ;) Отрицать очевидное тяжелое занятие.
Под разговорами о необходимости текстового языка в ПР ОВЕН, кажется, подведена черта. Разработчики ОВЕН приняли мудрое решение и скоро текстовый язык появится. По другому и быть не могло. В ПР ОВЕН используется мощный ЦП и использовать его возможности всего на 5% крайне неразумно. Трудно представить какое поле для творчества откроется, если хотя бы в макросах появится текстовый язык.
Я же писал , если без ущерба , то ради Бога...
А пока статистика такова(см.рис) ...
Зачем смотреть на рисунок которому 14 лет ? Эти данные давно не актуальны.
А если актуальны в большей степени? Вот любитель погадать ...За это время развилась целая ниша мини ПЛК (программируемых реле)
Для которых как раз удобнее LD.
Ибо ПР с аналоговыми сигналами - это скорее исключение.
А чем float не устраивает (input registers) , кто их исключает в ПР (разных фирм) ?
Алексеев
18.04.2021, 18:35
.. Люди работают (делают проекты и находят баги ) и спасибо им за работу ,которую не доделали производители .
rovki Хочу твоего совета , как эксперта . Описал фичу ( или баг ,может быть всех нюансов не знаю) , которая возникает в больших проектах ( наличие линий задержки) https://owen.ru/forum/showthread.php?t=34214&p=353748&viewfull=1#post353748 может быть Я не прав , ответа от Марии пока нету .
Но так не должно быть , чтобы отладить свои проекты , Я потратил очень много времени . Если не было бы этой фичи ( или бага ) может быть это произошло быстрее . Хочу услышать Вашего мнения --- почему линия задержки ведет себя по разному с обычными переменными с переменными энергонезависимыми и сетевыми ????
А по поводу Языка программирования мое мнение одно , кто как привык программировать в том языке иму и легче .
Я Сам долго тоже переучивался . И программирую в FBD на много хуже чем Вы и Сергей0308 или bayk наши общие знакомые по форуму . Проекты получаются громоздкие и приходится долго отлаживать . Писать легче , чем рисовать .
Кому как . Но работают , как не странно .:)
Линия задержки это из серии ,что первично курица или яйцо (шутка) ...И она может появиться в любой сложности проекта Это потому ,что программная реализация (последовательная) и обработка результатов в ОЛ идет от Выхода ко Входу (у всех эмуляторах) . В железе ,кто работал с цифровыми схемами знают такой эффект как ГОНКИ ( задержки в элементах на распространение сигнала от Входа к Выходу) . И если не учитывать их, схема может не работать ,там где это критично и можно пренебречь ими в других схемах . Об этом нужно всегда помнить ,но не всегда учитывать , в зависимости от проекта . Так и в эмуляторах нужно помнить о том ,что в одном цикле идет расчет всех выходов всех элементов и ФБ , особенно когда есть обратные связи и могут возникнуть неоднозначности . Поэтому есть такой инструмент как- задержка на один такт . Пример - постройте сдвигающий регистр на D- триггерах в ОЛ и он не будет работать правильно без линии задержки ,потому что именно за счет этих задержек (в реальной жизни) и работает регистр сдвига на Д триггерах. По опыту работы в ОЛ в большенстве случаев не обращаю внимание на наличие желтых связей. В некоторых проектах без них не обойтись, например нужен детектор изменения бита (короткий импульс) - ставлю исключающее ИЛИ ,на один вход переменная 1 , а на второй эту же переменную 1 ,но с задержкой . Тогда на выходе будет импульс в один такт ...
Я не против "перебежчиков" и рад пополнению наших рядов , но только что бы основная масса пользователей не пострадала от нового устава ...
Алексеев
18.04.2021, 21:32
Поэтому есть такой инструмент как- задержка на один такт ..
Самое главное Я это понимаю . Но почему для Нас (разработчиков проектов) переменные зависимые , энерго независимые и сетевые отличаются,
когда мы используем линию задержки .
По опыту работы в ОЛ в большенстве случаев не обращаю внимание на наличие желтых связей..
Но для меня желтый цвет -- это цвет это предупреждения -- что то не корректно сделано .
В некоторых проектах без них не обойтись,.
Я с Вами согласен они даже удобны . Но почему они работают по разному , с типами переменных --Это самый главный вопрос .??
Я не против "перебежчиков" и рад пополнению наших рядов , но только что бы основная масса пользователей не пострадала от нового устава ...
Спасибо . Язык FBD очень понятен , обычным киповцам , которые стараются повысить свой статус и внедрить что то новое
в производстве ,в котором работают . А их действительно , на много больше , чем программистов работающих на языках
более высокого уровня . Ни чего не должно пострадать в ф. Овен работают здраво мыслящие люди .
А для меня желтый цвет- напоминание ,что есть обратные связи . Если не лень поставь задержку на такт...
Не совсем понял про отличия переменных ??? Внутренние переменные формируются внутри(по тактам) ,а сетевые приходят из вне ,асинхронно .
Речь не про "здравомыслие" ,а про то что может пострадать работоспособность ОЛ (наличие багов) для тех кто не использует этот функционал. И о том ,что программист один и если он занят новым функционалом , то остальные хотелки ,которые пользователи высказали за много лет будут не реализованы в ближайшем будущем. Кроме того возможности самого МК не ограничены и на другие задачи может не хватить .
Алексеев
19.04.2021, 07:34
А для меня желтый цвет- напоминание ,что есть обратные связи . Если не лень поставь задержку на такт...
Не совсем понял про отличия переменных ??? Внутренние переменные формируются внутри(по тактам) ,а сетевые приходят из вне ,асинхронно .
Речь не про "здравомыслие" ,а про то что может пострадать работоспособность ОЛ (наличие багов) для тех кто не использует этот функционал. И о том ,что программист один и если он занят новым функционалом , то остальные хотелки ,которые пользователи высказали за много лет будут не реализованы в ближайшем будущем. Кроме того возможности самого МК не ограничены и на другие задачи может не хватить .
Как это можно объяснить 54667 ?????????????
С точки зрение программиста , это должно работать стабильно (не зависимо от типа переменной). 54668 .
, а оно дергается :confused: или с сетевой переменной 54672
Малышев Олег
28.04.2021, 23:12
Маленький пример, поясняющий почему ST удобнее FBD
var
// Т наружнего воздуха
t_extern:array [1..3] of real:=[-25.0,0.0,15.0];
// Т прямой - в сеть
t_direct:array [1..3] of real:=[80.0,55.0,30.0];
// Вычисление по графику Тпрям(Тнар)
function get_t_dir:REAL;
var_input
//Вход Тнаружн
t_ext:REAL;
max_points:UDINT;
end_var
var
// Итератор
iter:UDINT;
end_var
// Если Меньше = Нижней точки
if t_ext<=t_extern[1] then
get_t_dir:=t_direct[1];
ELSE
if t_ext>=t_extern[max_points] then
get_t_dir:=t_direct[max_points];
ELSE
iter:=1;
// Вычисляем в цикле
while iter<max_points do
if t_ext>=t_extern[iter] then // Нашли
// вычисление по формуле Y(x)=Y1+(Y2-Y1)*( (x-x1) / (x2-x1))
get_t_dir:=t_direct[iter]+(t_direct[iter+1]-t_direct[iter])*(t_ext-t_extern[iter])/(t_extern[iter+1]-t_extern[iter]);
iter:=100;
end_if
iter:=iter+1;
end_while
end_if
end_if
// Если больше = верхней точке
end_function
Сергей0308
29.04.2021, 00:15
Маленький пример, поясняющий почему ST удобнее FBD
var
// Т наружнего воздуха
t_extern:array [1..3] of real:=[-25.0,0.0,15.0];
// Т прямой - в сеть
t_direct:array [1..3] of real:=[80.0,55.0,30.0];
// Вычисление по графику Тпрям(Тнар)
function get_t_dir:REAL;
var_input
//Вход Тнаружн
t_ext:REAL;
max_points:UDINT;
end_var
var
// Итератор
iter:UDINT;
end_var
// Если Меньше = Нижней точки
if t_ext<=t_extern[1] then
get_t_dir:=t_direct[1];
ELSE
if t_ext>=t_extern[max_points] then
get_t_dir:=t_direct[max_points];
ELSE
iter:=1;
// Вычисляем в цикле
while iter<max_points do
if t_ext>=t_extern[iter] then // Нашли
// вычисление по формуле Y(x)=Y1+(Y2-Y1)*( (x-x1) / (x2-x1))
get_t_dir:=t_direct[iter]+(t_direct[iter+1]-t_direct[iter])*(t_ext-t_extern[iter])/(t_extern[iter+1]-t_extern[iter]);
iter:=100;
end_if
iter:=iter+1;
end_while
end_if
end_if
// Если больше = верхней точке
end_function
Совсем недавно в одной из тем приводили пример когда на LD проще выполнить алгоритм и думаю каждый может найти пример в пользу предпочтительного для него языка!
А если убрать пол страницы комментариев , то очень понятно , проще будет ?
Ревака Юрий
29.04.2021, 10:48
Маленький пример, поясняющий почему ST удобнее FBD
Подозреваю, что не всем это будет удобнее:) Главное чтобы был выбор.
Главное чтобы был выбор.
Золотые слова. :D
Возможность описать логику на простом и понятном языке - это здорово и круто!
Понятно, что с помощью FB можно описать условно любую логику, только ведь сам потом не разберёшься :)
Только зачем было выбирать такую дурную семантику? Есть же язык Си - простой и понятный всем, зачем усложнять на пустом месте?
Андрей Посохов
29.04.2021, 17:02
Возможность описать логику на простом и понятном языке - это здорово и круто!
Понятно, что с помощью FB можно описать условно любую логику, только ведь сам потом не разберёшься :)
Только зачем было выбирать такую дурную семантику? Есть же язык Си - простой и понятный всем, зачем усложнять на пустом месте?
Затем, что это заблуждение, что язык "С" всем понятный и простой :)
Он требует, как минимум, хорошего обучения. А языку FBD я в свое время научился сам, работая просто в симуляторе OwenLogic.
И многим проще работать с готовыми блоками, чем писать условия и текст. Но безусловно все будет зависеть от задачи.
Золотые слова. :D
В рамку: "C or FBD" :)
Есть же язык Си - простой и понятный всем, зачем усложнять на пустом месте?Ну-ну...
Язык С - очень сложный язык. Если писать на нем в стиле С. Если писать на нем в стиле Паскаля (ST в промавтоматике) - теряется смысл языка С.
Даже при стиле Паскаля на Си пишется лаконичнее - букв меньше.
Сергей0308
29.04.2021, 23:04
Боюсь, для ПР не нужен ST от слова совсем! Я так понимаю он нужен для сложных программ, алгоритмов, так вот недавно программу рисовал на ОЛ, в принципе несложную, но памяти(ОЗУ) израсходовалось более 2/3. Затея с ST это как танку крылья приделать, мне так кажется!
54882
Даже при стиле Паскаля на Си пишется лаконичнее - букв меньше.
А чем вас ПЛК с 5 языками не устраивает?
Ну все, у квадратописцев закончились аргументы, можно расслабиться.
А чем вас ПЛК с 5 языками не устраивает?
Разве стоимость сравнима? Да и скорость разработки выше - простота обращения к дисплею на ПР200.
Сравнима и что?
Метрологическая точность у ПЛК выше. Доступ к дисплею - это да, но это особенность, которую ОВЕН не хочет и не будет исправлять, ибо разработка тех ПЛК давно закончена.
Зато есть доступ к клавиатуре.
Вобщем, глупо мериться запятыми.
И многим проще работать с готовыми блоками, чем писать условия и текст.
Кому удобно, тот пусть и работает. Если в ПР ОВЕН можно будет писать программы на С, то многие скажут спасибо.
А чем вас ПЛК с 5 языками не устраивает?
ПЛК стоит много дороже ПР.
Кому удобно, тот пусть и работает. Если в ПР ОВЕН можно будет писать программы на С, то многие скажут спасибо.
Предлагал ещё при разработке первых ПЛК. Типа раскрывает схемотехнику, BIOS, библиотеки, мониторная программа. Мне объяснили, что ОВЕН не потянет поддержку всего этого. Слишком разные затраты на программирование. Как все же системотехник по образованию я согласился.
Ну и ДОКАЗАТЕЛЬСТВОМ этого является то, что модификация ПЛК с голым линуксом, без рантайма среды разработки, популярностью не пользуется. Вот ваше все - берите и прьграммируйте на С.
Ну-ну...
Язык С - очень сложный язык. Если писать на нем в стиле С. Если писать на нем в стиле Паскаля (ST в промавтоматике) - теряется смысл языка С.
я вот лютый гуманитарий, но точно могу сказать, что С от ST в данном контексте НИЧЕМ не отличается кроме того, что в ST больше нужно нажимать на клавиши.
Ну-ну...
Язык С - очень сложный язык. Если писать на нем в стиле С. Если писать на нем в стиле Паскаля (ST в промавтоматике) - теряется смысл языка С.
Смысл использования языка C в том, что есть готовый компилятор для микроконтроллера, который используется в ПР ОВЕН. Синтаксисы языков C и ST мало отличаются. Нет никакой нужды рядовому программисту использовать все возможности языка C при написании программ для ПР. Каждый будет использовать язык C в меру своих способностей и потребностей.
Знаете, когда я был молодым да не опытным, я тоже считал, зачем SCADA, когда есть среда разработки под Windows, драйвер протоколов, ... И вперёд. Когда показали, что при этом будет при реализации проекта хотя бы средней сложности, я изменил свое мнение.
Подумайте, зачем разрабатываются и используются платформы программирования ПЛК типа кросс-платформенны кодесис, изаграф, .... фирменных? Все дураки или негодяи, желающие срубить бабло?
_Mikhail
30.04.2021, 19:21
Смысл использования языка C в том, что есть готовый компилятор для микроконтроллера, который используется в ПР ОВЕН. Синтаксисы языков C и ST мало отличаются. Нет никакой нужды рядовому программисту использовать все возможности языка C при написании программ для ПР. Каждый будет использовать язык C в меру своих способностей и потребностей.
В том то и дело, что для целей в которых используется ПР, язык С или ST не нужен совсем.
даже в программах контроллеров для современного оборудования в основном используется LD и FBD.
Так как персоналу, который будет это все обслуживать так легче.
Разве обслуживающий персонал программирует ПР или ПЛК?
Удобство создания управляющей программы в итоге определяет скорость создания, скорость исправлений-доработок, стоимость и спрос.
_Mikhail
30.04.2021, 19:31
Разве обслуживающий персонал программирует ПР или ПЛК?
Удобство создания управляющей программы в итоге определяет скорость создания, скорость исправлений-доработок, стоимость и спрос.
При поиске причины сбоя обслуживающий персонал подключается к ПЛК и ищет причину сбоя. И в этот момент С никому не нужен.
Легче с LD и FBD/
Причину сбоя программы должен искать не обслуживающий персонал, а ее автор.
_Mikhail
01.05.2021, 16:23
Причину сбоя программы должен искать не обслуживающий персонал, а ее автор.
когда автор в другой стране, то кто должен искать причины сбоев?
_Mikhail
01.05.2021, 16:34
Нераскрыта тема как конкретный язык позволяет разобраться в причине сбоя.
Каких сбоев ? Диагностируемых ? По таким например в моих проектах персоналу вообще не нужно подключатся. Есть РЭ. Т.е. это вопрос программы как таковой. Причем тут язык ?
Недиагностируемых ? Это вопрос электросхемы/предусмотренных средств диагностики. Причем тут язык ?
Сбоев самого проекта ? - а причем тут язык вообще ? Может в консерватории что-то не то ?
Ну и если предусмотренные проектантом средства диагностики диагностируют "отключенный автомат X" и сообщают предусмотренным проектантом сигналом - "отключен автомат Х", то нужно стучать по голове персоналу который щемится "подключится к ПЛК" для "поиска причины сбоя".
все очень просто.
судя по вашим ответам вы работаете только со своими программами.
а я работаю с оборудованием, которое поставляется из разных стран, и везде программы написаны по разному
и при возникновении сбоев, мне нужно по программе выяснить , в чем причина и дать рекомендации обслуживающему персоналу, что делать.
и как показывает практика, гораздо легче объяснить, если это простые языки программирования.
открой FB___ NW___ посмотри что там, чем читать лекцию по с, ST и т.д.
Тем более вопрос темы ST В ПР
это точно тут не нужно.
_Mikhail
01.05.2021, 16:37
Ну и если предусмотренные разработчиком средства диагностики диагностируют "отключенный автомат X" и сообщают предусмотренным проектантом сигналом - "отключен автомат Х", то нужно стучать по голове персоналу который щемится "подключится к ПЛК" для "поиска причины сбоя".
А если по любому сбою синхронного привода разработчик вывел одну ошибку "ОШИБКА СЕРВОПРИВОДА" , что тоже стучать по голове персоналу, который ищет ошибку?
:)
"это точно тут не нужно."
Разработчики Овен сейчас только прочли и им пришлось вычеркнуть ЭТО из своих задач. Раз Вам не нужно. Жаль, мне, конечно, не обязательно, но было бы удобнее.
все очень просто.
судя по вашим ответам вы работаете только со своими программами.
а я работаю с оборудованием, которое поставляется из разных стран, и везде программы написаны по разному
и при возникновении сбоев, мне нужно по программе выяснить , в чем причина и дать рекомендации обслуживающему персоналу, что делать.
и как показывает практика, гораздо легче объяснить, если это простые языки программирования.
открой FB___ NW___ посмотри что там, чем читать лекцию по с, ST и т.д.
Тем более вопрос темы ST В ПР
это точно тут не нужно.
Информатику в наше время преподают во всех российских школах. Паскаль и Бейсик знает каждый школьник. Если человек не в зуб ногой в программировании, то ему надо подыскать другую работу.
_Mikhail
01.05.2021, 19:12
Информатику в наше время преподают во всех российских школах. Паскаль и Бейсик знает каждый школьник. Если человек не в зуб ногой в программировании, то ему надо подыскать другую работу.
при чем тут паскаль и бейсик? видать вы очень далеко от промышленных контроллеров
_Mikhail
01.05.2021, 19:16
Информатику в наше время преподают во всех российских школах. Паскаль и Бейсик знает каждый школьник. Если человек не в зуб ногой в программировании, то ему надо подыскать другую работу.
в продолжение темы: потом появляются разные сообщения , типа: Здравствуйте с промышленным программированием не знаком, программирую на питоне, го, вба
предложили работу кодера ПО связанного с промышленным программированием
Увидел ТЗ, небольшое решил взяться, это линия где стоят ванны с жидкостью, то есть для гальваники, в ванные нужно опускать детали они подвешены над ваннами должны передвигаться от ванны к ванной, опускаться и подниматься из неё в нужное время
Так вот я не пойму, с чего всё начинается?
к ТЗ приложено несколько схем сначала я их проигнорировал, а потом понял что они не спроста..... спасибо
И этим типа программистам дают задание, а потом мы обслуживающий персонал все переделываем
При чем тут паскаль и бейсик?
А при том. Если человек знает любой текстовый язык программирования, то освоить ST не составит никакого труда.
Видать вы очень далеко от промышленных контроллеров
С промышленными контроллерами я имею дело много лет. Полагаю ты под стол пешком ходил когда я начинал. ;)
Не совсем так.
Квадратитки - это программа, управляемая потоком данных, если брать теорию. И в некоторых случаях это удобнее, если таймеры, ПИДы...
ST - управление потоком команд.
Eugene.A
02.05.2021, 11:56
Знание языка ровным счётом ничего не даёт для создания алгоритма. Это как набор инструментов для балерины. Вот я знаю русский язык. Стою в картинной галерее против шедевра живописи, он мне нравится, но я и двух слов не могу связать о нём, в отличие от искусствоведа.
Вот как же и программист баз данных, в совершенстве владеющий языками программирования, может стоять перед каким-либо оборудованием, как баран перед новыми воротами.
Знание языка ровным счётом ничего не даёт для создания алгоритма.
Незнание языка еще хуже. ;)
Никакой ST в ПР не нужен. Никаким образом это не поможет увеличить объём продаж устройств данного типа, а следовательно все трудозатраты разработчиков этой функции будут слиты в унитаз.
Вместо этого, абсолютно бесперспективного занятия, следует уделить внимание расширению функций ФБД. Например, в системе программирования уже почти антикварных ПР ALPHA XL от известного японского производителя есть замечательный блок Calculation
6.28 Функциональный блок Calculation
С помощью функционального блока Calculation (Вычисления) можно создавать выражения,
содержащие переменные числом до четырех (A, B, C, D) и операторы (+, -, *, /, %), и получать на
выходе результат вычислений Y. Выражение может содержать до 64 членов. Глубина вложения
при помощи скобок может достигать максимум 6.
Или ещё вот этот блок:
6.3. Функциональный блок Boolean
С помощью этого блока можно производить логические операции с использованием функций
булевой алгебры. При этом разрешается применять несколько логических функций в одном
уравнении. Например, можно записать функцию AND с помощью уравнения «S1 AND S2 =
ВЫХОД» или функцию NAND с помощью уравнения «NOT (S1 AND S2) = ВЫХОД». Таким же
образом составляются и более сложные формулы. Выход может быть при этом определен в
одной из двух частей уравнения.
А ещё сделать масштабируемыми по количеству входов логические элементы.
И вообще, посмотреть внимательно, как ФБД реализован у успешных конкурентов, а не тратить ресурсы на бесперспективный для подобных устройств ST.
Еще один умник.;) Для таких как ты: если в ПР ОВЕН появится текстовый язык, то любой грамотный пользователь сможет легко реализовать все что ты там наперечислял и много больше. Т.е. можно будет самому реализовать все что душа пожелает.
IVM, Согласен ,за исключением того трудозатраты будут слиты в унитаз , они лягут на основных пользователей в виде новой цены на ПР (ОЛ же бесплатный).
Функционал FBD(ОЛ) раскрыт еще только на 50%. Очень много фишек у аналогичных FBD ,а нас понесло в другую сторону...Увеличение потребителей ПР лежит в сфере перехода их с других аналогичных брендов на Овен , а не привлечения за счет программистов ,пишущих на ST на тех же ПЛК от Овен. Что толку Овен , если 10 пользователей ПЛК ,перейдут на ПР ,с целью экономии.
В принципе ,как писал ранее ,не против ST , но смущает цена вопроса и отсутствие развития функционала ОЛ-FBD (кроме как добавление модулей расширения) и других хотелок , которые были предложены пользователями за долгие годы , но так и не нашли применения. При нормальной (конкурентной) цене на ПР , добавьте новый функционал FBD (самое лучшее из аналогов, изобретать не нужно) и к вам потянуться...и переход будет легче для них
Еще один умник.;) Для таких как ты: если в ПР ОВЕН появится текстовый язык, то любой грамотный пользователь сможет легко реализовать все что ты там наперечислял и много больше. Т.е. можно будет самому реализовать все что душа пожелает.
А почему на ТЫ , вы знакомы или родственники?
Можно подумать ,что те кто пишет на FDB не грамотные пользователи .
"Если бы, да кабы, выросли во рту грибы". Для таких как ты - твоё мнение меня не интересует от слова "совсем", и не трать на его выражение остатки своей никчёмной мозговой деятельности.
Ответка видать...Давайте жить дружно.
"тиа портал" не имеет никакого отношения к программируемым реле. Даже к их, сименсовским, LOGO!
Зачем нужны такие тупые, легко опровергаемые "аргументы"?
ну зачем же вырывать слова из контекста, до этого оппонент писал про контроллеры, это после он одумался и начал писать что программируемое реле это маленький контроллер
А разве это не так?
так Вы сами и определитесь тогда, речь все же о реле или контроллерах в целом. О тенденциях там шла речь. Если современные реле уже не просто заменяют шкаф механических релюшек, а выполняют мат.расчеты, то и языков надо больше, чтоб реализовать всё то что невозможно в одном из...
Большая часть проблем ОЛ, это как раз отрисовка, расположение квадратиков, обратные связи туда же, термин энергонезависимость в макросах. Если сложные логические конструкции будут писаться текстом, это сильно сократит размер занимамой площади холста и ряд проблем исчезнет, ну или будут очень редки, потому что всегда будут находится уникальные люди. Плюсом, вероятность что пользователь разберется как написать свое ТЗ в виде проекта увеличится, за дешевизной гонятся не только те кто разбирается в портянках релейных схем, кто то пишет только текстом, почему ему не использовать ПР
Можно, ноьнасколько удобно?
У каждого языка - своя ниша.
В рамках развитого ФБД возможно решить 100% озвученных проблем.
какие проблемы фбд решает, как выглядит конструкция CASE ... OF на десять кейсов? Особенно когда не примитивное присвоение, а расчеты.
И я озвучивал проблемы, про ошибки ОЛ, это то что хотя и схемы следят за выполнением с лева на право и с верху в низ, обязательно у кого нибудь какая нибудь связь с низу должна уйти на верх, из-за этого создаваемые выделенные схемы в макрос, прибавляют проблем с расположением входов, да и логики в целом, в тексте этого нет
А чего опровергать?
Создали конструктив по входам-выходам, экрану и кнопкам ~= ПЛК63, кроме метрологической точности - люди будут стремиться использовать его, как ПЛК. Хотя бы по цене, а кого сейчас волнует точность, да и в 90% ее достаточно. Доказательство - сам ОВЕН использует именно эту платформу для ТРМ, КТР, ...
Не спорю, да по ***** на это!
Это не мешает использовать его в ИТП, вентиляции, как пример. А это не маленький рынок в РФ. Никакая точность? Не спорю, только скажите это SE с его недоконтроллерами от бывшего модикона, с их точностью в 1..1,5 град, но при этом ценой и грамотным маркетингом они выносят ОВЕН с рынка, и не только брендом!
Да и ровки может рассказать про точность, нужна - не нужна.
ПР не средство измерения ,имхо , а программируемый пользователями устройство . Отсутствие сертификата на средство измерения не отменяет его известную погрешность, его отдельных аналоговых входов , декларированных в РЭ...И пользователь сам решает устраивает ли его 12раз. АЦП с известным быстродействием... Но датчики нужны не только же для того что бы их зрить на экране ,но что бы еще управлять ...
99,9% из массовых пользователей ПР, покупающих эти изделия на текущий момент времени, не будет использовать ST.
Попробуйте опровергнуть.
Легко. После выхода СТ 0.1 процента пользователей понаделают классных макросов и оставшиеся 99 сразу начнут ими пользоваться и оптимизировать под свои нужды. Одна беда нет нормального хранилища макросов. Да ещё и на форуме файлы удаляются.
Ревака Юрий
02.05.2021, 21:31
Легко. После выхода СТ 0.1 процента пользователей понаделают классных макросов и оставшиеся 99 сразу начнут ими пользоваться и оптимизировать под свои нужды. Одна беда нет нормального хранилища макросов. Да ещё и на форуме файлы удаляются.
А каких макросов сейчас не хватает, и какие могут появиться с выходом ST?
А каких макросов сейчас не хватает, и какие могут появиться с выходом ST?
ну например можно большинство кода из оскат перенести
А каких макросов сейчас не хватает, и какие могут появиться с выходом ST?
С выходом полноценного ST станут доступны, например, все элементарные функции. Не понятно что это апологеты FBD подняли такой жуткий вой. Никто не собирается отнимать у них любимую игрушку. Речь идет о том, что в ПР ОВЕН появится возможность писать макросы на ST. FBD в ПР ОВЕН как был так и будет. Появление ST никак не скажется на цене ПР ОВЕН. Как вариант можно сделать исполнение ПР с поддержкой ST.
Отразится и ещё как.
Вы предлагаете создать по сути полноценную систему программирования ПЛК(!), распространяемую бесплатно. Ее цена войдёт в стоимость ПР. Чудес на свете не бывает и законов сохранения никто не отменял(с). Ряд отечественных ПЛК даже 0-х годов рождения примером.
Отразится и ещё как.
Вы предлагаете создать по сути полноценную систему программирования ПЛК(!), распространяемую бесплатно. Ее цена войдёт в стоимость ПР. Чудес на свете не бывает и законов сохранения никто не отменял(с). Ряд отечественных ПЛК даже 0-х годов рождения примером.
Лицензионная марка для ПЛК с CoDeSys стоит €2. Вот на эту величину примерно и увеличится стоимость ПР с ST.;)
Rake Runner
03.05.2021, 10:08
Лицензионная марка для ПЛК с CoDeSys стоит €2. Вот на эту величину примерно и увеличится стоимость ПР с ST.;)
Пруфлинк дадите?
Пруфлинк дадите?
Все вопросы к ОВЕН.;) ОВЕН лицензионные марки пачками покупает у 3S-Smart Software Solutions GmbH и по хорошему должен клеить их на все свои ПЛК.
Лицензионная марка для ПЛК с CoDeSys стоит €2. Вот на эту величину примерно и увеличится стоимость ПР с ST.;)
Вы в курсе объемов продажи лицензий КДС? И сколько в штуках будет ПР200? А теперь переведите в %%.
Вы в курсе объемов продажи лицензий КДС? И сколько в штуках будет ПР200? А теперь переведите в %%.
А при чем тут объем продаж лицензий КДС ? Одно ПР - одна марка. За марку заплатит покупатель ПР с ST.
Rake Runner
03.05.2021, 10:41
Все вопросы к ОВЕН.;) ОВЕН лицензионные марки пачками покупает у 3S-Smart Software Solutions GmbH и по хорошему должен клеить их на все свои ПЛК.
Т.е. вы сотрудник ОВЕН?
Т.е. вы сотрудник ОВЕН?
С чего вы взяли ? Я вольный человек, с наемным трудом я давно завязал.;)
А при чем тут объем продаж лицензий КДС ? Одно ПР - одна марка. За марку заплатит покупатель ПР с ST.
Вы предлагаете перевести ПР на КДС? Или что?
Вы предлагаете перевести ПР на КДС? Или что?
Это лучше у представителей фирмы ОВЕН спросить. Конечным пользователям ПР ОВЕН без разницы как все будет реализовано. Интересует лишь цена вопроса и когда ST появится.
Что в итоге?
На прямой и конкретный вопрос:
А каких макросов сейчас не хватает, и какие могут появиться с выходом ST?
Нет ни одного конкретного и вразумительного ответа от сторонников ST.
За реализацию их идиотских хотелок предлагается заплатить всем остальным покупателям.
Цена ПР Овен уже сейчас не самая низкая на рынке, и если функция ST ляжет в его конечную стоимость (другой вариант - списать в убытки), то это неизбежно уменьшит объёмы их продаж.
Абсолютно лишённая какого-либо смысла затея.
Да уймись ты наконец. ;)
Да иди ты на х
«Юпитер, ты сердишься — значит, ты не прав». ;)
Других аргументов не осталось?
Аргументов в пользу ST полный вагон. Жаль, что до тебя это не доходит. Займись повышением своего технического уровня. Учиться никогда не поздно ;)
Вы взяли бы ПР/ПЛК, программируемый только на ST?
Так приведи их, мальчик.
Мальчик судя по всему - это ты. ;)
Вы взяли бы ПР/ПЛК, программируемый только на ST?
Не понятно к чему этот вопрос. Надо бы пояснить.
Да уж точно - не девочка.
Всё, слился?
Выпей водички и успокойся. ;)
Не понятно к чему этот вопрос. Надо бы пояснить.
К предпочтительным языкам для решения задач автоматического управления.
Не беря ОВЕН, я знаю много контроллеров только с ФБД, немного только с ладдером, во всяком случае, в моём начале и ни одного только с СТ.
Вы зря это делаете . Ругаетесь. Вы думаете так проста параллейно языку FBD Создать язык ST /:confused:
Даже компания инсайт допускает не которые ошибки при реализации языка ST , хотя она съела собаку в этой области .
Если только её подключить , но это будет стоить денег , которые лягут на потребителей . https://owen.ru/forum/showthread.php?t=11806&p=321825&viewfull=1#post321825 Вы знаете сколько времени уйдет на тестирование :confused:
Коллеги не ссорьтесь :)
А не надо велосипед изобретать. Проще язык C использовать с готовым компилятором и библиотеками.
К предпочтительным языкам для решения задач автоматического управления.
Не беря ОВЕН, я знаю много контроллеров только с ФБД, немного только с ладдером, во всяком случае, в моём начале и ни одного только с СТ.
А я знаю море ПЛК с CoDeSys и пятью языками.;) Доморощенные среды программирования ПЛК - это вчерашний день.
Даже компания инсайт допускает не которые ошибки при реализации языка ST , хотя она съела собаку в этой области .
https://owen.ru/forum/showthread.php?t=11806&p=321825&viewfull=1#post321825 Вы знаете сколько времени уйдет на тестирование :confused:
а где там ошибка то? Вам же ответили что у них всё работает и больше диалога с Вами не было. А код там так себе, можно и лучше написать было
А у нас сегодня кошка родила вчера котят.
Ты случайно не пьяный ? ;)
По мне так вместо ST была бы возможность писать "по человечески " X=sin(io1*io2/3.3+ io3) в макросе для математических выражений .Сомневаюсь , что будет возможность использовать циклы ,ветвления ,переходы итд. Тоесть текстовый язык нужен не для описания алгоритма (последовательности действий) ,а исключительно для мат.операций
А я знаю море ПЛК с CoDeSys и пятью языками.;) Доморощенные среды программирования ПЛК - это вчерашний день.
То есть, ПЛК63-лайт?
Даже если так, то уже не возможно. КДС2 в прошлом, а КДС3 на этот огрызок не установить.
По мне так вместо ST была бы возможность писать "по человечески " X=sin(io1*io2/3.3+ io3) в макросе для математических выражений .Сомневаюсь , что будет возможность использовать циклы ,ветвления ,переходы итд. Тоесть текстовый язык нужен не для описания алгоритма (последовательности действий) ,а исключительно для мат.операций
Это самое правильное решение для ОЛ я считаю. Но должны поддерживаться все возможные математические функции.
Логику всё равно проще на фбд писать
То есть, ПЛК63-лайт?
Даже если так, то уже не возможно. КДС2 в прошлом, а КДС3 на этот огрызок не установить.
Представитель ОВЕН недавно сообщил, что работы по текстовому языку для ПР ведутся. За разъяснениями лучше к ним обращаться.
Больше чем уверен , не все что ST , кодесис . Это будет скорее обрубышь ...
Одно напрягает - это расстановка приоритетов в развитии ОЛ...
Больше чем уверен , не все что ST , кодесис . Это будет скорее обрубышь ...
Одно напрягает - это расстановка приоритетов в развитии ОЛ...
Все будет хорошо. Даешь текстовый язык в ПР ОВЕН.
Сторонники "ST" на вопрос - какого блюда им не хватает, жмут плечами и говорят что им удочка нужна.
Забыли слово "мне"
Пользователям программируемых реле, точнее ( не программистам ,в узком понимании)
Все будет хорошо. Даешь текстовый язык в ПР ОВЕН.
Не обязательно ST . И в последнею очередь !
Ревака Юрий
03.05.2021, 15:41
А не надо велосипед изобретать. Проще язык C использовать с готовым компилятором и библиотеками.
Язык С можно и сейчас использовать, но боюсь Вам это не понравится:)
Язык С можно и сейчас использовать, но боюсь Вам это не понравится:)
Подробнее можно про использование C в ПР ОВЕН.
Ревака Юрий
03.05.2021, 21:51
Подробнее можно про использование C в ПР ОВЕН.
Да какие подробности, в ПР используется обычный контроллер STM, под который много разных вариантов разработки, никакого OwenLogic, полный доступ ко всему:)
Через JTAG?
Вот просто вопрос. Программы для ТРМ, КТР, СУНА,... на платформе ПР200 написаны на С или ОЛ? Понятно, что внутренняя информация, но может ответите?
Пишу , как пишу .Важен результат.
Попросили проверить в Вете https://owen.ru/forum/showthread.php?t=11806&p=321840&viewfull=1#post321840
Вот https://owen.ru/forum/showthread.php?t=11806&p=327139&viewfull=1#post327139
Просто интересно, как Вы представляете код ловли заднего фронта, это должен быть видимо какой то огроменный код, который инсатовцы ни как не могли победить что ли?
И точно ли дело в коде на ST, а вдруг он на чем то другом писался? Или ошибка вообще другого плана не связанная с кодингом пользователя
Примите за правило не пользоваться примитивными ФБ. Всегда можно записать
IF NOT xFLAG AND xOLDFLAG THEN
...
END_IF;
xOLDFLAG := xFLAG;
т.е. в Вашем коде вместо ФБ нужно добавить одну лишь булеву переменную и все
Ревака Юрий
03.05.2021, 22:54
Вот просто вопрос. Программы для ТРМ, КТР, СУНА,... на платформе ПР200 написаны на С или ОЛ? Понятно, что внутренняя информация, но может ответите?
В этом вроде нет тайны, в базе полно макросов как раз из этих разработок.
Через JTAG?
Вот просто вопрос. Программы для ТРМ, КТР, СУНА,... на платформе ПР200 написаны на С или ОЛ? Понятно, что внутренняя информация, но может ответите?
Все эти программы написаны на ОЛ. Тут никакого секрета нет.
Оператор CASE кране необходим. Лучше сделать так чтобы ПР можно было программировать на трех языках: ST, LD, FBD. Тогда точно ПР ОВЕН не будет равных.
хотя бы if then else ... или подскажите как это сделать в старом функционале
Сергей0308
05.05.2021, 12:21
хотя бы if then else ... или подскажите как это сделать в старом функционале
А задача какая, что Вы хотите сделать? Это можно по-русски написать?
ПР102 как Slave получает по Модбас команды и выполняет их, но в начале работы (при запуске) и иногда при работе по определённым условиям надо бы обнулять эту сетевую переменную, на случай если связи уже нет а команда "висит".
Она помниться даже при отключении- включении ПР
Сергей0308
05.05.2021, 12:38
ПР102 как Slave получает по Модбас команды и выполняет их, но в начале работы (при запуске) и иногда при работе по определённым условиям надо бы обнулять эту сетевую переменную, на случай если связи уже нет а команда "висит".
Она помниться даже при отключении- включении ПР
Не совсем понятна проблема, если Вам нужно иметь значение по умолчанию для сетевой переменной, можно так сделать:
54971
Просто обнулить(записать значение) по команде или при включении - вообще не вижу проблемы!
Не совсем понятна проблема, если Вам нужно иметь значение по умолчанию для сетевой переменной, можно так сделать:
54971
Об этом способе я уже думал, но не нравиться он мне- в каждом цикле переписывать сетевую переменную по которой же получаешь критическую информацию (команду на включение оборудования)
А если мне надо выполнить какое-нибудь действие только при определённом условии что нет функционала?
Ревака Юрий
05.05.2021, 14:26
Об этом способе я уже думал, но не нравиться он мне- в каждом цикле переписывать сетевую переменную по которой же получаешь критическую информацию (команду на включение оборудования)
А если мне надо выполнить какое-нибудь действие только при определённом условии что нет функционала?
Можно еще макросы SelChgF(I) использовать, по одному входу в нужное время посылать 0, по второму значение из сети, хоть каскад из них выстроить.
Сергей0308
06.05.2021, 08:39
Можно еще макросы SelChgF(I) использовать, по одному входу в нужное время посылать 0, по второму значение из сети, хоть каскад из них выстроить.
Недостаток этих макросов в том, что выходная переменная всегда "соединена" с одним из входов, то есть не обладает возможностями "самостоятельной жизни", короче, я обычно делаю так:
54990
При изменение входных переменных происходит разовая запись в выходную переменную, а дальше выходная переменная может "жить" собственной жизнью, например её можно изменить с экрана(или как ещё).
Ревака Юрий
07.05.2021, 08:20
Недостаток этих макросов в том, что выходная переменная всегда "соединена" с одним из входов, то есть не обладает возможностями "самостоятельной жизни", короче, я обычно делаю так:
54990
При изменение входных переменных происходит разовая запись в выходную переменную, а дальше выходная переменная может "жить" собственной жизнью, например её можно изменить с экрана(или как ещё).
Если макросы включить каскадом, то как раз и получается управление из нескольких мест.
Сергей0308
07.05.2021, 11:29
Если макросы включить каскадом, то как раз и получается управление из нескольких мест.
Если Вы имеете ввиду нарастить количество входов и "завернуть" выход на один из входов, то возможно так и получится, но это будет сложней моего варианта!
Если Вы имеете ввиду нарастить количество входов и "завернуть" выход на один из входов, то возможно так и получится, но это будет сложней моего варианта!
вариант подобный вашему с помощью SEL и FTRIG я и использую (пока в тестировании) но он мне не по душе, извращение какое-то переписывать сетевую переменную в каждом цикле.
Но почему нет нормального оператора подобного if()then enf_if мне не понятно. Если бы были операторы if и case то и ST для ПР не очень мне нужен бы был.
Сергей0308
07.05.2021, 13:23
вариант подобный вашему с помощью SEL и FTRIG я и использую (пока в тестировании) но он мне не по душе, извращение какое-то переписывать сетевую переменную в каждом цикле.
Но почему нет нормального оператора подобного if()then enf_if мне не понятно. Если бы были операторы if и case то и ST для ПР не очень мне нужен бы был.
В ОЛ так и внутренние переменные сохраняются(выход заворачивается на вход), всё на этом построено и это считается нормальным, так что не переживайте, а просто пользуйтесь!
Так и пишите что любой грамотный пользователь ардуино сможет .....водить и в ОЛ. А потом овен будет разбирать этот .....код искать ошибку и писать автору почему этот шедевр гения программирования не работает. Вот чего я боюсь. И запомните так и будет.
Уважаемые коллеги уже 18 страниц спорят (местами очень горячо) о том , чего нет и неизвестно когда будет. Вспомните тему (обратите внимание на дату) https://owen.ru/forum/showthread.php?t=27914&highlight=%F9%E8%F2%EE%E2%EE%EC
Как пафосно начиналась
Добрый день, коллеги!
Мы начинаем разработку программируемого реле в щитовом исполнении.
На данном этапе составляем портрет изделия. художник 4 года пишет портрет.:)
bubaeshka
12.09.2022, 10:52
Весьма интересный вопрос. А нет ли в ST для ОЛ (то есть ПР200) сложных типов данных? Массивы, как я выяснил уже, работают. А вот что то наподобие паскалевских записей. Наткнулся что в кодесис можно объявить тип TYPE - END_TYPE, а в нём структуру STRUCT - END_STRUCT.
kondor3000
12.09.2022, 11:08
Весьма интересный вопрос. А нет ли в ST для ОЛ (то есть ПР200) сложных типов данных? Массивы, как я выяснил уже, работают. А вот что то наподобие паскалевских записей. Наткнулся что в кодесис можно объявить тип TYPE - END_TYPE, а в нём структуру STRUCT - END_STRUCT.
В ОЛ даже функц. блоки неизвестно когда сделают, а вы структуры хотите)))
Напомнили Вы, коллеги, давно забытую тему https://owen.ru/forum/showthread.php?t=17834
Из которой был сделан единственный вывод:
Попытка приблизить программирование к конфигурированию (замена языка C++ на FBD, LD и т.д.) приводит к следующему:
По мере роста сложности проектов функциональности этих языков не достаточно, что приводит к созданию новых диалектов ST, которые в свою очередь не дотягивают до любого полноценного ЯП. В результате с одной стороны мы издеваемся над КИПовцами, заставляя их разбираться в НЕДОЯЗЫКЕ, а с другой над программистом, заставляя создавать различные костыли, чтобы добавить недостающей функциональности. Или долго ожидать очередного релиза ОЛ, чтобы потом бороться с новыми багами и ждать следующего релиза. Если пройтись по форуму и почитать вопросы новичков, то станет понятно, что информатику сейчас никто не учит - отсюда нет возможности понимать и инструкции по эксплуатации. И, соответственно, чтобы вести полноценную разработку все равно требуется специалист со семью пядями во лбу, который уже опытен во всем и умеет записать любой алгоритм в любом виде. Здесь, например, все ругают Arduino. Но популярность его в мире все больше и больше растет. Почему?
Может правильнее будет упрощать жизнь профессионалам, а не усложнять её новичкам?!:confused:
Рогов Алексей
14.12.2022, 13:00
Добрый день!
Вот и свершилось - ST в реле... А с чего начать? Паскаль учить или как? У нас 25 лет назад Бейсик и Фортран были...
По крайней мере триггеры в нормальных учебниках хоть 50 летней давности описаны - всё понятно, бери и учи. Или уважаемые коллеги самоучки и не знают чего просят или КАК?
Как простому человеку создать формулу, и не городить огород?
Добрый день!
Вот и свершилось - ST в реле... А с чего начать? Паскаль учить или как? У нас 25 лет назад Бейсик и Фортран были...
По крайней мере триггеры в нормальных учебниках хоть 50 летней давности описаны - всё понятно, бери и учи. Или уважаемые коллеги самоучки и не знают чего просят или КАК?
Как простому человеку создать формулу, и не городить огород?
Начните со справки к OL, там есть отдельный раздел
Дмитрий Костюков
15.12.2022, 11:25
Добрый день!
Вот и свершилось - ST в реле... А с чего начать? Паскаль учить или как? У нас 25 лет назад Бейсик и Фортран были...
По крайней мере триггеры в нормальных учебниках хоть 50 летней давности описаны - всё понятно, бери и учи. Или уважаемые коллеги самоучки и не знают чего просят или КАК?
Как простому человеку создать формулу, и не городить огород?
Добрый день.
Если есть хоть небольшой опыт в каком-то другом языке программирования, то вот тут довольно неплохо написано. И не размашисто - всего 8 страниц:
http://codesys.ru/docs/st_c.pdf
Добрый день.
Если есть хоть небольшой опыт в каком-то другом языке программирования, то вот тут довольно неплохо написано. И не размашисто - всего 8 страниц:
http://codesys.ru/docs/st_c.pdf
Нужно только иметь в виду, что [пока] не все возможности языка ST поддерживаются в OL.
Не все это прям мягко сказано, ради того что там сейчас поддержано даже учить смысла нет :-)
Рогов Алексей
16.12.2022, 13:36
Не все это прям мягко сказано, ради того что там сейчас поддержано даже учить смысла нет :-)
Возможно Вы правы - из того, что есть, даже задачи себе - потренироваться - поставить не смог,,, сравнивать, умножать и так можно. Интересно было бы узнать у товарищей, кто топил за ST чего они смогли добиться, раз просили - думаю не сложно опытом поделиться. Я не разработчик, а ремонтник на производстве, и подозреваю, что ребята просили ST только ради того, чтобы техперсоналу заказчика жизнь усложнить и заработать впоследствии. Это похвально, но редкому заказчику понравятся мины в программе. Для маленьких станочков ПР с FB вполне хватает, когда мозги менять приходится - обычно по двум причинам - нет проекта - нет диагностики или хочется модернизировать а программа и кабель для западных мозгов денег стоит больше, чем ПР. Программисты Овена затратили определённые ресурсы - и какая польза? Ведь покупая ПР мы их труд финансируем, а творческие ресурсы ушли на ST.
Я топлю за ST, но то что в ПР это еще не ST :-)
Овен пошел по правильному пути, но надо развивать начатое.
...Интересно было бы узнать у товарищей, кто топил за ST чего они смогли добиться...
Ну, так, вот в теме народ хвастался https://owen.ru/forum/showthread.php?t=35489
Возможно Вы правы - из того, что есть, даже задачи себе - потренироваться - поставить не смог,,, сравнивать, умножать и так можно. Интересно было бы узнать у товарищей, кто топил за ST чего они смогли добиться, раз просили - думаю не сложно опытом поделиться. ...
Вычисление дня недели по дате https://owen.ru/forum/showthread.php?t=35489&p=369454&viewfull=1#post369454
такой метод
dayOfWeek = (year+year/4+ ММ[mounth] + day) MOD 7
где
year - год;
day - номер дня в месяце;
ММ[mounth] - значение из массива
январь
5 (4 - для високосного года)
февраль
1 (0 - для високосного года)
март
1
апрель
4
май
6
июнь
2
июль
4
август
0
сентябрь
3
октябрь
5
ноябрь
1
декабрь
3
(кусочно-линейная аппроксимация) - график по 10 точкам, метод поиска делением интервала пополам https://owen.ru/forum/showthread.php?t=35489&p=369459&viewfull=1#post369459
Вариант предыдущего графика
- добавил вход "Количество точек", "Слева от первой точки – прямая параллельная оси Х" и "Справа от последней точки – прямая параллельная оси Х", такие как в блоке Graf_4pnt_v1.04 из онлайн библиотеки https://owen.ru/forum/showthread.php?t=35489&p=394889&viewfull=1#post394889
Возможно Вы правы - из того, что есть, даже задачи себе - потренироваться - поставить не смог,,, сравнивать, умножать и так можно. Интересно было бы узнать у товарищей, кто топил за ST чего они смогли добиться, раз просили - думаю не сложно опытом поделиться. Я не разработчик, а ремонтник на производстве, и подозреваю, что ребята просили ST только ради того, чтобы техперсоналу заказчика жизнь усложнить и заработать впоследствии. Это похвально, но редкому заказчику понравятся мины в программе. Для маленьких станочков ПР с FB вполне хватает, когда мозги менять приходится - обычно по двум причинам - нет проекта - нет диагностики или хочется модернизировать а программа и кабель для западных мозгов денег стоит больше, чем ПР. Программисты Овена затратили определённые ресурсы - и какая польза? Ведь покупая ПР мы их труд финансируем, а творческие ресурсы ушли на ST.
Так FB никуда не делись , не нравиться ST не нужно пользоваться, какие проблемы. То что появилась возможность пусть в ограниченном варианте это скорее хорошо , а не плохо. Да хотя бы арифметическую формулу более менее сложную гораздо проще и наглядней на ST , чем квадратиками. Или выше Петр наглядный пример привел.
Рогов Алексей
16.12.2022, 14:32
Здравствуйте!
Благодарю за ссылку, почитаю учебники Петрова.
Powered by vBulletin® Version 4.2.3 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot