[DSF Extension] ObjectSkipper - skip failing objects in a print

[wilriker]

Pre-Release v0.9.0

I implemented a small DuetSoftwareFramework extension to skip objects in a print because e.g. they are ripped off the build plate or whatever reason you might have to just skip an object.

v0.9.0 can be found at GitHub Releases page.

Usage

$ ./objectskipper --help
Usage of ./objectskipper:
  -currentid int
        M-number to list/add current object Id (default 52)
  -disable int
        M-number to disable filtering (default 53)
  -idpattern int
        M-number to manage object identifier patterns (default 50)
  -objectid int
        M-number to manage object Ids (default 51)
  -socketPath string
        Path to socket (default "/var/run/duet.sock")

It needs to be started as a user that has read/write permissions on socketPath (by default that would be root). It then will intercept certain M-Commands (by default that is M50, M51, M52 and M53) that currently have no other meaning in RRF (you could also override existing codes with that).

After configuration it will scan for comment lines (currently they have to be individual lines not comments appended to any command) starting with a pattern and if it finds one compares it to a list of objectIds to skip. If both match it will skip any code until the next pattern matches or does not match anymore (in which case it will not filter commands anymore).

Code Documentation

The following codes are documented based on their default numbers.

M50 Manage Identifier Patterns

Parameters

• P"pattern": Pattern that identifies an objectId
• Snnn: Add/remove pattern

This is used to add an identifier pattern, e.g. MESH: for Cura. You will have to look up what your slicer uses as an identifier term. This command can be used to add an arbitrary amount of these patterns.

Calling M50 without any parameters will list the set of configured patterns
Using Snnn with nnn != 1 does remove the pattern provided by the P parameter.

M51 Manage objectIds

Parameters

• P"objectId": Id of an object to skip
• Snnn: Add/remove objectId

This is used to add an objectId that the slicer has assigned to an object. Adding an objectId will start skipping this object on it's next occurrence. This command can be used to an an arbitrary amount of objectIds.

Calling M51 without any parameters will list the current set of objectIds to be skipped.
Using Snnn with nnn != 1 will remove the objectId provided by the P parameter from the set.

M52 Current ObjectId

Parameters

• Snnn: Select mode
  ** 0 or not provided: list id of current object plus a list of all objectIds seen so far (this of course requires patterns to be defined, see M50)
  ** 1: add id of current object to filter set (this is like using M51)
  ** 2: like 1 but start filtering immediately

This command without any parameters or S0 will output the current objectId.
Important note: this is the objectId of the object that is currently read from file and might differ from the one that is printed right now if it is a really small object or near the end of an object. This needs some improvement. The same restriction applies to S1 and S2 to add this object to the list of those being skipped.

Future Plans: this should have more information on coordinates of the object so it will be easier to identify.

M53 Disable filtering

Paramters

• Snnn: Optionally delete all known patterns and objectIds to filter
  ** S0 or missing: disable filtering until the next match
  ** S1: like S0 but also reset the lists of patterns and objectIds

Use this to disable filtering temporarily or reset filtering completely.

Contribution

As always I welcome any kind of contribution here or over at GitHub. Comments, suggestions, bug reports, Pull Requests, whatsoever. Everything is appreciated.

[gtj0]

Very nice Manuel!

[T3P3Tony]

@wilriker great! are the M5x commands intended to be gcodes that will be generally supported for these actions? if so is it worth reserving them as such in the gcode documentation on the RepRap Wiki as well ad our dozuki?

[wilriker]

@T3P3Tony I don't know if anyone thinks of standardizing these as M-Commands but we could reserve them so they are there already, i.e. creating our own standard everyone else has to follow. But then we would need to discuss first if they are appropriate like they are right now.

[T3P3Tony]

@wilriker indeed - first question would be if they clash with anything used in CNC or other G/M code uses.

[wilriker]

@T3P3Tony at least they are not listed at RepRap GCodes wiki - that's why I chose these. This should cover NIST standard (I can check though). Not sure if there is any other relevant standard it there.

EDIT: I checked NIST Standard and it does not contain any M-code in the 50s range.

[dc42]

May I suggest that any new M codes intercepted by add-ons be given high numbers, for example in the range 2000 to 3000. It's not just NIST we have to worry about, it's also current and future versions of Marlin, LinuxCNC, Fanuc etc. Gcode that RRF may have to emulate in future.

[wilriker]

@dc42 I think your idea is good but I am a bit torn on this one specifically. This might be a feature that will make it into firmwares at one point. If we set (and document) it to be in the say 2000s range do we expect that other firmwares will adapt such large numbers?

[dc42]

@wilriker said in [DSF Extension] ObjectSkipper - skip failing objects in a print:

@dc42 I think your idea is good but I am a bit torn on this one specifically. This might be a feature that will make it into firmwares at one point. If we set (and document) it to be in the say 2000s range do we expect that other firmwares will adapt such large numbers?

In the past, other firmwares have almost always done their own thing and ignored what has been done before. For example, RRF was first with support for mixing tools (M567), but Repetier first and then Marlin chose a different command to support mixing tools. Likewise, RRF was first with a code for pressure advance (M572), but Marlin chose a different command. RRF chose M208 to define axis limits, but Marlin subsequently ignored that and used M208 for a different purpose. This is despite the RRF commands always being documented at https://reprap.org/wiki/G-code before being implemented.

So i don't think you have much chance of getting other firmwares to use the same codes.

[wilriker]

@dc42 Hope dies last we say in Germany.
Seriously: good points. I will move the default values into the 2000s range with the next version. And they are configurable from command line anyway.

[dc42]

I just did a search for "gcode m50" and found that LinuxCNC already uses it. http://linuxcnc.org/docs/html/gcode/m-code.html

[wilriker]

Ooohhh, Feed Override control. That would be "fun" to filter out.