Cancel individual part(s)

JoergS5

IMHO it's possible to distinguish objects in the gcode: analyze all movements where the extruder is active and find the non printing areas which are in all layers (except raft layer etc.) non printing.

A different approach: in the Gui who handles the deactivation of parts, the parts could be marked by different textures. After removing a part, the g-code is recalculated and print proceeded at the active layer, now without the deactivated part. You pause at the end of a layer print, so proceeding should be without problem.

deckingman

@doctrucker said in Cancel individual part(s):

Without tags in the slice file it is near impossible to do a resonable job of deleting a single part. If you were to use audio file terminology the gcode format is not loss-less. When you slice you loose information regardless of the file size increasing.

Trying to distiguish what data belongs to what part would be very difficult. For example are four circles of filled area four differwent parts or four legs of a tiny table? Closest you may be able to do is specify a box and ignore any gcode blocks that are included, intersected by, or encirculate said box. This is still not fool proof and could result in a number of layers of a part bein cancelled then build resuming in free space making a far worse mess.

Wes,

One of doing it in Slic3r (and other slicers too) would be to assign a different tool to each object or part. The gcode file would then contain Tn commands and anything that comes after would be related to one part until the next Tn command. I guess what I'm saying is that the Tn commands would act as flags (or tags). The "T" would denote the start of each part and the "n" would denote the number of that part. So to cancel part 2, the firmware would need to ignore any commands coming after a T2 "flag" but before the next Tn "flag".

There are of course practical implications, not least of which would be the need to define multiple tools identical in all respects apart from their numbers.

Just a kind of random thought.........

Jbourns

would being able to print multiple gcode files work somehow ? then you could send a command to ignore that file.

DocTrucker

The amount of work to distiguish parts without any for of flag is massive. It would be far easier to make contact with the people who write the slicers ang get them to agree on a universal tagging system. You can even have support structure from one part intersecting the next.

Merging different gcode files (one per part) with python would be easily possible, and then the gcode could be tagged in a way that would allow dc42 to create a simple feature demonstrator. Issues with this would be total slice time should be kept above the minimum to avoid auto cooling and slow down (good prstice anyway) and the skirt would not work easily without a little more bodgery! All easier than reverse engineering gcode and if you've got the skills to reverse engineer the gcode like that I'm sure there are some firmware projects that your efforts would be better spent on.

I guess the other simple option is Duet being configured to load multiple, rather than single gcode file. Have a master build file that specifies file name and positional offset. The duet then has no need to parse for tags.

@deckingman Yes, that would be a good way of flagging. I'm still learning with Slic3r but haven't seen how you assign different processing parameters to different parts.

Edit: Sorry @Jbourns, missed your comment. We're suggesting the same thing by printing multiple files.

DocTrucker

Currently redundant at the moment and busying myself by completing outstanding jobs around the house. I'll look into a python script that merges multiple gcode files whose file names, offsets, and tool numbers are specified in a JSON formatted file.

This shouldn't take long and is useful practice for me anyway.

All going well the output would be a gcode file that can be run by a printer (or online simulator) without fault but also be able to be split back into individual files.

Tags will be simply

;part_0="nameOfPart.g"|applied_offset=(12.0,12,0.0)

These will be entered before the gcode for the part. The next part tag will indicate the end of the previous. This won't be fool proof and could easily result in multiple parts intersecting.

Proof will be something along the lines of:

Simulate files in duet.
Split files into layers (not compatible with vase mode).
Format G1 commands to specific number of decimal places.
Add commented checksum for non commented out G1 commands.
Merge files applying offsets and tags.
Read into duet and simulate build.
Split file removing offsets.
Check layerwise checksums.
Rebuild files.
Simulate files in duet.

fma

@DocTrucker, with a friend, at work, we made some tests using K-means algorithms. We get decent results, even with parts having several isolated perimeters. But it's under Matlab...

@deckingman, your approach sounds great! The resulting G-Code could be post-processed as well, to remove dummy 'T' commands, and replace them by a more specific flag! I will try that...

fma

Just started to write something: pretty easy!

Ok, so, now, we need to define the tag the firmware will parse. Octoprint looks for 'process', but it is a workaround, based on S3D possibility, not really a dedicated tag.

DocTrucker's one seems good:

; part_n

@dc42, what do you think?

PS: my script will also add S3D 'process' tag, for people using Octoprint.

dc42

I suggest "; part n" to be similar to the "; layer n" comments that some slicers insert.

resam

Seems like there is some work also going on in Cura:
https://github.com/Ultimaker/CuraEngine/issues/801
https://github.com/Ultimaker/CuraEngine/compare/feature_comments_per_object

paukstelis created this issue in Ultimaker/CuraEngine

closed Feature Request: Add object/model/mesh name comments to gcode blocks #801

fma

Here is a very simple Python script to implement Ian's idea:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import sys

for line in sys.stdin:

    # Replace tool changing commands by part changing tags
    if line.startswith('T'):
        num = int(line[1:])
        print "; part %d\n; process %d" % (num, num)

    else:
        args = line.split()

        # Only keep tool 0 temperature commands
        if line.startswith('M104') or line.startswith('M109'):
            args = line.split()
            num = int(args[2][1:])
            if num == 0:
                print line,

        # Default commands
        else:
            print line,

It replaces tool changing commands:

Tn

by:

; part n
; process n

It also remove all temperature commands of tools >= 1.

To use it:

$ ./tool_parser.py <input.gcode >output.gcode

PS: I only checked Slic3r output; Cura output may need additional stuff.

wilriker

@fma said in Cancel individual part(s):

It replaces tool changing commands:
Tn
by:
; part n
; process n

Regarding Cura: AFAICT your script will replace all occurrences to Tn including the first one that actually really selects the tool (if it has not been selected previously) and will be inserted by Cura as the very first command (even before start codes) if you chose RRF in settings.
So you might want to also check for the start of the first layer before replacing Tn lines.

patakopecek

@dc42 the script above seems to work (at least for me) reasonably well, I think I could integrate it into slic3r PE to run after the slicing is done, would you integrate it to the firmware please? It would make my life so much easier.

BTW: The gcode to end the part could be something like G84 Pn Ln (the L could be the layer to stop the object at)

T3P3Tony

@patakopecek this functionality is also being discussed here:
https://forum.duet3d.com/topic/6540/a-fairly-large-change-to-the-code/12