Usually the indexes of the boards array follow the declaration order in config.g, therefore looks like board 20 has actually address 119 as shown from your screenshot;

maybe you can try something like this

M952 B119 A20

Are the can-addresses of the other 2 boards congruent ?

Please let me know if you fixed it in another way.

I've been playing with DSF object model websocket for a while now and, after writing my own "connectors" programs, I wanted to dispatch some actions especially when there's a critical error like 'file cannot be print' or similar;
I think it would be nice to have an optional ErroCode property (string/int) in the object model Message class so that we can easily dispatch some actions based on those codes;

message EXAMPLE:

{"messages": [
   {
      "code": "PR1",
      "content": "failed to start print, axes not homed",
      "type": 2 
   }
  ]
}

but I understand that it would require a lot of work on both DCS and RepRap plus an all new documentation to write, explaining what each code means.

Anyway, I thought it could be an interesting topic to talk about.

@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