Страница 23 из 39 ПерваяПервая ... 13212223242533 ... ПоследняяПоследняя
Показано с 221 по 230 из 385

Тема: Бэта-версия OWEN Logic 1.9

  1. #221

    По умолчанию

    Цитата Сообщение от Владимир Ситников Посмотреть сообщение
    По-научному "неработоспособность связки write to FB и CTU" называется "обратная совместимость". В старых версиях ОЛ была ошибка, кто-то мог завязаться на именно такое поведение (сам того не зная) и теперь просто так исправлять нельзя.
    А теперь побуду адвокатом ОЛ пользователей: так можно вообще дойти до того, что все ошибки вредно исправлять.
    В развитых средствах давным-давно используется автоматическая миграция кода на новую версию.

    Открываем, например, старый ОЛ проект в новой версии и ОЛ говорит: "у вас тут write to FB для CTU, но раньше это не работало, а сейчас есть возможность починить. Чиним?"
    Грубо говоря, если создаём новый проект, то там всё работает. А, если открываем старый, то ОЛ находит проблемную часть и предлагает починить.

    Почему такое не делается в ОЛ -- непонятно.

  2. #222
    Пользователь
    Регистрация
    17.06.2016
    Адрес
    Тольятти
    Сообщений
    62

    По умолчанию

    Цитата Сообщение от Владимир Ситников Посмотреть сообщение
    А побуду-ка я "адвокатом ОВЕН"
    Если выйдет обновление ОЛ, в котором write to FB для CTU заработает, то старые программы могут испортиться.
    Сильно сказано. Честно говоря, не хватает образования, чтобы представить, как "не используемая новая возможность" может повредить старый проект.
    Умный человек - с лёгкостью решает любые проблемы. Мудрый - их не создаёт.
    https://vk.com/a.matica

  3. #223

    По умолчанию

    Цитата Сообщение от Project M Посмотреть сообщение
    Сильно сказано. Честно говоря, не хватает образования, чтобы представить, как "не используемая новая возможность" может повредить старый проект.
    Объясняю:
    1) В проекте была связка write to FB + CTU.
    2) Да, параметр CTU не обновлялся
    3) Но блок write to FB пытался записать в CTU какую-то муть. И лишь ошибка в ОЛ была тем самым звеном, которое удерживало схему в работоспособном состоянии
    4) Если теперь "ошибку исправить", то write to FB таки сможет записать свою муть в CTU, схема начнёт работать по-другому и, соответственно, может случиться авария на производстве.

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

    В общем, ключевое слово -- обратная совместимость.

  4. #224
    Пользователь
    Регистрация
    21.01.2011
    Адрес
    еБург
    Сообщений
    893

    По умолчанию

    Цитата Сообщение от Project M Посмотреть сообщение
    Решил вопрос таким образом.
    Вложение 31222
    Благодарю за помощь.
    положу тут, пусть полежит

    fEQ с точностью...
    Вложения Вложения
    • Тип файла: rar fEQ.rar (30.5 Кб, Просмотров: 21)
    начинающий профессионал

  5. #225
    Пользователь Аватар для rovki
    Регистрация
    03.01.2010
    Адрес
    Чехов
    Сообщений
    11,829

    По умолчанию

    Цитата Сообщение от Владимир Ситников Посмотреть сообщение
    Объясняю:
    1) В проекте была связка write to FB + CTU.
    2) Да, параметр CTU не обновлялся
    3) Но блок write to FB пытался записать в CTU какую-то муть. И лишь ошибка в ОЛ была тем самым звеном, которое удерживало схему в работоспособном состоянии
    4) Если теперь "ошибку исправить", то write to FB таки сможет записать свою муть в CTU, схема начнёт работать по-другому и, соответственно, может случиться авария на производстве.

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

    В общем, ключевое слово -- обратная совместимость.
    Очередное гадание ....
    ФБ CTU был сделан разработчиками другими средствами ,получили что то типа макроса ,без возможности залезть во внутрь .Потому и блок записи в него не работает ....
    электронщик до мозга костей и не только

  6. #226

    По умолчанию

    Цитата Сообщение от rovki Посмотреть сообщение
    Очередное гадание ....
    Зачем писать всякую муть про гадание? Я не гадаю, а реальных примерах рассматриваю аргументы.
    Поосторожнее со словами.
    Когда умные обсуждают программные средства, то вы слушайте, и учитесь (если хотите).

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

    Цитата Сообщение от rovki Посмотреть сообщение
    ФБ CTU был сделан разработчиками другими средствами ,получили что то типа макроса ,без возможности залезть во внутрь .Потому и блок записи в него не работает
    Мне (как и любому другому пользователю ОЛ) должно быть совершенно без разницы в каком средстве сделан блок CTU. Я уверен, что ОВЕН могут починить блок CTU. И я уверен, что эта починка не затребует хоть сколько-нибудь существенных ресурсов.

    Почему именно они не чинят -- я вообще без понятия. Может, программисты в отпуске, может забылась задача в общем списке, может все заняты на проекте owencloud. Да мало ли причин?

    Я же говорил про другое: даже, если организационных проблем нет (т.е. волшебная палочка взмахнула, программисты есть, тестировщики есть, все готовы починить связку write to FB + CTU), то всё равно есть техническая проблема. Вот нельзя просто взять и изменить поведение старого блока CTU -- это может сломать имеющиеся ОЛ проекты. Я не пытаюсь угадать/предполагать причину того, что ОВЕН не исправляет эту "ошибку".

  7. #227

    По умолчанию

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

    Открываем, например, старый ОЛ проект в новой версии и ОЛ говорит: "у вас тут write to FB для CTU, но раньше это не работало, а сейчас есть возможность починить. Чиним?"
    Грубо говоря, если создаём новый проект, то там всё работает. А, если открываем старый, то ОЛ находит проблемную часть и предлагает починить.

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

  8. #228

    По умолчанию

    Цитата Сообщение от wal79 Посмотреть сообщение
    Почему же не делается?! Делается и уже очень давно, иначе развитие лоджика застопорилось бы много лет назад.
    Вы меня неправильно поняли. В том сообщении (#221) я не спрашивал "почему в ОЛ не исправляется конкретная ошибка с CTU". Я спрашивал почему в ОЛ не встречается подход, когда среда обнаруживает устаревшие конструкции кода и предлагает пользователю обновить их до работоспособных.

    Возьмём для примера те же "неявные линии задержки". Сейчас ОЛ 1.9 обнаруживает циклы и говорит "у вас тут цикл". Предлагает ли ОЛ заменить одну из связей на линию задержки? Нет. Могла бы? Могла.

    Точно так же: "Вообще говоря, у вас тут используется <<write to FB + CTU>>. Такая конструкция не работает. Хотите заменить её на <<write to FB + CTUD>>?" И варианты <<Да, конечно>>, <<Нет, и так сойдёт>>. Иными словами, само "устранение проблемы" можно свести к тому, чтобы среда просто предлагала пользователю исправить CTU на CTUD (ну или как называется рабочий блок в ОЛ). Т.е. CTU переделывать не нужно, прошивку обновлять не нужно. Достаточно просто на стороне ОЛ сделать замену CTU блока на рабочий. Я не призываю именно к такому варианту решения. Я просто показываю пример, как может приносить пользу механизм "нашли устаревший код и предложили пользователю упростить-исправить".

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

    PS. Про то, почему не решается конкретная проблема с CTU меня не интересует (как я и писал в #226) и я прекрасно понимаю что такое приоритеты.
    Последний раз редактировалось Владимир Ситников; 19.05.2017 в 22:23.

  9. #229
    Пользователь Аватар для rovki
    Регистрация
    03.01.2010
    Адрес
    Чехов
    Сообщений
    11,829

    По умолчанию

    Цитата Сообщение от Владимир Ситников Посмотреть сообщение

    PS. Про то, почему не решается конкретная проблема с CTU меня не интересует (как я и писал в #226) и я прекрасно понимаю что такое приоритеты.
    А столько текста исписали ...а оказывается не интересует
    Цитата Сообщение от wal79 Посмотреть сообщение
    Почему же не делается?! Как rovki уже сказал этот блок выполнен как гибрид. Он и не макрос и не элементарный блок. .
    Поумничили и хватит (Ситникову).
    Что вообще об этом говорить ,когда есть макросы ,создал свой CTU ,вывел вход для уставки и забыл ...какие проблемы ?
    Последний раз редактировалось rovki; 19.05.2017 в 22:51.
    электронщик до мозга костей и не только

  10. #230

    По умолчанию

    Цитата Сообщение от Владимир Ситников Посмотреть сообщение
    Вы меня неправильно поняли. В том сообщении (#221) я не спрашивал "почему в ОЛ не исправляется конкретная ошибка с CTU". Я спрашивал почему в ОЛ не встречается подход, когда среда обнаруживает устаревшие конструкции кода и предлагает пользователю обновить их до работоспособных.

    Возьмём для примера те же "неявные линии задержки". Сейчас ОЛ 1.9 обнаруживает циклы и говорит "у вас тут цикл". Предлагает ли ОЛ заменить одну из связей на линию задержки? Нет. Могла бы? Могла.

    Точно так же: "Вообще говоря, у вас тут используется <<write to FB + CTU>>. Такая конструкция не работает. Хотите заменить её на <<write to FB + CTUD>>?" И варианты <<Да, конечно>>, <<Нет, и так сойдёт>>. Иными словами, само "устранение проблемы" можно свести к тому, чтобы среда просто предлагала пользователю исправить CTU на CTUD (ну или как называется рабочий блок в ОЛ). Т.е. CTU переделывать не нужно, прошивку обновлять не нужно. Достаточно просто на стороне ОЛ сделать замену CTU блока на рабочий. Я не призываю именно к такому варианту решения. Я просто показываю пример, как может приносить пользу механизм "нашли устаревший код и предложили пользователю упростить-исправить".

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

    PS. Про то, почему не решается конкретная проблема с CTU меня не интересует (как я и писал в #226) и я прекрасно понимаю что такое приоритеты.
    Я правильно понял о чем Вы говорите...
    CTU+WriteToFb не существует, поэтому анализатору и не надо ничего делать. Со старыми проектами тут проблем как раз таки такой нет, какую Вы описываете. Тут только решение проблемы с "гибридными" блоками.
    А вот кстати насчет циклических связей... Есть задача похожая задача.
    программер

Страница 23 из 39 ПерваяПервая ... 13212223242533 ... ПоследняяПоследняя

Похожие темы

  1. OWEN Logic v1.7
    от Евгений Сергеевич в разделе Среда программирования OWEN Logic
    Ответов: 404
    Последнее сообщение: 25.08.2020, 15:17
  2. Owen Logic версия: 1.8.4 build 108 beta
    от Руслпн в разделе Программируемые реле
    Ответов: 108
    Последнее сообщение: 29.12.2015, 08:21
  3. Версия OWEN Logic.
    от smk1635 в разделе Трёп (Курилка)
    Ответов: 5
    Последнее сообщение: 25.05.2014, 22:18
  4. ПО OWEN Logic !!!
    от Ельцов Андрей в разделе Программируемые реле
    Ответов: 3
    Последнее сообщение: 11.10.2011, 16:33
  5. OWEN Logic 1.2.0.14b
    от Ельцов Андрей в разделе Программируемые реле
    Ответов: 40
    Последнее сообщение: 21.02.2011, 14:16

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •