Codesys2.3 на выходе был ШИМ сигнал

[Михаил Иванович]

Ну хоть одним глазком ?

Попробуйте подставить в преобразование типов TIME_TO_REAL
значение 4194967295 ms, названное в документации максимальным значением для типа TIME. Может это и так, только что Вы получите на выходе? У меня, например, получается совсем не это число. Ограничения в преобразовании не указано, значит что-то не так с реальным диапазоном.
Можете поэкспериментировать с обратными преобразованиями из REAL. Там Вы получите тоже странные, на мой взгляд результаты. Уверен, что Вы этого не пробовали делать.

[Валенок]

Попробуйте подставить в преобразование типов TIME_TO_REAL
значение 4194967295 ms, названное в документации максимальным значением для типа TIME. Может это и так, только что Вы получите на выходе? У меня, например, получается совсем не это число. Ограничения в преобразовании не указано, значит что-то не так с реальным диапазоном.
Можете поэкспериментировать с обратными преобразованиями из REAL. Там Вы получите тоже странные, на мой взгляд результаты. Уверен, что Вы этого не пробовали делать.

T:time R1,R2:real;

R1:=-1;
T:=real_to_time(R1);
R2:=time_to_real(T) => -1 Чего тут не это ?

[Михаил Иванович]

T:time R1,R2:real;

R1:=-1;
T:=real_to_time(R1);
R2:=time_to_real(T) => -1 Чего тут не это ?

Все не так.
1. Указанное мною в предыдущем сообщении число принадлежит по документации диапазону значений TIME. Следовательно, на выходе должно получиться это же число. Этого не происходит. Но Вы почему-то этого не видите.
2. Вы не поэкспериментировали. Потому что если бы провели такие экспермиенты, то полученные результаты заставили бы Вас задуматься.
3. Я стараюсь как можно более доходчиво разъяснить свою позицию. Вы стараетесь писать как можно непонятнее, небрежно бросая пару строк. Не строя гипотез о причинах этого, могу лишь сказать, что подобный стиль не ведет к решению проблем и, следовательно, неконструктивен.
Вывод:
Продолжать диалог в этой ситуации бессмысленно.

[Валенок]

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

T1:= T#49d17h2m47s295ms (копи пасте прям из хэлпа)
RR:=TIME_TO_REAL(T1);
T2:=REAL_TO_TIME(RR);
Что не вижу ? T1 = T2. Должно быть как-то иначе ?
Ах, вырезали вторую цифирь – а она 4194967295ms
А в голову не приходит- почему первая и вторая цифирь в хелпе разные ?
Что простая опечатка 4194967295ms ? Девочка 1 вместо 2 нажала. Нет же. Всё неправильно. Всё нет так. Катастрофа. Из опечатки сделали вселенскую проблему. Мне такое даже в голову не приходит.
Вы видели какую-то документацию в таком объеме АБСОЛЮТНО без опечаток ?

Знаете за что у меня взгляд зацепился когда копипасте того числа сделал ? За чётность при обратном преобразовании. Мне хватило чтоб найти трабл.
Вы не подумали, почему я даже не пытаюсь вспомнить кол-во дней/часов в максимальном TIME а пишу просто INT_TO_TIME(-1) ?

3…Вы стараетесь писать как можно непонятнее, небрежно бросая пару строк.

Так эти строки – из той же песни. И если взаимосвязь невидна, хотя бы направление, то это нужно основы изучать - но форум вроде не тот.

2. Вы не поэкспериментировали. Потому что если бы провели такие экспермиенты, то полученные результаты заставили бы Вас задуматься.

А зачем мне экспериментировать ?
Выяснять почему-же все таки с тем числом нет отката назад при преобразовании ?
А Вас не удивляет что REAL_TO_WORD(2.7) = 3 ? Примерно отсюда же. Курим по IEEE – если интересно. Направление – представление отрицательных чисел. Оно не аналогично целочисленным. То число в нормализованном виде для мантиссы требует 27 бит. А сколько дают ? А -1 требует 1 бита. (знак – отдельно в обоих случаях) Вот и делайте выводы

И действительно -

Продолжать диалог в этой ситуации бессмысленно.