How can I prevent machine limit to be overriden by slicer code?

kuon

In my config.g, I have machine limit like M203, M201...

I want to be sure that the slicer cannot override those.

Is it possible to "lock" those values once config has been read?

jay_s_uk

@kuon no. You'll need to stop the slicer from outputting those values. Most slicers can turn it off

kuon

@jay_s_uk said in How can I prevent machine limit to be overriden by slicer code?:

@kuon no. You'll need to stop the slicer from outputting those values. Most slicers can turn it off

Yes I know that, but sometimes people create a new config and output high values which can damage the machine.

dc42

@kuon one of the things on my list is to limit the commands that can be run from a job file, in particular banning commands that change machine configuration or machine limits.

dwuk3d

@dc42 have you ever considered allowing all commands to be overridable with macros like I think you can do with Klipper?

As this would allow this type of requirement to be met fairly easily I think.

T3P3Tony

@dwuk For a lot of configuration commands it would require the user to "rewrite" those commands as macros that did the same function, so we would need to implement an alternative way to achieve that command.

For example M203. if that was replaced with M203.g, the contents would have to be another command that carried out the functionality of M203 + any user logic they wanted to add (like checking if it was being run in config.g or not).

I can see some sense in being able to override more built in commands with macros (possibly some of the probing commands for example), however configuration commands don't fall into that category for me. For those being able to enable/disable their ability to be run makes more sense.

kuon

@dwuk You mean that in config, doing something like (pseudo code): M203 = M291 P"Not allowed" then, using M203 later would run the M291 instead?

The danger with that is that I think we should make a distinction between machine files (config, daemon, tfree...) and jobs.

dwuk3d

@kuon @T3P3Tony Yes something like that - I think in Klipper - you can specify in a Macro - Rename_existing: - That renames the original command, and then you can then put some logic before or after it - and if required still call the original command using its new name.

For example in the SV09 Klipper config the M106 fan control command has been overridden to cause both print head cooling fans to turn off and on at the same time.

In the standard SOVOL SV08 configuration the following commands have all be overriden.
M109, M190,M106, M107, M600.

So in the example of M203 you could either completely disable it, or have some logic that set some limits or circumstances when it could be called.