Cancel individual part(s)

dc42

Do you know what information it uses that is written by S3D?

DocTrucker

Slic3r has an option to add comments when the data is moving onto different parts but I've not tested it yet. Might be something as limited as "; end part", ";start part". I did something similar for MCP/MTT/Renishaw's SLM machines in a different life! Speeds up experiments massively as you can chance things and cancel problem makers. Less risk.

@dc42 Did you get much luck setting up a cross platform working group to investigate developing or replacing to gcode format?

Identifing blocks of code as belonging to one part is a start, moving process parameter data to a header section allowing for local scope over rides is another potential big step.

fma

@dc42 see:

https://www.youtube.com/watch?v=ANfOr2F79LQ&feature=youtu.be&t=162

fma

@doctrucker said in Cancel individual part(s):

Slic3r has an option to add comments when the data is moving onto different parts but I've not tested it yet.

It seems it only works when printing objects sequentially...

fma

I read the messages in the Slic3rPE bug-tracker, and it seems that this feature will not be integrated soon...

So, I think that post-processing the G-Code would be a more universal solution. This mainly requires to be able to distinguish different parts by analysing the tool trajectory.

Do you have any advice to do that? I would like to use Python, so if you know some interesting modules...

PS: Ian, which module are you using to parse G-Code?

deckingman

@fma said in Cancel individual part(s):

PS: Ian, which module are you using to parse G-Code?

I write my own. TBH all I do is text editing and you can use any number of tools to do that. Mostly it's a case of search for a particular string of characters and replace it with something else, or insert something before of after that string. I started doing it with notepad++ but it became a bit tedious. I chose Python basically because there are many resources on the internet so I can just "Google" what I want to do and find an answer. I looked at Perl but every time I did a search for a particular topic, I ended up some forum or other where a bunch of purist code writers would be bickering and arguing about the most efficient way of doing something, rather than answering a simple question.

So when I say, I write my own modules, what I really mean is that I scrape chunks of code off the internet and cobble them together. The results aren't pretty and I'm sure that professional writers of code would either laugh or cry if they saw my efforts. But I get the job done and that's all I care about.

fma

@deckingman said in Cancel individual part(s):

I write my own. TBH all I do is text editing and you can use any number of tools to do that.

Ok. Yeah, this is easy to parse such text file in Python, but I don't like re-writing something which already exists ;o)

Thanks!

DocTrucker

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.

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)