bengeisler / tclog Goto Github PK

If the folder path doesn't exist it is not created, and the text file is not saved. Is this correct? Should it create the "C:/logs/" because it doesn't on my system. If I manually add C:/logs before running the program it works fine but if the folder isn't there to begin with I get error 1804 for fileOpen.

What is the best way to write log messages on the first couple of PLC scans after restarting.
I would like to implement something like the following in a POU:

VAR_INPUT
	bInput : BOOL;
	bFirstScan : BOOL;
END_VAR
VAR
	_logger : TcLog;
	_tcLogTrig : TcLogTrig;
END_VAR


_logger
	.OnCondition(bFirstScan)
	.Warning(CONCAT('Initial value is ', BOOL_TO_STRING(bInput)));	

_tcLogTrig
	.OnRisingEdge(bInput)
	.Warning('Signal had a rising edge');	
	
_tcLogTrig
	.OnFallingEdge(bInput)
	.Warning('Signal had a falling edge');

With the POU being calling like so from MAIN:

VAR
	_coreLogger : TcLogCore(bufferSize := 100 * (Tc2_System.MAX_STRING_LENGTH + Constants.FifoOverhead));
	_logger : TcLog;
	
	fbTest : FB_Test;
	bInput : BOOL;
	bFirstScan : BOOL := TRUE;
END_VAR


_coreLogger
.WriteToAds()  
.IncludeInstancePath()
.TimestampFormat('YYMMDD')
.SetRollingInterval(RollingIntervals.Daily)
.MinimumLevel(LogLevels.Debug)
.WriteToFile(path, filename)
.RunLogger();

fbTest(bInput := bInput, bFirstScan := bFirstScan);
bFirstScan := FALSE;

However I end up getting two files written as below:

With the contents of the first file being:

It looks like the time hasn't been updated yet to the local time. Is it possible to expose DateTime._localSystemTime.bValid? Or is there a better way of doing this?

Has anyone tested it with the current TwinCAT version. Our project does not build anymore after the upgrade.

Hi, I just installed this via Twinpack and tried to run the example code, but I am missing some references or libraries maybe?

MAX_STRINGLENGTH
Constants.FifoOverhead
LogLevels.Debug

All of these are red and not recognized by Twincat. Is there something I am missing?

Hi!

this is not an issue, but only a discussion…
At Zeugwerk we have a pretty similar logger and are currently implementing a fluent API for it (atm our API is not fluent) - in general our logging mechanism has some major differences to TcLog, because we don’t use a singleton pattern, but allow several loggers to be used in a single PLC and require logging into multiple log targets to be thread-safe.

I played around a bit on how to implement the fluent API for it and found that having the log level as the first call can improve the performance a lot.
Our API, coming with Zeugwerk Framework 1.6, will look like this

_logger.AtInfo().LogMessage('I am a log message);
_logger.AtTrace().WithCondition(boolean1).Append('Number ').AppendInt(5).Append(' is alive').LogMessage('');
_logger.AtWarning().WithRisingTrigger(boolean1).LogMessage('boolean1 just got true');

having the log level as the „initiating“ call to the fluent API, has the advantage that a log message can be immediately discarded if the minimum log level as not satisfied, also if any „with“ condition is not met the message can be discarded. A discarded message doesn’t need any string operations, so besides the calls to the methods and an „if discarded then return“ the messages are for free.

What do you think of this?

Hello, I have started using this library and I have encountered small issues, that I might try to fix. What is the desired contributing strategy?

Best regards,
Mihai

We had to change the TwinCat from version 4024.32 to 4024.55 due to driver problems on a new Beckhoff computer. Since the change to the 55 version, I can no longer compile the program as long as TcLog is active. There are problems recognizing the contents of the library.
If I switch back to 4024.32 on the same PC, everything works again.

There will then be 120 error messages. Here are a few as an example:

• Expression of type 'BOOL' expected in this place
• Functionblock 'TcLog' must be instantiated to be accessed
• Unknown type: 'TcLog.ErrorCodes.ClosingFileFailed'
• Unknown type: 'TcLog.ErrorCodes.EnumeratingFilesInSpecifiedDirectoryFailed'
• Unknown type: 'TcLog.LogLevels.Fatal'
• Unknown type: 'TcLog.LogLevels.Error'
• Unknown type: 'TcLog.LogLevels.Warning'
• Unknown type: 'TcLog.LogLevels.Information'
• Unknown type: 'TcLog.LogLevels.Debug'

When logging many messages per cycle, eventually FB_FileClose throws an error. The state machine of DynamicStringBuffer.PersistToFile changes from STATE_APPEND_DATA_TO_FILE (3) to IDLE (0). The opened file does not get closed.

Following up on discussion at #2 .

Hello @bengeisler
It would be great if you included the library in TwinPack,
I'll give you the link:
https://github.com/Zeugwerk/Twinpack

How should one log multiple Boolean signals in the same FB? Is it ok to use the same instance or do you require a new FB for each thing you want to log. Specifically, I'm looking at the TcLogTrig. For example, can I do the following:

FUNCTION_BLOCK FB_DigitalInputLogger
VAR_INPUT
        input1 : BOOL;
        input2 : BOOL;
	fbCoreLog : REFERENCE TO TcLogCore;
END_VAR
VAR
	fbTcLogTrig : TcLogTrig;
END_VAR

fbTcLogTrig.SetLogger(fbCoreLog);
fbTcLogTrig
	.OnRisingEdge(input1)
	.Information('Input 1 is TRUE');
fbTcLogTrig
	.OnFallingEdge(input1)
	.Information('Input 2 is FALSE');
	
fbTcLogTrig
	.OnRisingEdge(input2)
	.Information('Input 2 is TRUE');
fbTcLogTrig
	.OnFallingEdge(input2)
	.Information('Input 2 FALSE');

With last version "manual" installation (V0.5.0), the TC log lib have no category
I dont know if this can be fixed, but a "log" categorie can be good

I am having an issue appending int values using AppendAny. I think perhaps the pointer values are not lining up?

For example -18000 (is) is appearing as 115.

this is my code

PROGRAM MAIN
VAR
	tcLog:TcLogCore(bufferSize:= 1000);
END_VAR

Hi!
I would like to put your repository on the twinpack registry, which we just developed: https://github.com/Zeugwerk/Twinpack-Registry

This will automatically check your repository for new releases and if there is one that is not available on Twinpack yet, it is uploaded to Twinpack. It is only required to have the .library file as an asset in the release, which you do anyway. In the next release we will even have a feature that directly downloads libraries from the GitHub assets and will do a fingerprint check to make sure that the library was not modified after publishing.

No other interaction is required for publishing to Twinpack as soon as a repository is on the list. As Twinpack itself, the registry is open source and available here https://github.com/Zeugwerk/Twinpack/tree/main/TwinpackRegistry

Are you ok with this? If you like this initiative please spread the word, we want to get some momentum in the TwinCAT community by this