Вид для печати
Богу-боговое ,кесарю -кесарево. Я уже писал про законодателей моды, мода приходит и уходит(все имеют право на ошибку) ,а тенденция останется , пока я не увижу общею тенденцию ,выводов делать не буду. А пока статистика такова(см.рис) ...Цитата:
Сообщение от capzap
Я же писал , если без ущерба , то ради Бога...Цитата:
Сообщение от IVM
Зачем смотреть на рисунок которому 14 лет ? Эти данные давно не актуальны.Цитата:
Сообщение от rovki
А если актуальны в большей степени? Вот любитель погадать ...За это время развилась целая ниша мини ПЛК (программируемых реле)
Для которых как раз удобнее LD.
Ибо ПР с аналоговыми сигналами - это скорее исключение.
А чем float не устраивает (input registers) , кто их исключает в ПР (разных фирм) ?
rovki Хочу твоего совета , как эксперта . Описал фичу ( или баг ,может быть всех нюансов не знаю) , которая возникает в больших проектах ( наличие линий задержки) https://owen.ru/forum/showthread.php...l=1#post353748 может быть Я не прав , ответа от Марии пока нету .Цитата:
Сообщение от rovki
Но так не должно быть , чтобы отладить свои проекты , Я потратил очень много времени . Если не было бы этой фичи ( или бага ) может быть это произошло быстрее . Хочу услышать Вашего мнения --- почему линия задержки ведет себя по разному с обычными переменными с переменными энергонезависимыми и сетевыми ????
А по поводу Языка программирования мое мнение одно , кто как привык программировать в том языке иму и легче .
Я Сам долго тоже переучивался . И программирую в FBD на много хуже чем Вы и Сергей0308 или bayk наши общие знакомые по форуму . Проекты получаются громоздкие и приходится долго отлаживать . Писать легче , чем рисовать .
Кому как . Но работают , как не странно .:)
Линия задержки это из серии ,что первично курица или яйцо (шутка) ...И она может появиться в любой сложности проекта Это потому ,что программная реализация (последовательная) и обработка результатов в ОЛ идет от Выхода ко Входу (у всех эмуляторах) . В железе ,кто работал с цифровыми схемами знают такой эффект как ГОНКИ ( задержки в элементах на распространение сигнала от Входа к Выходу) . И если не учитывать их, схема может не работать ,там где это критично и можно пренебречь ими в других схемах . Об этом нужно всегда помнить ,но не всегда учитывать , в зависимости от проекта . Так и в эмуляторах нужно помнить о том ,что в одном цикле идет расчет всех выходов всех элементов и ФБ , особенно когда есть обратные связи и могут возникнуть неоднозначности . Поэтому есть такой инструмент как- задержка на один такт . Пример - постройте сдвигающий регистр на D- триггерах в ОЛ и он не будет работать правильно без линии задержки ,потому что именно за счет этих задержек (в реальной жизни) и работает регистр сдвига на Д триггерах. По опыту работы в ОЛ в большенстве случаев не обращаю внимание на наличие желтых связей. В некоторых проектах без них не обойтись, например нужен детектор изменения бита (короткий импульс) - ставлю исключающее ИЛИ ,на один вход переменная 1 , а на второй эту же переменную 1 ,но с задержкой . Тогда на выходе будет импульс в один такт ...
Я не против "перебежчиков" и рад пополнению наших рядов , но только что бы основная масса пользователей не пострадала от нового устава ...
Самое главное Я это понимаю . Но почему для Нас (разработчиков проектов) переменные зависимые , энерго независимые и сетевые отличаются,Цитата:
Сообщение от rovki
когда мы используем линию задержки .
Но для меня желтый цвет -- это цвет это предупреждения -- что то не корректно сделано .Цитата:
Сообщение от rovki
Я с Вами согласен они даже удобны . Но почему они работают по разному , с типами переменных --Это самый главный вопрос .??Цитата:
Сообщение от rovki
Спасибо . Язык FBD очень понятен , обычным киповцам , которые стараются повысить свой статус и внедрить что то новоеЦитата:
Сообщение от rovki
в производстве ,в котором работают . А их действительно , на много больше , чем программистов работающих на языках
более высокого уровня . Ни чего не должно пострадать в ф. Овен работают здраво мыслящие люди .
А для меня желтый цвет- напоминание ,что есть обратные связи . Если не лень поставь задержку на такт...
Не совсем понял про отличия переменных ??? Внутренние переменные формируются внутри(по тактам) ,а сетевые приходят из вне ,асинхронно .
Речь не про "здравомыслие" ,а про то что может пострадать работоспособность ОЛ (наличие багов) для тех кто не использует этот функционал. И о том ,что программист один и если он занят новым функционалом , то остальные хотелки ,которые пользователи высказали за много лет будут не реализованы в ближайшем будущем. Кроме того возможности самого МК не ограничены и на другие задачи может не хватить .
Как это можно объяснить Вложение 54667 ?????????????Цитата:
Сообщение от rovki
С точки зрение программиста , это должно работать стабильно (не зависимо от типа переменной). Вложение 54668 .
, а оно дергается :confused: или с сетевой переменной Вложение 54672
Маленький пример, поясняющий почему 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 проще выполнить алгоритм и думаю каждый может найти пример в пользу предпочтительного для него языка!Цитата:
Сообщение от Малышев Олег
А если убрать пол страницы комментариев , то очень понятно , проще будет ?
Подозреваю, что не всем это будет удобнее:) Главное чтобы был выбор.Цитата:
Сообщение от Малышев Олег
Золотые слова. :DЦитата:
Сообщение от Ревака Юрий
Возможность описать логику на простом и понятном языке - это здорово и круто!
Понятно, что с помощью FB можно описать условно любую логику, только ведь сам потом не разберёшься :)
Только зачем было выбирать такую дурную семантику? Есть же язык Си - простой и понятный всем, зачем усложнять на пустом месте?
Затем, что это заблуждение, что язык "С" всем понятный и простой :)Цитата:
Сообщение от Dron/9K
Он требует, как минимум, хорошего обучения. А языку FBD я в свое время научился сам, работая просто в симуляторе OwenLogic.
И многим проще работать с готовыми блоками, чем писать условия и текст. Но безусловно все будет зависеть от задачи.
В рамку: "C or FBD" :)Цитата:
Сообщение от IVM
Ну-ну...Цитата:
Сообщение от Dron/9K
Язык С - очень сложный язык. Если писать на нем в стиле С. Если писать на нем в стиле Паскаля (ST в промавтоматике) - теряется смысл языка С.
Даже при стиле Паскаля на Си пишется лаконичнее - букв меньше.
Боюсь, для ПР не нужен ST от слова совсем! Я так понимаю он нужен для сложных программ, алгоритмов, так вот недавно программу рисовал на ОЛ, в принципе несложную, но памяти(ОЗУ) израсходовалось более 2/3. Затея с ST это как танку крылья приделать, мне так кажется!
Вложение 54882
А чем вас ПЛК с 5 языками не устраивает?Цитата:
Сообщение от Ollema
Ну все, у квадратописцев закончились аргументы, можно расслабиться.
Разве стоимость сравнима? Да и скорость разработки выше - простота обращения к дисплею на ПР200.Цитата:
Сообщение от rovki
Сравнима и что?
Метрологическая точность у ПЛК выше. Доступ к дисплею - это да, но это особенность, которую ОВЕН не хочет и не будет исправлять, ибо разработка тех ПЛК давно закончена.
Зато есть доступ к клавиатуре.
Вобщем, глупо мериться запятыми.
Кому удобно, тот пусть и работает. Если в ПР ОВЕН можно будет писать программы на С, то многие скажут спасибо.Цитата:
Сообщение от Андрей Посохов
ПЛК стоит много дороже ПР.Цитата:
Сообщение от rovki
Предлагал ещё при разработке первых ПЛК. Типа раскрывает схемотехнику, BIOS, библиотеки, мониторная программа. Мне объяснили, что ОВЕН не потянет поддержку всего этого. Слишком разные затраты на программирование. Как все же системотехник по образованию я согласился.Цитата:
Сообщение от IVM
Ну и ДОКАЗАТЕЛЬСТВОМ этого является то, что модификация ПЛК с голым линуксом, без рантайма среды разработки, популярностью не пользуется. Вот ваше все - берите и прьграммируйте на С.
я вот лютый гуманитарий, но точно могу сказать, что С от ST в данном контексте НИЧЕМ не отличается кроме того, что в ST больше нужно нажимать на клавиши.Цитата:
Сообщение от ASo
Смысл использования языка C в том, что есть готовый компилятор для микроконтроллера, который используется в ПР ОВЕН. Синтаксисы языков C и ST мало отличаются. Нет никакой нужды рядовому программисту использовать все возможности языка C при написании программ для ПР. Каждый будет использовать язык C в меру своих способностей и потребностей.Цитата:
Сообщение от ASo
Знаете, когда я был молодым да не опытным, я тоже считал, зачем SCADA, когда есть среда разработки под Windows, драйвер протоколов, ... И вперёд. Когда показали, что при этом будет при реализации проекта хотя бы средней сложности, я изменил свое мнение.
Подумайте, зачем разрабатываются и используются платформы программирования ПЛК типа кросс-платформенны кодесис, изаграф, .... фирменных? Все дураки или негодяи, желающие срубить бабло?
В том то и дело, что для целей в которых используется ПР, язык С или ST не нужен совсем.Цитата:
Сообщение от IVM
даже в программах контроллеров для современного оборудования в основном используется LD и FBD.
Так как персоналу, который будет это все обслуживать так легче.
Разве обслуживающий персонал программирует ПР или ПЛК?
Удобство создания управляющей программы в итоге определяет скорость создания, скорость исправлений-доработок, стоимость и спрос.
При поиске причины сбоя обслуживающий персонал подключается к ПЛК и ищет причину сбоя. И в этот момент С никому не нужен.Цитата:
Сообщение от Ollema
Легче с LD и FBD/
Причину сбоя программы должен искать не обслуживающий персонал, а ее автор.
когда автор в другой стране, то кто должен искать причины сбоев?Цитата:
Сообщение от Ollema
все очень просто.Цитата:
Сообщение от Валенок
судя по вашим ответам вы работаете только со своими программами.
а я работаю с оборудованием, которое поставляется из разных стран, и везде программы написаны по разному
и при возникновении сбоев, мне нужно по программе выяснить , в чем причина и дать рекомендации обслуживающему персоналу, что делать.
и как показывает практика, гораздо легче объяснить, если это простые языки программирования.
открой FB___ NW___ посмотри что там, чем читать лекцию по с, ST и т.д.
Тем более вопрос темы ST В ПР
это точно тут не нужно.
А если по любому сбою синхронного привода разработчик вывел одну ошибку "ОШИБКА СЕРВОПРИВОДА" , что тоже стучать по голове персоналу, который ищет ошибку?Цитата:
Сообщение от Валенок
:)
"это точно тут не нужно."
Разработчики Овен сейчас только прочли и им пришлось вычеркнуть ЭТО из своих задач. Раз Вам не нужно. Жаль, мне, конечно, не обязательно, но было бы удобнее.