Да ,арифметика со временем -не привычное дело ....
Да ,арифметика со временем -не привычное дело ....
электронщик до мозга костей и не только
я вот как то предлагал иметь время в ПРке в виде общего количества миллисекунд или секунд, как удобно было бы арифметические операции делать, независимо от перехода на следующие сутки, а вернуть в нормальное представление не так уж много функций понадобилось бы, так нет закидали меня "помидорами"![]()
А как в кодесис работают со временем ,как там учитывают переход через ноль...при сравнении данного типа
электронщик до мозга костей и не только
ну как я предлагал макросы для вычисления фаз восход/закат из оскатовских библиотек, это если с RTS работать, а так я например использую функцию TIME(), преобразую её в двойное слово (целочисленное по вашему) и вычисляю разницу вышеуказанной функции с запомненым значением, получаю прошедшее время в секундах
У меня вроде бы все варианты проверяются, кроме варианта "В включается, когда А еще не выключилось, а выключается, когда А уже включилось". Вот в этот случай я и уперся. Хотя я тут выкладывал рабочий вариант, но он действует только в случае фиксированных интервалов 18 и 12, да и то с "костылями" внутри. А хочется универсальный сделать, чтобы с любыми уставками работал![]()
Вроде победил егоТеперь должен работать правильно во всем диапазоне и с любыми интервалами. Проверяйте!
Тогда вставляем ваш макрос в мой проект ....![]()
электронщик до мозга костей и не только
Он простой, спору нет. Жалко только, не работаетПосле А=18:00 и включения B в полночь(ну или например А=23:00 B=01:00) он ошибку показывает, хотя все правильно по алгоритму и режим В завершает работу в пределах режима А. Я примерно такой уже пробовал сделать, с "костылями"(как раз обслуживающими кусок времени с 18:00 до 0:00) он даже правильно работает, выкладывал его. Но он получился не универсальным, а лучше один раз сделать хорошо, чтобы потом не переделывать каждый раз "костыли" под очередную уставку.
Теперь про Ваш. По состоянию выходов двух макросов видно, что они по-разному работают, а должны одинаково, если алгоритм один и тот же отрабатывается. Ну и если другие промежутки поставить(не 1080 минут и 720), то и время ошибочное другое будет. Повторюсь, мой по задумке считает адекватно при любых уставках интервалов и времени старта режимов, хотя скорее всего его и упростить можно было бы. Но повторюсь еще раз, я только учусь...
P.S. Спасибо, что занимаетесь моей проблемой, я во время этих попыток разобраться в алгоритмах узнаю для себя что-то новое постоянно![]()
Последний раз редактировалось Budka; 30.11.2013 в 01:06.
Прекрасно понимая, что у всех есть своя работа и свои дела, не прошу готового решения. Но может кто-нибудь из уважаемого сообщества хотя бы с алгоритмом поможет? Таймеры двух видов уже есть, проверку тоже осилили, а вот то самое переключение по полчаса в день двенадцать дней подряд - не могу алгоритм простой придумать. Но понимаю, что нужно плясать от реальной даты(номер дня в году), чтобы энергонезависимость была, и при этом только одну переменную энергонезависимую использовать(дату переключения). Пока задумка такая: в момент переключения записываем в энергонезависимую переменную номер дня, дальше считаем от него. Берем номер дня, прибавляем 1, в минутах А и В проверяем, можно ли с одной стороны отнять 30 минут, чтобы не вылезти за допустимые пределы, и назначаем на этот день А-30минут(если с одной стороны нельзя, проверяем с другой стороны и отнимаем). Берем опять номер дня, прибавляем 2, повторяем с 60 минутами, если не проходит - отнимаем 30 с одной, 30 с другой и т.д., пока не останется меньше 30 минут с каждой стороны, их не обрабатываем в последний день, а уже включаем режим В, потому что это и есть последние 30 минут. Но очень громоздко получается, на каждый день свой блок проверок и расчетов. Или я не в ту сторону думаю?Может, как-то проще можно сделать?
Последний раз редактировалось Budka; 30.11.2013 в 12:20.