Страница 3 из 3 ПерваяПервая 123
Показано с 21 по 28 из 28

Тема: к петрову и. (про время и даты ...)

  1. #21

    По умолчанию

    Я похоже тут назначен крайним за косяки МЭК стандарта. Давайте будем реалистами. Вы требуете слишком много от простых инструментов. Ну не написано инструкции к пиле, сколько кубов земли ей можно вырыть. Такой вот ужасный косяк авторов пилы

    Тема поднята непростая, за раз не осилим, давайте постепенно.

    1. Тип TIME – это не время, а длительность. Название в МЭК выбрали неудачно, но так уж сложилось исторически Бывает. Cо страной ‘Гондурас’ тоже промашка вышла

    С TIME можно делать вычисления и сравнения. Внутри это обычный целый тип DWORD со всеми вытекающими. Операции вычислений и сравнений, которые умеет делать сам микропроцессор с целыми без знака, тут подходят. В ассемблер компилируется без вопросов. Остается только сделать преобразование в человеческое представление в компиляторе, отладчике и визуализации.

    Человеческое представление – это дни, часы, минуты и пр. В хелпе есть замечание (*Старший компонент может выходить за свой предел*). Это вполне логично. Например, можем думать в минутах и писать 10 минут, 10.5 (десять с половиной) минут или 1000 минут. Вполне удобно. Можем работать в часах, но тогда уж минут должно быть не больше 59. Можем ввести секунды, но тогда не используем доли минут. Логично. Иначе человек сломает голову при разборе.

    К хелпу есть базовое требование чтобы букв было минимум при максимуме пользы. Стоит ли по TIME писать в нем подробнее, чем есть сейчас?

    2. Займемся TOD - время дня. Название хорошее. В хелпе написано: ‘Диапазон значений TOD от: 00:00:00 до 23:59:59.999.’ Попробуем ввести TOD1 := TOD#26:00:00; Компилятор дает ошибку. Правильный компилятор. Проверка делается на ПК и не напрягает проц. ПЛК. Пусть она будет.

    Тип TOD обычно нужен чтобы получить время из некоего места, например аппаратных часов, и выполнить нужную операцию в нужное время. Например, так:

    IF TOD1 > TOD#17:00 THEN bLight := FALSE END_IF

    Можно применять сравнения. Можно выполнять преобразования. Можно вычитать и получать длительность. Можно добавлять длительность. Дополняет TOD тип DATA. Можем сделать структуру с датой и точным, до мс, временем. Нормально.

    Остается вопрос о контроле переполнения TOD. Стоит ли в каждую вычислительную операцию вводить обрезание по суткам? Хорошо, будет защита от дурака. Но, это дополнительный процессорный код на каждую операцию, он однозначно даст тормоза всех вычислений. Я бы не стал даже только поэтому. Кроме того, после добавления к времени дня интервалов может получиться новый день. Может быть нужда его поймать и перенести в дату. С обрезанием получим большой облом. Итого, просится не водить контроль, а считать что программист умный и понимает что делает. ИМХО CoDeSys хорош быстрым кодом и расширениями МЭК, рассчитанными на умных пользователей. Значит все гармонично.

    В ключе этих мыслей TIME_TO_TOD( T#1d1s ) должно дать TOD#24:00:01. Оно и дает.

    Пока не вижу никакого криминала с TOD в CoDeSys. Можем поменять в хелпе фразу c ‘Диапазон значений TOD от: 00:00:00 до 23:59:59.999.’ на: ‘Диапазон значений констант TOD от: 00:00:00 до 23:59:59.999.’ Будет точнее. Меняем?

  2. #22

    По умолчанию

    Цитата Сообщение от BETEP Посмотреть сообщение
    ...кодесису действительно не хватает полноценной библиотеки для работы с датой...
    Да, и много других не хватает! В статье не было даже попытки сделать биб-ку. Задача была разжевать базовые типы на примерах. Накрутить вокруг даты можно кучу полезных функций – планировщики и др. и пр. Давайте сделаем такую биб-ку, но.. только в следующем году. Коллеги настойчиво предлагают попробовать интересный подарочный напиток ‘Овновка’, пора С наступающим!

  3. #23

    По умолчанию

    Цитата Сообщение от Валенок Посмотреть сообщение
    А про : ( A + B - A ) <> ( A - A + B ) таки и не пояснили.
    Согласен, что вычисления с датой могут вызывать законное удивление.

    Увы, нельзя переделывать CoDeSys под здравый смысл, который мы имеем сейчас. Он обязан подчинятся стандарту МЭК 61131-3 и здравому смыслу, который тогда был. Представляете, какой он был? Была куча очень разных ПЛК с собственными языками. В некоторых, очень продвинутых, были аппаратные часы. В них год, месяц и пр. представлены отдельными регистрами. Так удобно для вывода на цифровые индикаторы. Для глобализации ПЛК желательно бы ввести единообразное ‘человеческое’ представление. Ну, вот и ввели тип data и повелели его представлять как 'year'-'month'-'day '. Внутренне представление стандартом не регламентируется никак! Это может быть целое (как в CoDeSys) или структура. Кому как удобнее. Никаких вычислительных операций с таким типом быть не должно. Единственное, не знаю почему, возможно кто-то особо настаивал, прописали вычитание двух дат с результатом TIME. Но, с особым примечанием: deprecated (не рекомендуется).

    Разница двух дат не вызывает вопросов. Со сложением сложнее. Вчера + полдня = вечером уже сегодня, а утром еще вчера. Часа в дате нет и ‘нормальный’ ответ может быть разный у разных людей. Без ‘Овновки’ не разобраться

    >>Эти приколы с DATE - нормальны?
    Соответствуют требованим стандарта МЭК.
    Последний раз редактировалось Игорь Петров; 27.12.2010 в 18:06.

  4. #24

    По умолчанию

    Цитата Сообщение от BETEP Посмотреть сообщение
    ...если есть желание улучшать кодесис V2, то похоже уже поздно.
    Хм. Все ‘опытно-революционные’ идеи вносятся только в V3. Это логично. В V2 продолжается шлифовка. За этот год прошла куча доработок. Документацию правим регулярно. В декабре провели тотальный контроль интерфейса, одних сообщений на русском добавлено под 2 сотни. В следующий патч все будет включено.

    Что касается изменений среды программирования и компилятора, то это тоже возможно. Конечно, нужно понимать, что это всегда серьезная работа, а ресурсы не безграничны и нужно верно расставлять приоритеты. Предложение должно быть проработано и должно быть доказано, что это оно нужно не только одному человеку. 24-25 Мая 2011 состоится конференция в Смоленске. Пожалуйста, подготовьте презентацию с предложениями. В расписании под это время мы выкроим. Интерес к этой теме будет точно и обсуждение будет точно. Реально принять решение о необходимости планирования и проведения такой работы может только Дитер Хесс. Он руководитель проекта CoDeSys. За математику отвечает Хилмар Панцер. Они оба любезно согласились приехать на конференцию, чтобы рассказать своих работах и нас послушать. Так что, шлагбаум открыт.

  5. #25
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,254

    По умолчанию

    Не выдержал до юбилея темы, решил спросить
    команда STRING_TO_TIME('T#9h30m'); не превращает строчку в тот же интервал, в онлайне переменная TIME выглядит как T#570m...
    Вопрос, как выудить из этой переменной часы не прибегая к конвертированию в DWORD?

  6. #26

    По умолчанию

    div 60
    p.s. у меня временная никогда не принимает тип старшего числа больше минуты
    + при задании дней в строковой преобразование игнорирует эти дни
    Последний раз редактировалось swerder; 15.11.2011 в 15:36.

  7. #27

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    Вопрос, как выудить из этой переменной часы не прибегая к конвертированию в DWORD?
    V2.3
    V3.4 показывает T#9h30m

  8. #28
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,254

    По умолчанию

    Может Вы как нибудь Дитеру или Хилмару намекнете, чтоб шлифанули 2.3

Страница 3 из 3 ПерваяПервая 123

Ваши права

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