@dc42 I forgot to mention at the beginning that we had to enable segmentation (M669) in order to reduce the delay to 2s.

Are there any other options to reduce the delay ?

@chrishamm Is there a reason why DSF uses an sbyte (int8_t) for MinorNumber when parsing a g-code, and then check that value is greater than 0 in the Parser class ?

if (sbyte.TryParse(args[1], out sbyte minorNumber) && minorNumber >= 0)
 {
    result.MinorNumber = minorNumber;
 }
 else
 {
    throw new CodeParserException($"Failed to parse minor {char.ToUpperInvariant((char)result.Type)}-code number ({args[1]})", result);
 }

The type used in RepRap looks like an integer

struct CodeHeader
{
	uint8_t channel;
	CodeFlags flags;
	uint8_t numParameters;
	char letter;
	int32_t majorCode;
	int32_t minorCode;
	uint32_t filePosition;
	int32_t lineNumber;
};

Would it be possible to use the same data type or just a more redundant integer type ?

@TuomasT thanks for posting this topic, I actually have a similar issue regarding print speed.

@dc42 we are already using M220 but we observed some delays even when printing straight lines;
we noticed though that, by assigning a really high jerk value using M566, we were able to reduce the delay to 2s;
without doing that, the algorithm takes a long time to change the speed of the print in order to preserve the jerk value of the machine (from what I read from RepRap docx file in GitHub).
is there a flag or configuration that we could enable to ignore/speed up the jerk check algorithm ? if that is not the root cause, is it related to how RepRap processes the g-codes queue buffer ?

@infiniteloop did you read the code snippet I wrote in the first message ?

I am also providing an 'agnostic' view;
the best advantage of the approach that I suggested in the first code snippet is that is platform independent (it will work everywhere) and NLog is already being configured for ColoredConsoleTarget anyway (see Settings.cs line 413 in DCS).

I didn’t want to hurt your feelings - not even your pro-Micro$oft ones

Mate, you're hurting nobody, but please do not move the subject elsewhere, nobody is engaging any war.

I love linux and all the amazing contributions the communities behind are adding to the kernel and the distros.

@infiniteloop
seems like you guys don't really like Microsoft ecosystem;

then what is the purpose of using dotnet in DSF ?

there are so many programming languages and runtime environments platform independent with GPIO libraries included (nodejs, python, jdk, rust and many more).

Also, the NLog library is a non-profit project, microsoft only provides the runtime and the file system abstraction.

@chrishamm @oliof
sorry guys if I went too far and kind of changed the main subject of this conversation, going from logging functionalities to os cross-compatibility.

I still firmly think that, at least for logging, DCS and DWS should have a file logs rotation properly configured (via NLog for DCS and maybe via NLog/log4net for DWS).

The possibility for the user to configure the rotation via M-code by extending M929 could be a handy feature; but it doesn't have to be that way, we could just configure it via config.json and/or http.json.

The dotnet platform provides really good abstractions for multiple purposes (logging could be one of them), and deciding to not take advantage of these is like deciding to kind of re-inventing the wheel.

@chrishamm would it be possible to add at least the thread-name/id in the pattern layout for debug purposes ?
using something like the following:

"${longdate} [thread-${threadname:whenEmpty=${threadid}}] ${uppercase:${level}} - ${message}"

I am aware that DSF is based on LinuxAPI (especially for SPI and GPIO tasks) but, since .NET is cross-platform, I think it's best practice to configure a proper logger for DCS and DWS that will work potentially on every platform supported by .NET; this way we won't need to worry about logs rotation anymore.

There's a library provided by Microsoft https://github.com/dotnet/iot that provides abstractions for any sort of GPIO driver (I2C, SPI, PWM ecc..) using System call APIs based on where we run the programs (Linux or Windows); this way DSF could be potentially extended to other platforms

@oliof NLog is already being configured for ConsoleTarget, I think it's way easier to just add another target (FileTarget for rotation) in the source code (this way it will work on every os), instead of using something like logrotate that is specific to linux machines

Have you guys ever considered the possibility of adding file logs rotation to the DuetControlServer and the DuetWebServer ?

For the DuetControlServer is pretty straight forward adding another rule in the config with a FileTarget

using NLog;
using NLog.Config;
using NLog.Targets;

var config = new LoggingConfiguration();

// Define file target with log rotation
var fileTarget = new FileTarget("logfile")
{
    FileName = "/opt/dsf/sd/sys/log-${shortdate}.log",
    ArchiveFileName = ""/opt/dsf/sd/sys/archive/log-{#}.log", // Archived files pattern
    ArchiveNumbering = ArchiveNumberingMode.Rolling,
    ArchiveAboveSize = 10 * 1024 * 1024, // 10 MB size limit
    MaxArchiveFiles = 5,                // Keep max 5 archive files
    ConcurrentWrites = true,
    KeepFileOpen = false,
    Encoding = System.Text.Encoding.UTF8,
    Layout = "${longdate} [thread-${threadname:whenEmpty=${threadid}}] ${uppercase:${level}} - ${message}"
};

// Add the target to configuration
config.AddTarget(fileTarget);

// Define a rule to log everything from Debug level and higher
var rule = new LoggingRule("*", LogLevel.Debug, fileTarget);
config.LoggingRules.Add(rule);

// Apply configuration
LogManager.Configuration = config;

Notice how, in the code snippet above, the pattern layout that includes the current thread that is running, it might be very handy since DCS is a multi-threaded program.

For the DuetWebServer it could get very complex since Microsoft default logger for ASP.NET does not have file logs rotation options; there are some workaround using Serilog but maybe it would be easier to just use NLog as well, or Log4net even better

@chrishamm awesome, thank you for getting back to me so quickly