это известно давно и исправляться не будет ,используйте универсальный счтчикСообщение от Project M
это известно давно и исправляться не будет ,используйте универсальный счтчик
электронщик до мозга костей и не только
Благодарю, воспользовался. Получилось нагромождение.
Грустно, что такая элементарная вещь игнорируется производителем. По "русски" как-то.
А побуду-ка я "адвокатом ОВЕН"
Вот смотрите: сейчас write to FB игнорируется.
Если выйдет обновление ОЛ, в котором write to FB для CTU заработает, то старые программы могут испортиться.
Грубо говоря, раньше программы могли работать лишь из-за того, что "write to FB в CTU" не выполнялось.
Представим ситуацию: выходит обновление, открываем в нём старый проект, записываем в реле и на эксплуататора выливается ведро помоев.
Надо это? Разумеется, это никому не нужно.
По-научному "неработоспособность связки write to FB и CTU" называется "обратная совместимость". В старых версиях ОЛ была ошибка, кто-то мог завязаться на именно такое поведение (сам того не зная) и теперь просто так исправлять нельзя.
А теперь побуду адвокатом ОЛ пользователей: так можно вообще дойти до того, что все ошибки вредно исправлять.
В развитых средствах давным-давно используется автоматическая миграция кода на новую версию.
Открываем, например, старый ОЛ проект в новой версии и ОЛ говорит: "у вас тут write to FB для CTU, но раньше это не работало, а сейчас есть возможность починить. Чиним?"
Грубо говоря, если создаём новый проект, то там всё работает. А, если открываем старый, то ОЛ находит проблемную часть и предлагает починить.
Почему такое не делается в ОЛ -- непонятно.
Почему же не делается?! Делается и уже очень давно, иначе развитие лоджика застопорилось бы много лет назад. Когда задумывался лоджик ряд вещей было упущено, цели лоджику ставились другие, не такие как сейчас. Насчет того, что что-то разработчики не сделали, какие-то задачи упустили... Есть оперативный план, в него входят задачи, сортируются по приоритетам. Если какая-либо задача не была сделана, значит коэффициент важности и трудозатратности этой задачи не в верху списка.
Дать доступ к CTU - задача как менее приоритетная так и более трудозатратная. Как rovki уже сказал этот блок выполнен как гибрид. Он и не макрос и не элементарный блок. Поэтому есть определенные сложности. Никто не говорит что они нерешаемые, но время будет потрачено.
программер
Вы меня неправильно поняли. В том сообщении (#221) я не спрашивал "почему в ОЛ не исправляется конкретная ошибка с CTU". Я спрашивал почему в ОЛ не встречается подход, когда среда обнаруживает устаревшие конструкции кода и предлагает пользователю обновить их до работоспособных.
Возьмём для примера те же "неявные линии задержки". Сейчас ОЛ 1.9 обнаруживает циклы и говорит "у вас тут цикл". Предлагает ли ОЛ заменить одну из связей на линию задержки? Нет. Могла бы? Могла.
Точно так же: "Вообще говоря, у вас тут используется <<write to FB + CTU>>. Такая конструкция не работает. Хотите заменить её на <<write to FB + CTUD>>?" И варианты <<Да, конечно>>, <<Нет, и так сойдёт>>. Иными словами, само "устранение проблемы" можно свести к тому, чтобы среда просто предлагала пользователю исправить CTU на CTUD (ну или как называется рабочий блок в ОЛ). Т.е. CTU переделывать не нужно, прошивку обновлять не нужно. Достаточно просто на стороне ОЛ сделать замену CTU блока на рабочий. Я не призываю именно к такому варианту решения. Я просто показываю пример, как может приносить пользу механизм "нашли устаревший код и предложили пользователю упростить-исправить".
Если оказывается, что про подобные автоподсказки думали и они не поместились в бюджет, то, конечно, печально. Ну, делали же подкраску циклов из связей. Наверняка несложно было бы за одно сделать и замену связи на линию задержки с подтверждения пользователя.
PS. Про то, почему не решается конкретная проблема с CTU меня не интересует (как я и писал в #226) и я прекрасно понимаю что такое приоритеты.
Последний раз редактировалось Владимир Ситников; 19.05.2017 в 22:23.
Я правильно понял о чем Вы говорите...
CTU+WriteToFb не существует, поэтому анализатору и не надо ничего делать. Со старыми проектами тут проблем как раз таки такой нет, какую Вы описываете. Тут только решение проблемы с "гибридными" блоками.
А вот кстати насчет циклических связей... Есть задача похожая задача.
программер
А столько текста исписали ...а оказывается не интересует
Поумничили и хватит (Ситникову).
Что вообще об этом говорить ,когда есть макросы ,создал свой CTU ,вывел вход для уставки и забыл ...какие проблемы ?
Последний раз редактировалось rovki; 19.05.2017 в 22:51.
Сильно сказано. Честно говоря, не хватает образования, чтобы представить, как "не используемая новая возможность" может повредить старый проект.
Умный человек - с лёгкостью решает любые проблемы. Мудрый - их не создаёт.
https://vk.com/a.matica
Объясняю:
1) В проекте была связка write to FB + CTU.
2) Да, параметр CTU не обновлялся
3) Но блок write to FB пытался записать в CTU какую-то муть. И лишь ошибка в ОЛ была тем самым звеном, которое удерживало схему в работоспособном состоянии
4) Если теперь "ошибку исправить", то write to FB таки сможет записать свою муть в CTU, схема начнёт работать по-другому и, соответственно, может случиться авария на производстве.
Разумеется, такое не в каждом проекте может быть. Но полностью исключать такое нельзя. Поэтому трезвый подход (с точки зрения ОВЕН) состоит в том, чтобы рассматривать эту "особенность поведения ОЛ" именно как особенность поведения, а не как "ошибку, которую просто исправляем и всего делов". Повторюсь: править это поведение можно и нужно, но не просто "теперь это работает так-то", а так, чтобы старые проекты не ломались.
В общем, ключевое слово -- обратная совместимость.
Ваши права
