The bit pattern of the source value is transferred unchanged right-justified and interpreted as nanoseconds to the destination data type. A change in sign has the result that the enable output ENO is set to "0".

For all Xint.


You can see on my attachment that is not the case, not at all.
Conversion to Time, working until you exceed 1Day (expected)
Conversion to Lint, working as seconds, and the number is completed by zero on the right....don't really know why, and I find nothing to re-convert to something usefull
Conversion to Dint and Dword,I did not expect much

Maybe I take the problem upside down, and Ltime is a format to be using with timer, not a format to save "time" in general...
Has anyone ever used the Ltime format ?

CPU side, it's easier to use LTime:= Ltime + LT#1s;  instead of coding a self clock, but if it's impossible to display this format on HMI side....

Simple way:

Use DINT for seconds counter (big enough for >60 years). Increase this counter every second (use "clock 1Hz" and a "p trig" to increment this counter, if machine is working)....

Then use math to calculate minutes, hours, days, months, years (from this DINT counter for seconds), in separate tags and then pass them to HMI, It will work on any CPU and HMI.

Have fun!

uel123.

Thanks, but I already know how to make a count-timer with some tags, the goal was to not doing this, but use the Ltime which is manufactured for... (and with HMI, I always tried to use only the minimum of tag)
And it is working well (CPU side), one tag = a timer going up to 300 years.
I think siemens "forget" to implement the format Ltime for I/O field, that's all.
And I think also that the explicit conversion Ltime->Lint don't work properly, it's a bug.

I was hoping someone had already used this format (which is unconventionnal)

Why implement Ltime if you can't display/modify from an HMI ?
In fact, you can display it, but it's in seconds only...
In codesys you can choose how you want to display time-tag for example, Omron have this kind of solution too

In short, too bad

The LTIME datatype is a 64-bit signed number that represent nanoseconds.
TIME is a 32-bit signed number for milliseconds.

There are code published in SIOS that expand TIME to D / H / M / S / MS. So also is there a TIME-to-STRING converter in the Library of General Functions (LGF). I know of no prepared code published here that helps for LTIME.

Engineers working with Siemens equipment is so clever that there is no need to handhold them for such trivial coding. Or.. This forum has the most helpful intellectual expert base of any PLC brand.     Chose whichever of these skewed opinions or see if Oscat.de or other sources have some coding for you.

It's better to increment a DWORD by 1 every second instead of TIME by t#1s.
S7-1200 does not have 64-bit time so it can hold less than 25 days in a TIME variable.

I use FB below to convert seconds to dddd:hh:mm:ss string.

(BTW if for machine runtime hours is enough, you may look into RTM instruction that I think does that)

FUNCTION_BLOCK "sec2str_FB"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
VAR_INPUT
inTimeSec : DWord;   // time to convert, in seconds
END_VAR

VAR_OUTPUT
sTime : String;   // inTimeSec as ddddd:hh:mm:ss string
END_VAR

VAR
aHMS : Array[0..13] of Byte := 5(48), 58, 2(48), 58, 2(48), 58, 2(48);   // == 00000:00:00:00 [ddddd:hh:mm:ss]
num : Array[0..9] of Byte := 48, 49, 50, 51, 52, 53, 54, 55, 56, 57;   // ASCII codes of 0..9
END_VAR

VAR_TEMP
days : DWord;
hours : DWord;
hoursAll : DWord;
min : DWord;
minAll : DWord;
sec : DWord;
startPos : DInt;   // aHMS index to start copying from
i : Int;
END_VAR


BEGIN
//converts a DWORD (time in seconds)to ddddd:hh:mm:ss string

#sec := #inTimeSec MOD dword#60;   //seconds of last non-full minute

#minAll := #inTimeSec / dword#60;   //minutes
#min := #minAll MOD dword#60;       //minutes of last non-full hour
#hoursAll := #minAll / dword#60;    //hours
#hours := #hoursAll MOD dword#24;   //hours of last non-full day
#days := #hoursAll / dword#24;

#aHMS[0] := #num[#days / dword#10000];
#aHMS[1] := #num[(#days MOD dword#10000) / dword#1000];
#aHMS[2] := #num[(#days MOD dword#1000) / dword#100];
#aHMS[3] := #num[(#days MOD dword#100) / dword#10];
#aHMS[4] := #num[#days MOD dword#10];

#aHMS[6] := #num[#hours / 10];
#aHMS[7] := #num[#hours MOD 10];

#aHMS[9] := #num[#min / 10];
#aHMS[10] := #num[#min MOD 10];

#aHMS[12] := #num[#sec / 10];
#aHMS[13] := #num[#sec MOD 10];

FOR #i := 0 TO 12 DO
IF #aHMS[#i] <> 48 AND #aHMS[#i] <> 58 THEN
#startPos := #i;
EXIT;
END_IF;
END_FOR;

Chars_TO_Strg(Chars := #aHMS,
pChars := #startPos,
Cnt := 0,
Strg => #sTime);



END_FUNCTION_BLOCK

Thanks you all for your suggestions, and in general the discussion.

At least, I have my answer.
Just don't use the Ltime (except for big timer), so I make this : 

sixthomas

O_Einstein

Let's suppose you have your tag set up in a DB named TestDB and tag named TimeTag.
"TestDB".TimeTag.hour .. TimTag.minute etc.

 -> in TIA V15.1, it is no longer working, just why ?

I don't think it ever worked like that.

sixthomas

After that, I tried to convert it, and found that F1Help was in contradiction with the reality (the explicit conversion to Lint is not in nanoseconds, and not right-justified). > it's clearly a bug.

Can you show a proof that LTIME_TO_LINT fails?

Ooh, epic fail.
I forget 1ms = 1 000 000 ns, not 10^3
Mea Culpa

It doesn't change the others points (which are more personnal opinions).
I maintain that in general, it is better to use the correct datatype.
To count "time", I found the Ltime suitable, unfortunately it is not implemented on the HMI side (and not in 1200 series) easily. (VBS script can convert I think, I have not try)
For example, for dates, we have plethora of datatype (Date, TOD, LTOD, DT, LTD and DTL), and a dedicate tool (date/time field and clock) on the HMI side. One would expect the same treatment regarding "time".
You probably find that I'm complaining for nothing, it's probably true (certainly depends on where we got "ours marks" in programming).
And from my point of view, it was not a complaint, rather an attempt to understand
And I admit to being stubborn.
I think we have covered the whole question