Страница 2 из 2 ПерваяПервая 12
Показано с 11 по 16 из 16

Тема: Разная работа программы в эмуляторе и на контроллере

  1. #11

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    Вот ключевые слова, здесь почему то Вы не отрицаете факта, что придется подстраиваться, но требуете от эмуляции точного выполнения физики процесса. Может причина не в ПЛК, а в программе отвечающей за создание адекватной модели регулируемой среды
    Что Вы! Ничего я не требовал, я спрашивал "Каковы могут быть причины разной работы программы ...". И получил от Вас и Игоря Петрова ответы, которые мне понятны. Спасибо.

  2. #12

    По умолчанию

    Цитата Сообщение от Игорь Петров Посмотреть сообщение
    По жизни мелкие правки программ часто несколько опережают мануалы.
    На мой взгляд, сначала должна писаться документация, потом программа. Это относится и к мелким правкам. Но это дискуссия уже на другую тему. Извините.

    Цитата Сообщение от Игорь Петров Посмотреть сообщение
    Он намеренно прогоняет программу намеренно медленнее. Все вычисления отрабатываются, но надо понимать, что не в реальном времени.
    Беда не в том, что медленнее, это как раз не страшно, тут у меня вопросов бы не возникло. На разных машинах программы тоже с разной скоростью идут. Беда в том, что из-за разного масштаба времени, о чем сами приборы, конечно, не знают, они идут по-разному. Эту особенность и причину Вы объяснили, а я понял. Это хорошо. Будем с этим считаться.
    Спасибо.

  3. #13

    По умолчанию

    Цитата Сообщение от Михаил Иванович Посмотреть сообщение
    На мой взгляд, сначала должна писаться документация, потом программа. Это относится и к мелким правкам.
    Согласен, но... Вы сдаете важный горящий объект, попросите внести мелкую правку. Вместо помощи за 5 минут, программист зарядит это дело в отдел технической документации.. после праздников они согласуют.. Боюсь, что мой взгляд в такой ситуации выражался бы только матом

    Если серьезно, то документацию и ПО пишут не боги. Стоит взять за правило тестировать самому любую новую функцию или блок, прежде чем использовать в деле. Это и в CoDeSys и в любых других системах является хорошей идеей.

  4. #14

    По умолчанию

    Цитата Сообщение от Игорь Петров Посмотреть сообщение
    Согласен, но... Вы сдаете важный горящий объект, попросите внести мелкую правку. Вместо помощи за 5 минут, программист зарядит это дело в отдел технической документации.. после праздников они согласуют.. Боюсь, что мой взгляд в такой ситуации выражался бы только матом
    Вы утрируете ситуацию для того, чтобы показать ее более ярко. С яркостью - согласен. Но, я думаю. что все не так страшно. В приведенном Вами случае программист перед тем, как менять саму программу, должен написать за 5 минут техническое задание на коррекцию программы в самой простой свободной форме, еще за 5 минут - проект вносимого изменения, тоже в свободной форме, причем первое и второе можно совместить, еще за 5 минут внести эти изменения, потом потратить пол-часа на проверку того, не навредил-ли, и если все в порядке, зафиксировать внесенные изменения, получить подпись заказчика на акте испытаний внесенных изменений. А уж "после праздников", если они уже наступили, передать свои листочки в соответствующий отдел, они с ними разберутся, дадут программисту втык, за то, что не по форме, наябедничают начальству, начальство, как водится наградит непричастных и накажет невиновных, листочки в первозданном виде подошьют куда надо ибо выяснится, что и такая форма не противоречит ГОСТу, внесут запись в лист изменений, заведут на это изменение карточку и разошлют ее смежникам - держателям проектной документации. И только такой путь (за исключением ябеды начальству) позволит не утонуть в волнах вносимых изменений. Ибо опыт показывает, что документация "потом" - не пишется. То о чем я говорю называется элементарной производственной дисциплиной. Конечно, это требует определенных волевых усилий, для огромного большинства программистов просто немыслимых. Отсюда и рождаются всякие концепции "экстремального программирования" и т.п. Приведенная Вами в примере "помощь за 5 минут" в дальнейшем обернется сутками поиска где, когда и зачем кто-то что-то внес. А если человек уволился, то это может стать вообще безнадёжным делом. Уверен, что Вы с этим сталкивались, если не при разработке конкретной программы, то в какой-то иной ситуации, потому что это явление общее. Так может быть, лучше потратить час на простое документирование?

    Цитата Сообщение от Игорь Петров Посмотреть сообщение
    Если серьезно, то документацию и ПО пишут не боги. Стоит взять за правило тестировать самому любую новую функцию или блок, прежде чем использовать в деле. Это и в CoDeSys и в любых других системах является хорошей идеей.
    Совершенно согласен. Собственно, именно это и является источником моих вопросов, на которые Вы и другие специалисты отвечаете, за что еще раз спасибо.
    Последний раз редактировалось Михаил Иванович; 28.04.2012 в 09:10.

  5. #15

    По умолчанию

    Всегда разрабатываются детальные спецификации, но например я не способен все придумать сразу, особенно если делается нечто не имеющее аналогов. Многие вещи рождаются в процессе, обкатываются, притираются, потом описываются. Хорошо бы художнику зайти в Лувр, получить описание требуемого шедевра и спокойно его нарисовать

    Цитата Сообщение от Михаил Иванович Посмотреть сообщение
    Приведенная Вами в примере "помощь за 5 минут" в дальнейшем обернется сутками поиска где, когда и зачем кто-то что-то внес. А если человек уволился.......это явление общее. Так может быть, лучше потратить час на простое документирование?
    Будет как у юристов – поправка 215 к поправке закону, инструкция по чтению инструкции...

    Не надо сутки поиска. Проблема решается системами управления версиями. Для CoDeSys V2 используется ENI. В V3 Professional Edition интегрирован SVN. На конференции раскроем эту тему.

  6. #16

    По умолчанию

    Цитата Сообщение от Игорь Петров Посмотреть сообщение
    я не способен все придумать сразу, особенно если делается нечто не имеющее аналогов. Многие вещи рождаются в процессе, обкатываются, притираются, потом описываются.
    Никто не способен. Есть процесс разработки, есть пробы, ошибки, решения. И бывает так, что изначальный вариант меняется до неузнаваемости - это объективно неизбежный процесс. Но если изначально нет Тех. задания, нет проекта с первоначальным описанием решений на основании того, что "все равно изменится, потом все опишу", не делается текущих описаний в этом процессе на том же основании, то "потом" - никогда не наступает. Почему? Первое - идеология. Человек, который придерживается идеологии "потом опишу" не способен на это. Он потому её и придерживается, что она позволяет ускользнуть от невозможного для него дела, найти себе текущее оправдание. Второе - забывается все быстро. Даже если добросовестный сотрудник действительно может и хочет описать потом, то у него может это не получиться или придётся затратить огромное, несопоставимое с самой работой время. Пока вы что-то делаете, пока "в теме", все кажется понятным. Проходит месяц, настаёт "потом" - и все надо поднимать заново. Сидеть и разбираться - а зачем такое было написано, выбрано такое решение. Неужели Вы с этим не сталкивались? У меня у самого такое бывало, поэтому взял за правило документировать, хоть пару строк - зачем, почему, как. Всего три вопроса и надо осветить. А если в проекте участвует много людей и один из них что-то важное забыл? Или уволился. Не было у Вас таких случаев? У меня, к счастью, не было, а с некоторых пор вообще предпочитаю работать в одиночку, но я такое наблюдал. Нельзя написать "потом", "потом" можно только подытожить, создать создать на основе текущих локальных документов новый общий документ. Вам хочется использовать систему управления версиями? Пожалуйста. Кто-то использует листочек бумажки и карандаш, кто-то делает заметки в Word'е, кто-то по каждому поводу запускает сервер с Аксаптой. Не важно, что используется, важно, чтобы этот процесс был системным, чтобы он был обязательной частью разработки. На каждом этапе. Это и называется "производственная дисциплина". И я речь веду именно о ней - не путать с отсидкой. Её автоматизировать невозможно. И без неё любая система, в том числе ENI, в том числе любая ERP-система превращается в автоматизированный бардак. А это совсем плохо.
    Должен ещё сказать, что у меня есть впечатление, что мы как-то по-разному понимаем предмет обсуждения. Не могу я себе представить, что Вы не понимаете необходимости документирования проекта на всем протяжении процесса его реализации.
    О конференции я знаю, но, увы, присутствовать не смогу.
    Спасибо.

Страница 2 из 2 ПерваяПервая 12

Похожие темы

  1. Ответов: 12
    Последнее сообщение: 11.12.2012, 22:05
  2. часы в контроллере
    от AKHolod в разделе ПЛК1хх
    Ответов: 9
    Последнее сообщение: 08.12.2010, 23:55
  3. Обновление проектов в контроллере у заказчика.
    от Дмитрий Артюховский в разделе ПЛК1хх
    Ответов: 28
    Последнее сообщение: 15.09.2010, 14:25
  4. ПИ регулирование на контроллере
    от Максим_Фалалеев в разделе ПЛК1хх
    Ответов: 1
    Последнее сообщение: 01.12.2008, 10:21
  5. Не держится boot в контроллере
    от Igont в разделе ПЛК1хх
    Ответов: 5
    Последнее сообщение: 17.09.2007, 11:12

Ваши права

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